What Memnox is

This page assumes nothing technical. If you work in operations, finance, legal, HR, customer success or leadership, this is the page to read, and it is the same explanation an engineer gets, not a simplified one.

The problem

A team already runs AI agents. Somebody installed Claude Code, somebody else turned on Cursor, a pipeline has a token, and a product the team buys has an assistant inside it. Each of them was granted access once, by somebody who may have moved on.

The agents are good enough to do the work. What stops a team going further is not capability, it is nerve. More autonomy means more access, more access means more consequence, and more consequence means less willingness to walk away from the screen. So the work gets supervised, and the supervision is the cost.

Underneath that sit three things that are separately knowable and nowhere joined up:

• what each one can do, which lives in permissions, MCP manifests and tokens;
• what each one actually did, which lives in whatever logs it happened to keep;
• what the team intended, which lives in a Slack thread from March and in the head of the person who is on holiday.

Knowing only the first is an inventory. Only the second is observability. Only the third is search. Any two of them is a feature, and none of the three, on its own, is enough to let anybody say go ahead.

What Memnox does

Memnox raises how much you can safely let an agent do without watching it.

It does that by closing the gap above: what agents can do, what they actually do, and what your team intended. The question it is built to answer is not what did my agent do last night, it is what can I safely let it do next.

That reduces to four questions, in this order, and everything in the product answers one of them.

1. What can it do?

Memnox reads what is already on the machine, agent configuration, MCP manifests, shell profiles, credential stores, and reports what can act and what that can reach. No account and no network call, because the answer is on your own disk. See What can already act on this machine.

2. What is it doing?

Every action an agent takes passes a seam, the MCP proxy, a PATH wrapper, the governed shell, a git hook, and each one records what happened rather than what the agent said happened. Each also states what it cannot see, because a governed agent with an unwatched side channel is worse than an ungoverned one. See The runtime and its seams.

3. Why is it allowed?

Once Memnox knows the team's rules, payments code needs a second pair of eyes, nothing touches the production database, it can hold an agent to them. Not as a reminder, as a gate: an action is allowed, held until a named human decides, or refused with the permitted alternative named.

The gate contains no AI. It is a deterministic rule engine: the same request produces the same answer every time, and the answer quotes the rule that produced it. See How a decision is made.

Nothing enters that picture without a link back to where it came from. Every thing Memnox believes can be clicked back to the Slack message, the pull request, or the minute of the recording it came from. See The team graph.

4. What can I let it do next?

This is the one the other three exist for. An agent that has earned more authority is a question with an answer: what a wider grant would actually enable, read from what has already been observed rather than imagined. Widening is a decision somebody makes with that in front of them, never something Memnox does on its own. See Who caused this.

What Memnox refuses to do

This matters as much as the list above, because it is what makes Memnox safe to put in front of everything.

Memnox governs agents. It is not one.

• It does not write code.
• It does not review code, comment on pull requests, or suggest reviewers.
• It does not run your work in a sandbox of its own. The one wall it draws, memnox run --untrusted, is around an agent you started, and it does nothing inside it.
• It does not put an AI model in the path of a security decision.

It reads a pull request the way it reads a Slack message: as evidence that a decision may have been made. Forming an opinion about the code inside it is review, and review is somebody else's product.

The two halves, and where the line falls

Memnox knows this session. Memnox Cloud knows everything around it.

Memnox on your machine governs the agent, and it does that from inside the session the agent is already running. Memnox Cloud governs the team around it: the other machines, the other people, and what the team decided.

Memnox ships as those two pieces, and the line between them is a principle rather than a feature count, because a feature count means arguing about it every quarter.

Everything one person needs to govern the agents on their own machine is open and works with no account. Anything that only means something across more than one person is the cloud. The transition is not a paywall. It is the moment a second person arrives.

The runtime is what one person needs

It runs on your own machines, is open source and free, and memnox setup puts a machine under it in one command. No account, no API key, no network connection, because deciding whether an action may proceed never required one. That is architecture rather than a free tier, and it is the reason a security engineer will run it on a laptop that holds production credentials.

An engineer runs setup, and from that moment every agent action on that machine is decided before it runs, refused where it should be, and recorded either way. A daemon keeps the boundary in place afterwards: an agent installed next week is hooked on its own, and a hook something removed is put back.

After that the engineer works in the agent, not in a Memnox terminal. The agent is told the boundary when a session starts, is reminded of a decision somebody already took where it runs into one, and can ask Memnox why something was stopped, what the session did, or to rewind the files, which its person has to approve. A question Memnox puts to a person arrives in the agent's own permission prompt. No tool in the session can approve anything, so the agent cannot approve itself. The CLI is the escape hatch: setting up, stopping and starting protection on the record, updating, and a handful more. See Memnox in your session.

The cloud is what a second person makes possible

It runs hosted, and everything in it is something one laptop cannot answer: how many agents the team has, what a rule would do to forty machines, who should be asked and where they already work, and whether an agent has earned more authority than it holds.

An admin sets it up in a browser. A machine joins it with memnox login, the one deliberate step towards the cloud, and memnox setup after that puts each of its agents in the workspace.

Which half holds what

There is a competitive reason as well as a principled one. The enforcement primitive is being given away by companies with far more distribution, so a policy engine behind a login is a losing position within a year. Giving away the engine and selling the team layer around it is not.

How they relate

The runtime works completely on its own. A developer can govern their agents on a laptop forever and never talk to a server that is not theirs.

The cloud makes the runtime better informed: decisions your team approved and the team's current state, an open incident or a release freeze, are compiled into the same bundle the evaluator already reads. The hot path never waits on the control plane and never on a model. An install that cannot reach the cloud keeps deciding on its cached bundle and marks every verdict stale, and memnox logout forgets the credential while the rules already pulled stay in force.

Nothing about the local path changes when the rest of the team adopts the cloud. Local ids are kept when a machine enrols, so no history is lost, and the record is always yours to export.