Nobody governs the action

An AI agent with tools is not a chat. It is a process that opens files, runs commands, calls third-party services and, increasingly, hands work to other agents. The moment it has effects, it stops being a question of text quality and becomes a question of permissions.

This paper describes where the gap is, what we found auditing our own multi-agent platform, and four patterns that close it. There is no product to buy in any of these pages: all four patterns can be implemented in any system, and on the last page we say what we do, in case someone would rather not implement them alone.

2 · What an agent can actually do

Before governing anything it is worth enumerating the surface. An agent with tools has five classes of effect, and each fails differently:

1. 1

   Execution

   Commands on the system where it runs. The most dangerous and the most underestimated, because it usually arrives as “a tool that runs a script”.

2. 2

   Files

   Reading and writing on the client's disk. The scope is rarely bounded: if the agent can read a directory, it can usually read its parent.

3. 3

   Network

   Outbound internet. This is the default exfiltration channel: any data the agent has seen can leave inside a perfectly legitimate request.

4. 4

   External tools

   Tool servers, today usually over MCP. The agent runs code you did not write, with whatever permissions the launching process holds.

5. 5

   Other agents

   Delegation. Permission travels with the task, and the moment there are two levels nobody knows under whose authority the last step ran.

Across those five surfaces, three failure modes appear again and again: excessive permissions granted “to make it work” and never withdrawn; prompt injection, where content the agent reads turns into commands it obeys; and exfiltration through a tool, where data leaves down a channel that was authorised for something else.

4 · Four patterns of action governance

None of the four requires any particular technology. They can be implemented on any agent runtime, and they are best implemented in this order.

1. 1

   Deny-by-default gate

   Every action with effects passes through a single point that starts by saying no. It is not a list of forbidden things — that list is never complete — but a list of permitted ones, and anything absent is refused. You verify it like this: write an action nobody anticipated, and check that it is denied without anyone having had to anticipate it.

2. 2

   Role-scoped approval

   Who may approve what, declared as rules rather than as the judgement of whoever happens to be watching the console. The operator who approves reading a directory is not necessarily the one who may approve a write to production. You verify it like this: take a high-impact action and try to approve it with the lowest role that exists.

3. 3

   Sealed chain

   Every action is recorded chained to the previous one by a signature, so deleting or editing an entry breaks the chain and the verifier flags it. That is precisely the difference from an ordinary log: you do not have to trust the record, you check it. You verify it like this: hand-edit an intermediate entry and check the system detects it and says which.

4. 4

   Fail-closed to zero

   When the permission system cannot be resolved — it is down, a rule is ambiguous, a field is missing — the agent closes down to zero tools instead of pressing on with whatever it has. It is the most frequently omitted pattern, because it contradicts the instinct that the system should keep working. You verify it like this: kill the permission service with an agent mid-task.