Agent revocation and kill switch
A kill switch that has never been tested is a belief, not a control. Revocation has to answer three questions with evidence: how fast authority is actually withdrawn, what happens to work already in flight, and how you prove the agent stopped.
Get an Agent Trust Gap BriefWhy "we can turn it off" usually is not true
Most teams believe they can stop an agent. What they usually have is the ability to stop the orchestrator. Those are different things, and the gap is where incidents extend from minutes into hours.
Three gaps show up almost every time. Tokens the agent already holds remain valid until they expire. Actions already handed to a provider continue to execute. And queued work resumes the moment the process restarts, because the queue was never part of the stop.
A revocation control that does not address all three is a pause button described as a kill switch.
The four properties a real kill switch has
| Property | What it means | How you test it |
|---|---|---|
| Propagation time | How long between pressing stop and the last permitted action being refused. | Measure it. Press stop under load and record the timestamp of the final accepted action. |
| Blast radius | Exactly which effects stop and which continue. Stopping everything is sometimes worse than stopping precisely. | Enumerate before the incident. During one, nobody has time to work it out. |
| In-flight handling | What happens to actions already dispatched to a provider — completed, cancelled, or left indeterminate. | Deliberately stop mid-action and record the outcome. Indeterminate is an answer, but it must be a known one. |
| Evidence of stop | A record proving the agent had no authority after time T, not just that a process exited. | Refusal receipts after the stop timestamp. Silence is not proof. |
Revocation is an identity problem before it is a runtime problem
If an agent's authority is a long-lived credential, revocation depends on whatever consumes that credential noticing it has been withdrawn. Short credential lifetimes plus a checked revocation list beats a long-lived token and a hopeful API call, every time.
- Short-lived credentials by default. The natural expiry becomes your worst-case propagation time, which turns an unknown into a number.
- Revocation checked at the effect boundary. The component that actually sends, pays or writes checks authority — not the agent, and not only the orchestrator.
- Scoped stops, not just a global one. Stop this agent, this action class, this integration. A single global switch is used late because using it is expensive.
- Refusal receipts after the stop. The evidence that revocation worked is a record of attempts being refused, not an absence of logs.
- Rehearse it. An untested kill switch fails in the exact conditions it exists for, because those are the conditions nobody simulated.
Common questions
What is the difference between a kill switch and revocation?
A kill switch stops execution. Revocation withdraws authority. Stopping the process without revoking credentials leaves an agent that can act again the moment anything restarts holding those credentials.
How fast should revocation propagate?
Fast enough that the worst action in your blast radius cannot complete within the window. That makes it a per-deployment number derived from your action inventory, not a universal target.
What happens to in-flight actions?
It has to be decided in advance: completed, cancelled, or explicitly indeterminate. Indeterminate is acceptable if it is known and documented — it is a failure only when it is a surprise.
How do you prove an agent stopped?
Refusal receipts after the stop timestamp. Absence of activity proves nothing, because absence is also what a broken logger looks like.
Should the kill switch be global or scoped?
Both, with scoped as the default. Global switches get used late because the cost of using them is high, and lateness is the whole problem.