Six Agents, One Name: Stopping an AI Agent Swarm, and Proving You Did
It is Cybersecurity Awareness Month, and the question we keep hearing from teams running AI agents is a simple one. When one agent becomes six, who do you stop?
An orchestrator hands a task to three workers. One of them spawns two more. Six identities exist, six keys sign, six audit trails fill up. And every question that matters in an incident is about the six together. What have they spent between them? How deep did the delegation go? Who authorised the fourth hop? Can you stop all of them in one action, and how long did that take?
Every identity standard we have implemented names the agent. None of them names the group. SPIFFE names a workload. OAuth and delegation chains name a lineage of grants. The A2A protocol has a context id for a conversation but no notion of a set of agents, and MCP has no group at all. So "stop the swarm" turns into "find every agent by hand", and "the swarm's budget" turns into "add up whatever each one happened to spend".
We wrote the whitepaper because we had to solve this for ourselves. On 9 October we audited our own runtime and found that our kill switch stopped the agent you pressed it on and left every agent it had delegated to running. That audit is written up here. The fix needed a new kind of identity, and once we had it, nine more controls followed. The paper is the account of all of them, with a column for what each one does not bound.
Give the group a name the agents cannot choose
The first move is the one everything else hangs on. The server that sees a delegation happen mints an identifier for the group at that moment, every member inherits it when it joins, and each member records which agent it joined under. No request can set it. The runtime then stamps it onto every decision, every audit event and every shared-memory write, so a budget, a behaviour rule, a kill switch and an attestation all have something to point at.
Membership is exclusive, so an agent belongs to one group at a time, and the tree can be walked from parent pointers without trusting any message passed between agents. That last part matters more than it sounds. A compromised orchestrator can lie about who its workers are. It cannot lie about who the server watched it delegate to.
Enforce the charter, do not document it
A charter is the set of limits a group lives under: how deep delegation may go (we default to three layers), how many children one parent may have, how many members may be active at once, and how long the group lives. The point is where the check runs. It runs at the moment of each join and each resume, under a lock, so a burst of parallel spawns cannot overshoot a cap. A charter that is reviewed afterwards is documentation. Lowering a limit refuses the next join rather than evicting running work, and every refusal is logged with the limit that refused it.
Budgets that conserve
A worker's share of the group's token budget comes out of its parent's share. At every node, what has been granted to children plus what the node spent itself can never exceed what it was given, and the check happens when a grant is made, not when it is exceeded. Every charge mints a receipt signed with our platform key and chained to the one before it, so a third party can verify the spend without replaying anything. That is the honest alternative to the deterministic-replay promise observability tools cannot keep.
What "stopped" can honestly mean
Suspending the root now suspends every member reachable through delegation links and parent pointers, expires their cached verdicts, and sends each one its own Shared Signals event. Reactivating the root brings back exactly the agents that cascade stopped, and leaves alone any agent an operator suspended on their own. Revoke is permanent.
For every stop we record a platform-signed measurement: when the order arrived, when the last covered agent flipped, how many were affected, with p50 and p99 across the month. And the record says what it does not cover. A model call already in flight at a provider, a webhook already queued, a task already handed to a system we never see are not ours to stop, and the signature does not pretend otherwise.
Before settling the semantics we read Zhu and Wang's paper on root-scoped authorization quiescence. Their rule is the one to keep. A stop has three honest verdicts, quiescent, not quiescent and indeterminate, and nothing short of evidence turns the last two into the first. Not a timeout, not retry exhaustion, not the agent saying it has stopped. Our unanswered escalations time out as denied, never as approved, for the same reason.
The human side
A swarm raises escalations faster than one agent does, and past a certain rate people stop reading and start clicking yes. So a group now carries an attention budget, the number of escalations per hour it may ask a person to read. Past it, further escalations are denied unread or the group is suspended. Each operator carries a cap on approvals per hour. And every approval is signed over one canonical line with an algorithm field, so a phone-held key, our platform key and a guardian agent's key all produce evidence of the same shape.
Two numbers to ask any vendor for
If you take one thing from the paper, take this. The hardest question you can put to anyone selling agent governance is "show me", and two measurements have been the cheapest for us to produce and the hardest to argue with.
Kill-switch propagation. For each stop, the signed interval between the order arriving and the last covered agent being refused, with p50 and p99 over 30 days, plus the observed delivery time to your identity provider. A vendor who publishes this with its boundary statement has told you exactly what their kill switch is. A vendor who will not has told you something too.
Attention utilisation. For each group, escalations per hour against the budget a person can actually read, the median time to a verdict, the mean time between escalations, and the fan-out estimate after Olsen and Goodrich. A group whose utilisation sits above one is being rubber-stamped, whatever the policy says.
What we do not claim
Every control in the paper was built to pay for itself on single agents as well as on swarms. We do not claim to prove an agent has stopped acting in the world; we prove our gate refuses it from a stated moment. And we have one gap we have not closed: an agent that holds an independent authorisation from a second root is suspended with the first and has to be reactivated by hand. The paper says so.
The whole thing is six pages. It is free, in exchange for an email, and you may share and quote it with attribution.
If you run agents that delegate to other agents and want the two numbers above for your own swarms, write to hello@vorim.ai.