A kill switch is a control that stops an AI agent, or one of its capabilities, from taking any further action immediately, without a code change or a release. A good one is owned by a named person, works in seconds, leaves the agent's records intact and is tested before it is ever needed.
Why does a kill switch matter once agents act?
Agents work at machine speed. If an agent starts sending wrong letters or preparing payments from a corrupted source, every minute of delay adds more of them. The question in an incident is not whether the team can fix the agent; it is whether they can stop it before they understand what went wrong.
It also changes who can intervene. If stopping an agent needs an engineer to redeploy, the business owner who spots the problem has to find one first. If the owner can stop it from where they review its work, the gap between noticing and acting closes.
How does a kill switch work in practice?
A useful kill switch has a few properties:
- Granular. It can stop one capability (sending refunds) while leaving others (reading accounts, drafting replies) running, or stop the whole agent.
- Outside the model. It is enforced where actions are checked, not by asking the model to stop. A model cannot be relied on to obey an instruction to halt.
- Fast and simple. One action by an authorised person, effective on the next attempted action.
- Recorded. Who pulled it, when, why, and what was in flight.
- Reversible with care. Turning the agent back on is a decision with its own approval, not an undo button.
Actions already held for a person stay held. Actions already executed are not reversed by the switch; that is a separate decision for the incident team.
What does an example look like?
A collections agent at a consumer lender sends payment reminders at depth 3. On a Monday morning, the arrears manager sees reminders going to customers who agreed repayment plans last week; the plan data feed has stalled. She suspends the agent's "send reminder" capability from the operations view. The agent keeps reading accounts and drafting, so nothing is lost, but every reminder is now refused at the moment of action and the verdict names the suspension. Once the feed is fixed, the capability is turned back on with the collections lead's approval.
How is it different from switching the model provider?
The two are often confused during incidents. A kill switch stops the agent acting. Changing the model behind the agent changes how it reasons, and is a planned change that needs the agent re-tested before it acts again at the same depth. If a model provider has an outage or its model starts behaving differently, the first move is usually the kill switch, or a drop to depth 1, while you decide whether to move. How to keep your bounds, records and certification intact through that move is covered in switching model provider without losing control of an AI agent and in how to switch model providers without starting again. The point that links them: the stop should live in the governance layer, so it works the same whichever model sits underneath.
Which terms sit close to a kill switch?
Suspension is the act of using it on an agent or capability. Depth 1 is the fallback state: the agent can still read, but not act. Withheld is different: it is a permanent platform refusal of certain actions for every agent, not an emergency stop. Our guide to agent governance shows how the stop fits with the other controls.
Questions people ask
How often should a kill switch be tested?
Often enough that nobody is surprised when they use it for real. Test it when an agent first goes live, after any significant change, and as part of regular incident drills, and record each test.
Who should be allowed to pull it?
The agent's business owner, the operations lead on shift and the incident lead at a minimum. The list should be short, named and known, and pulling the switch should never need a second approval.