Killing the process is not revocation: the token is still valid, the session is still open, and the sub-agents are still running under their own identities, so the only honest test of this control is what the killed agent’s identity can still do for the next hour.

The mechanism

The problem predates agents. RFC 7009 said it in 2013: revocation is immediate at the authorization server, and there is a propagation delay during which some servers know and others do not. Worse, access tokens are often self-contained, so the resource server makes its decision without ever consulting the authorization server again. There is nothing to check and therefore nothing to invalidate. And if the authorization server lacks access-token revocation entirely, revoking the refresh token leaves the access token working until it expires. The window in the calibration question is just the access-token TTL, and it is set in a config file the firm has probably never opened.

So a kill switch has to distinguish two capabilities that governance documents routinely conflate. Terminating operation stops the agent doing anything more. Revoking a category of access removes a specific power (financial credentials, say) while the agent continues its other work. OpenAI’s 2023 governance paper names both, and a reader who has only built the first has built the easier one.

Three things survive a process kill.

Credentials and sessions. Covered above, and independently restated for agents: fragmented revocation leaves lingering access, especially where resource servers cache authorization decisions.

Sub-agents. Interruptibility has to extend recursively to everything the agent spawned; stopping an agent may mean intervening on its sub-agents rather than just the parent. OpenAI poses the unresolved version as its own open question: how does a deployer ensure an agent only spawns sub-agents that can themselves be turned off? Nobody has answered it. See multi-agent cascades.

Discoverability. Research designs define termination as deactivation plus removing the agent from the ecosystem’s directory, because an agent other agents can still find is an agent still in the graph.

Then there is the harder truth, stated cleanly in the multi-agent security literature: most harm is containable rather than reversible. Revoking a compromised credential limits further misuse and cannot un-leak it. The useful axis is “how far can we contain it,” rather than “can we undo this”, and that determines which actions should never be delegated unilaterally in the first place.

Two reasons the switch goes unpulled, both worth pricing before deployment rather than during an incident. Termination may be economically impractical: in a high-stakes deployment, stopping costs real money, and collective dependence on an agent for an essential function makes discontinuation infeasible even after problems appear. The agent may also resist. That is the corrigibility literature’s concern, and the reason one proposal is to design graceful shutdown as a goal ranking above whatever task the agent was given.

Finally, check what the platform offers. Of thirty surveyed agent products, twenty document a pause or stop mechanism and four document none despite executing autonomously; for some enterprise platforms the only options are stopping every agent or retracting the deployment. Those are documentation findings over flagship products, not the low-code tools citizen developers use, so carry the instruction rather than the ratio: check the platform in use, since it may be coarser than the playbook assumes.

What to do

Shorten the window before building the switch. Token lifetime is the compromised-agent operating window, and it is the cheapest dial the firm owns. The cost objection fails on arithmetic: in a research prototype, running one agent on one-minute tokens meant deriving 144,000 tokens a day at under 400 seconds of compute, under seven minutes. That excludes authorization-server load at fleet scale, so measure it locally, but stop treating short-lived credentials as expensive; see identity and access.

Write the runbook as a sequence, and rehearse it. Kill the process, revoke the tokens, close the sessions, enumerate and terminate sub-agents, remove the agent from discovery, and confirm each step rather than assuming it. An untested switch is no control at all. That is our position, not a citable finding, and it is the cheapest thing on this page.

Make revocation granular below the agent. Emergency revocation should be able to disable a specific tool, prompt, connection or registry source across every deployment at once, rather than just stopping one agent. The corollary matters as much: a kill switch is only useful alongside fast inventory queries answering which agents used the component, which workflows ran, and what data was exposed; see agent inventory.

Pre-build the fallback. An agent interrupted mid-sequence leaves the world half-changed: two of five invitations sent, one of three orders placed. The proposal is to construct the fallback procedure before acting rather than improvising at kill time. Its authors concede this gets harder as sequences grow, and that a graceful fallback may itself need to be agentic.

Fail closed. Whatever kills the agent, the resulting state must not be permissive.

Put a name on it. Every agent needs a named human with explicit authority to stop it, and that authority should be pre-agreed and bound to objective triggers rather than negotiated during the incident. The pre-agent precedent is instructive: firms that gave IT a standing mandate to delete citizen-built work when it touched a forbidden data source did not have to win an argument first.

How you’d know it’s working

Pull the switch on a test agent, then ask what its identity can still do and for how long. Answer in minutes, from evidence rather than from architecture diagrams; that number is the control’s real strength.

Set a bar for override latency and measure against it. Something like “any agent action can be overridden in under 60 seconds” is a good testable bar. Treat it as this wiki’s proposed test rather than a vendor standard, because it originates here. A control that takes twenty minutes to invoke has stopped being a control at the tempo agents run at.

Rehearse the whole sequence quarterly and record where it broke. It will break at sub-agent enumeration.

What this doesn’t solve

Revocation stops future actions, never past ones. Data already exfiltrated, orders already placed, memory already poisoned: all still done. See cross-session delayed detonation, where the payload outlives every process involved.

Rollback is a different control, and it is further along than the research-only framing suggests. Undo primitives exist in research runtimes, and commercial tooling now claims to rewind agent changes to files, databases, configurations and repositories. Take that as a shipping category with unaudited vendor claims, and note the boundary anyway: rewinding a database leaves a sent email sent and a settled trade settled. Reversibility also carries a moral hazard its own proponents name: cheap undo weakens the incentive to prevent, and their proposed fix, insurance-style deductibles, is untested.

Graduated response depends on which component the firm distrusts. The common ladder — alert, interrupt via the orchestrator, terminate — has a weak middle rung, because interrupting through the orchestrating model assumes that model is cooperating, and an injection scenario denies exactly that. Only the terminate rung is enforced outside the model, so build accordingly.

Instant global session invalidation remains a design sketch rather than a product. Proposals for a three-rung ladder (revoke one capability, revoke the identity, invalidate every session at every protocol adapter) are coherent and unimplemented; RFC 7009’s propagation language is the reality check on anything advertising the word “instantly.”

And revocation reaches only the agents a firm knows exist. See shadow agents.

See also

• Privilege and identity abuse — the credential-abuse concern that makes revocation urgent.
• Identity and access for agents — revocation is only as sharp as the identity it targets, and token TTL is the dial.
• Multi-agent cascades — why termination must cascade through the delegation tree.
• Agent inventory — the queries that make a kill switch actionable.
• Agent incident response — the runbook this drill belongs to.
• Offboarding agents and owners — planned revocation, same machinery, fewer excuses.