What changed under you

Yesterday everything worked. Today an agent can reach something it could not, and nobody remembers granting it.

The causes are ordinary: a new MCP server, a credential that appeared, a permission somebody widened, a tool an update added. None of them announced itself, and the first sign is usually an agent doing something surprising. Two commands make the change visible instead, and a third answers the version of the question where the surprise is another agent rather than a configuration.

What moved since last time

A scan can be kept, and a later one compared against it.

memnox scan --save          # keep this scan as the baseline
memnox scan --since 1d      # what has moved since

CHANGES SINCE  2026-09-04T08:14:02.118Z
 
  + Slack MCP «server»              8 tools, 3 write-capable
      ~/.cursor/mcp.json
  + AWS credential «secret»         reachable by 3 agents
  - Postgres MCP «server»           removed
 
2 changes widen authority, 1 narrows it

The last line is the one to read. A change that widens what an agent can reach is a different kind of event from one that narrows it, and collapsing the two into "3 changes" would bury the only half that matters.

Every field says where it came from. A capability with no grantedBy line is one the scan could not attribute, and it says so rather than guessing.

While you work

diff answers when you ask. watch answers when it happens.

memnox watch

⚠ NEW MCP SERVER
 
  stripe
 
  14 tools, 5 write-capable
 
  No rule covers any of them.

It wakes on a change to an agent's configuration rather than on a timer, so a server added mid-session shows up in seconds; --interval is the backstop, not the mechanism. What it reports is the same set diff reports, one event at a time: new servers, new write-capable tools, credentials that became reachable, and agents that updated themselves.

The daemon notices it for you

watch answers while it runs in a terminal. The daemon answers whether or not anybody started anything: every pass, it takes the same comparison watch makes against a baseline of its own, at most once every thirty seconds, so one save is one look. It never starts an MCP server to do it and never writes into the scan history scan --since reads.

Drift raises one desktop notice per kind of change, never more than three a pass. Every change the daemon makes and every drift it finds is also written to the ledger as a config row, naming the file and a before and after in words.

memnox timeline      # config changes appear among the actions, in order
memnox why <id>      # one of them, with what it was before and after
memnox trace <id>

Config rows stay out of budgets, next, report and collisions, because a config change is not agent work. They also stay on the machine rather than reaching a workspace: the control plane would read an action row as a capability the agent holds.

Agents that stopped working and kept their reach

An agent is dormant when it has been known for thirty days, still holds a write tool, a credential or a hook, and no ledger row names it in that time. memnox status shows a dormant row, memnox explain <agent> says so, and the daemon mentions it once per stretch of silence. Standing authority with no work behind it is reach nobody would miss.

Unusual, even where the rules allow it

A rule set answers what an agent may do. It cannot answer whether this is something the agent has ever done. Three signals turn an allowed action into an ask, read from local state and decided by a table rather than a model, so the same facts answer the same way on replay.

Like every other ask, these bite in enforce. In observe and advise the action runs and the ledger keeps what enforce would have said. Two settings control them:

memnox config set noticeWarmupDays 7    # days after setup that novelty only records (default 3)
memnox config set noticeUnusual false   # turn all three off

When the surprise is another agent

The other thing that changes under you is not configuration. Cursor is writing a feature in one directory while another agent refactors the layout underneath it, and nothing crashes and nothing is denied, because each did exactly what it was asked. The developer finds out at git status.

memnox collisions --days 7

TWO AGENTS IN ONE FILE
 
  !  src/billing/invoice.ts
     cursor        writing  2026-09-05T09:12:44.019Z
     claude-code   writing  2026-09-05T09:14:01.882Z
 
TWO AGENTS BUILDING ONE THING
 
  !  cursor and codex-cli  since 2026-09-05T08:40:12.004Z
     src/billing, src/billing/plan.ts
 
Reported, not refereed — which one should stop is your call.

That last line is the design. Deciding which agent should stop is a claim about somebody's work that nothing here can make, so the two are named with what each touched and when, and the judgement stays with a person.

Why this is separate from discovery

Discovery answers what can act here, and it is true the moment you run it. This page answers what is different, which needs two readings and a saved baseline.

The distinction matters when somebody asks why an agent did something new. A scan says what it can reach now. A diff says what it gained, and when, and from which file, which is the answer to the question actually being asked.