Is this actually working

Five questions you will be asked and probably cannot answer today: how much of what your agents can do is governed, whether anything is intercepting at all, how much reach is going unused, what stops an agent right now, and which agents were ever meant to be here.

How much is actually governed

The last two lines of a scan are the whole question:

memnox scan

18 capabilities can change something outside this laptop.
8 of them are governed by a policy.

Both are counts, never a score. The second is computed by matching every rule in force against every capability just listed, not by counting rule files: a file count would let the screen report a reassuring eight about rules that cover none of what it printed, which is the one lie the whole page exists to avoid.

Is anything intercepting at all

Rules alone govern nothing. A verdict nobody is obliged to ask for is advice.

memnox doctor --wiring

  ok    config        mode is observe — verdicts are recorded and nothing is denied
  ok    rules         5 rule(s) from memnox.policies.toml · v083503318b3d
  ok    interceptors  18 installed
  !     path          interceptors are installed but are not ahead of the real binaries on PATH
                      → start the agent with "memnox run -- <agent>", which sets PATH for it
  ok    proxy         all 3 MCP server(s) routed through the proxy
  ok    daemon        not running; interceptors evaluate in process, which is the same rules
  idle  ledger        nothing recorded yet, so "memnox why" has nothing to explain

This answers a different question from memnox doctor. Not "what is risky here" but "is Memnox gating anything right now", and every failing line carries the one command that fixes it.

The rules line ends in a content hash of the set in force. That is what makes "four laptops are on the same rules and one is not" answerable without diffing files.

What was granted and never used

Discovery answers what your agents can reach. After a few days of real work, the record answers something better: what they actually did, and what they never needed. Least privilege written from behaviour rather than from imagination is the strongest thing a week of history buys you.

memnox scan --usage 7d

GRANTED AGAINST USED — last 7 days
 
  14 granted    4 used    10 never touched
 
  ! 3 unused tool(s) can change external state:
      github.merge_pull_request   (~/.cursor/mcp.json)
      github.delete_repository    (~/.cursor/mcp.json)
      stripe.create_refund        (~/.claude.json)
 
  memnox protect  propose rules for what is not being used

The window is yours to choose, and it is stated in the output rather than assumed, because "unused" means nothing without saying since when.

The two numbers

The line worth acting on is the one under them: how much of the never-touched half can change something outside this machine. Ten unused read tools are clutter. One unused tool that merges pull requests is the whole reason this page exists.

Turning it into rules

memnox protect --from-usage 30d

It drafts rules for what was granted and never used, into the same memnox.policies.toml you already read, in the same format. Nothing is applied without you seeing it first.

With no history at all it refuses to call anything unused rather than drafting from nothing:

Everything reachable was used in the last 30 days.

That is the honest answer to a question asked too early, and it is better than a confident file full of denies derived from silence.

What stops one, right now

There is no kill switch, and there deliberately is not one: a command that terminated somebody's agent mid-write would cost more than it saved. What there is stops the actions, which is the part that leaves the machine.

$memnox freeze payments --for 2h --reason 'troubleshooting the database'

$memnox freeze --lift

$memnox protect --enforce

$memnox rewind

A freeze is a state fact, so a rule opts into it by naming one:

[policies.match]
actions = [ "railway.up", "vercel.deploy-prod" ]
state = [ "freeze:payments" ]
[policies.decision]
effect = "deny"
reason = "payments is frozen"

Those stop the actions on this machine. On a team, one agent is frozen on every machine at once, and every machine is moved to enforce at once, from the console or from chat; see Who acts here.

Nothing is frozen implicitly. A rule that did not name the state carries on as it was, which is what keeps a freeze from stopping the work of fixing the incident.

Which agents are even meant to be here

memnox config set approvedAgents claude-code,cursor

Anything that acts and is not on that list is reported as unregistered, and an empty list means nobody has decided rather than that everything is approved. See Configuration for the field.

What is never reported

Next