Enrolling an agent

A scan says what can already act on this machine. Enrolling is the act after it: putting one of those agents under Memnox deliberately, one at a time, with the undo written before the change.

All of it in one command

$memnox setup

Find the agents, MCP servers, CLIs and credentials here, show what each agent can already reach, ask once whether to put them under Memnox, and wire the machine. No account and no network call.

$memnox status

Whether this machine is protected, the mode, the agents and MCP servers, the rules in force, today's actions, asks and denials, the approvals waiting, and whether a workspace is connected. Bare memnox shows the same once setup has run.

Every agent's reach is on screen before the question, because whether to govern something that can read your cloud credentials is a different decision from something that can only read this checkout. Then setup wires the machine: the interceptors, the hooks in Claude Code, Codex, Cursor, Gemini CLI and Windsurf where they are installed, the MCP servers through the proxy, a baseline rule set and a daemon the operating system keeps running. It ends by saying the machine is under Memnox and that nothing left it. The machine starts in observe, watching rather than stopping, until memnox config set mode enforce.

The daemon keeps that boundary afterwards. An agent or MCP server installed later is wired automatically, and a Memnox hook removed from an agent's config is put back. Each raises a desktop notice, so there is no setup to run again.

Enrolling an agent into a workspace is the step after, and the only one that needs an account. Run memnox login, then memnox setup again: it names each agent in the workspace and puts it there, and the rest of this page is the same steps separately, for when you want one of them.

What is on this machine

$memnox agents discover

Scan this machine for agents and report what was found: each one by the name you gave it, the product it is, and what it can reach. The default subcommand. It asks what to call each one as it goes, and Enter keeps the detected name.

$memnox agents name <agent> [name]

Call an agent whatever you call it. --clear puts the detected name back.

$memnox agents list

What this machine hosts, from the scan already taken. Deliberately the cheap one: a discovery starts every MCP server it finds and takes seconds, and listing is what somebody runs twice in a row.

$memnox agents status <agent>

One agent, with the file that proved each surface it has. A count says how much an agent can reach; the path says who granted it, which is the half somebody can act on.

Starting somebody else's MCP server is the one thing a discovery does that runs code, so --no-probe turns it off and tools come from the cache instead.

Where this machine is connected to a workspace, a discovery is reported on the same pass a sync uses rather than through a second path of its own, because two ways to report one scan is one of them drifting. With no account it reports nowhere and says so, and a control plane it cannot reach costs the send and never the scan: that one goes up with the next sync.

Putting one under Memnox

$memnox agents onboard [agent]

Enrol one agent, back its configuration up first, and add a single Memnox entry to it. Takes the name you gave it, the id or the product, whichever you have in front of you. --name says what the workspace should call it rather than being asked. With no agent named, it lists what could be onboarded.

Five things happen, and the order is chosen for what survives an interruption rather than for what reads well.

1
You say what to call it
Asked first, because this is the moment the name stops being local: it is sent with the enrolment and it is what the console shows from then on. The control plane hashes the hostname and never stores it, so the name you choose is the only human thing on the fleet row, and a fleet nobody named is a list of ids nobody can tell apart. It is written here too, so the name on this laptop and the name in the workspace are one name rather than two that drift.
2
A person approves it
The command prints a code and the page to approve it on, which is the device flow memnox login already uses for the host. A machine credential cannot mint another machine on purpose: something able to enrol machines could enrol as many as it liked, and enrolment is the act the control plane wants a person for. One enrolment per agent rather than per host, so revoking one agent's access does not take the others on this laptop with it.
3
Its configuration is copied
Only after the credential exists, so an enrolment that fails leaves the file untouched. The backup path is printed rather than kept quiet, because an undo nobody can find is not one.
4
The record is written
Before the configuration rather than after it, so a process killed between the two leaves something that knows what to undo, pointing at a backup that is already there.
5
One entry is added
A single MCP server named memnox, carrying the workspace address and the credential this agent was enrolled under. Everything else in the file survives untouched: the agent's model settings, its permissions and its own servers. One fixed name, so onboarding twice replaces its own entry instead of leaving two, and so offboarding removes exactly what onboarding added.

Taking it back out

$memnox agents offboard <agent>

Put the configuration back and take the credential away. Both halves are reported as what actually happened rather than as what was attempted.

The backup is the honest undo, because it restores exactly what was there. Where it has gone missing, only the entry onboarding added is removed, and that weaker answer is said as one: anything a person changed in that file since stays.

Interposed, or advisory

Two ways an agent is covered, and they are not the same product.

How it is reached

A runtime on the host

Interposed. The seams are in the path and the agent cannot not go through them, so everything it does is covered, including what it never thought to ask about. This is the stronger one and the one to install where a shell is available at all.

An MCP connection

Advisory. The agent asks, and whatever it does without asking is not covered. It is a floor rather than a gate, and it is worth having exactly where nobody can install into the host: a hosted harness, a container somebody deployed in one click, a machine you do not own.

The fleet records which of the two an agent came in on, because a number that counted a cooperating agent as a gated one is the number nobody should trust. The console names an advisory connection as advisory on the approval screen and on the row afterwards, for the same reason.

Saying something to one while it works

$memnox agents control [agent]

Collect what an operator has said to the agents on this machine, one agent or all of them. Named turns, with who said each and when.

From your team's channel this is /memnox tell <agent> <message>. A turn is written before it is delivered, so an agent that reconnects is still given what it missed and somebody can ask afterwards why it did that.

Three properties hold that up, and each is a way it would otherwise go wrong. The machine asks, so nothing dials a laptop and the seam still runs one way. A turn is handed over once, so it is printed before it is acknowledged: the worst case is then a receipt nobody recorded rather than an instruction nobody saw. And what is acknowledged is received, never done, because acting on it is whoever is at the agent.

Connecting to a workspace

What memnox login writes, and exactly what crosses the wire.

What can already act here

The scan these commands read, and what it finds.

Is this actually working

How much of what an agent can do is actually governed.