The Agent Kill Switch
Disable a tool, disable the agent, or fall back to a simpler mode — all without a redeployment, because a redeploy is too slow when an agent is doing something harmful.
The question, the obvious approach, and why it breaks
Every lesson starts where the work starts: an operational problem, a first attempt that is entirely reasonable, and the way production disagrees with it.
An agent is taking a harmful action right now. What stops it in the next thirty seconds?
Ordinary services fail by returning errors, and an error is contained: the user retries, nothing else happens. An agent fails by acting — sending messages, writing records, calling APIs, spending money — and each iteration of the loop produces more consequences while you decide what to do.
If something goes wrong, roll back. It is the standard response, it is well-tested, and it restores a known-good version.
A rollback takes as long as your pipeline takes: build or fetch, roll out, wait for instances, drain connections. Minutes at best. The agent is still looping the whole time.
- A rollback takes as long as your pipeline takes: build or fetch, roll out, wait for instances, drain connections. Minutes at best. The agent is still looping the whole time.
- The problem often is not the version. A tool has started returning bad data, an upstream dependency is degraded, or a specific input pattern is triggering a behaviour — and the previous version does exactly the same thing.
- Rollback is all-or-nothing. If one tool of eight is dangerous right now, you do not want to remove the other seven, and you may not want to remove the agent at all.
- Rollback does not undo the actions already taken. Whatever the agent did is done, and every second before it stops adds more (Idempotency in Agentic owns limiting the damage of repeats).
- In-flight requests keep running through a rollout, so the harmful loop can continue on old instances while new ones start.
What is actually happening
Underneath the tooling, which is the part that survives a change of tool.
- A kill switch is a runtime-evaluated control on the request path — a flag, a policy record, a config value read per request — rather than a property of the deployed artifact. That is the entire mechanism, and it is why it is fast (Feature Flags: Deploy Is Not Release).
- The switch must be checked at the point of action, not only at request entry. The decisive check is immediately before executing a tool call, so a request already in flight stops at its next action rather than completing its loop.
- It has levels, because harm has levels. Disabling one tool, requiring approval for one tool, capping loop iterations, falling back to a simpler non-agentic mode, and disabling the agent entirely are five different responses to five different situations.
- A fallback mode is what makes the switch usable. If the only options are "agent" and "broken", nobody will flip it early. A retrieval-only answer, a templated response, or a straight handoff to a human turns the switch from an outage into a degradation (Fallbacks, Caching and Model Routing).
- The control plane carrying the switch must not depend on the system being disabled, and should tolerate the failure of whatever serves it: a cached last-known value plus a default-safe behaviour when the flag store is unreachable.
- Propagation time is the specification. "Effective within N seconds across all instances" is the number that matters, and it has to be measured rather than assumed (A Successful Deploy Is Not Evidence of a Healthy System).
Where the switch sits on the request path
The guards are on the path, evaluated per request and — critically — per tool call. A request already in its loop hits the tool guard on its next action, which is what makes the stop fast rather than eventual.
The fallback is the branch that makes the switch usable. Without it, the only alternative to the agent is an error, and an on-call engineer will hesitate before choosing that.
Five levels, five situations
Levels exist so the response can match the problem. The last column is the one that decides whether a switch gets used early: if flipping it means an outage, people wait, and waiting is the expensive part.
Note the second row. When a tool is disabled, tell the model it is unavailable rather than letting the call fail — otherwise the model keeps attempting it and works around the refusal in ways nobody predicted.
| Level | Use when | What it does | What the user experiences |
|---|---|---|---|
| Disable one tool | One capability is causing harm or returning bad data; the rest is fine | The tool is removed from what the model can call, and the model is told it is unavailable | Slightly reduced capability; most requests unaffected |
| Require approval for one tool | The action is high-consequence and you want a human in the path, not a stop | Calls to that tool queue for human confirmation (In-the-Loop vs On-the-Loop and Escalation) | Slower for affected requests; nothing is lost |
| Cap iterations or budget | Requests are looping or costs are climbing, but behaviour is otherwise correct | The loop terminates early with a partial result or an escalation (Budgets, Limits and Termination) | Some requests end incomplete or are handed off |
| Degraded mode | The agent as a whole is unreliable but the product still needs to answer | Falls back to retrieval-only, a template, or a direct human handoff | A simpler, less capable answer — visibly degraded, not broken |
| Disable the agent | Harm is not confined to one tool and degraded mode is not trusted either | The path is turned off entirely | The feature is unavailable; the rest of the product is not |
Why a redeploy is the wrong instrument
A reconstruction of the same incident twice: an agent began issuing duplicate refunds after an upstream order service started returning stale statuses. Nothing was wrong with the deployed version, which is the detail that makes the rollback path so much worse than it looks.
The times are the whole argument. Both responses were correct decisions made by competent people; only one of them was available in seconds.
- 09:14changeUpstream order service begins returning stale statuses after its own deploy
- 09:16signalAgent starts issuing duplicate refunds; error rate unchanged, every call returns success
- 09:21signalFinance alerting flags an unusual refund rate; the agent team is paged
- 09:23actionResponder confirms the agent is behaving as designed on incorrect input
- 09:24actionPATH A: rollback started. Build fetched, rolling update begins across the fleet
- 09:24actionPATH B:
issue_refunddisabled by flag; guard denies at the next tool call on every instance - 09:24recoveryPATH B: refunds stop; agent continues answering, telling users refunds are temporarily unavailable
- 09:29signalPATH A: rollout completes — but the previous version does the same thing, since the fault is upstream
- 09:31actionPATH A: agent disabled entirely; the whole feature goes down
- 10:05recoveryUpstream service rolls back; statuses correct again
- 10:12recoveryRefund tool re-enabled after verifying statuses on sampled orders; compensation begins for duplicates issued
Path A spent seven minutes on a rollback that could not work, because the deployed version was not the problem — then took the whole feature down. Path B stopped the harm in seconds and kept the rest of the product working. The switch is not faster rollback; it is a different instrument, aimed at the action rather than at the version.
How to do it properly
Most important first.
- Build the switch as flags evaluated per request, with the tool-level check immediately before each tool invocation (Tool Permissions and Least Privilege).
- Provide the levels explicitly: per-tool disable, per-tool require-approval, iteration cap, degraded mode, full disable. One binary switch is not enough to be used calmly.
- Define and implement the degraded mode before you need it, and test that it works — a fallback path that has never served traffic will not work the first time it does (Reliability Overview: The Seven Failure Scenarios).
- Make the switch reachable by whoever is on call, without a deploy, without a code review, and without waiting for someone with special access (Break-Glass Access).
- Write the runbook: which level for which symptom, what it does to users, and how to confirm it took effect (Runbooks).
- Measure propagation. Flip a harmless switch in production periodically and record how long it takes to be effective on every instance.
- Log every flip as a change event so it lands on the incident timeline like any other change (Change Correlation).
- Fail safe: if the policy store is unreachable, the agent should fall back to the more restricted behaviour, not the more permissive one.
How much can this affect
Every production change has a blast radius. Stated as a scale so it is comparable between changes rather than adjectival — and paired with what actually contains it, because a wide scope with a real containment mechanism is a different situation from a wide scope with none.
The switch itself is what contains other failures. Its own risk is inverted: a switch that is missing, stale-cached or fails open leaves you with no fast response, and one that is too easy to flip wrongly is an outage mechanism.
What can go wrong
- The switch read at process start and cached indefinitely, so flipping it does nothing until a restart — which is a deploy, which is the thing you were avoiding.
- The flag service being down at the moment you need the switch, with the failure mode defaulting to "allow".
- The check placed at request entry only, so requests already in the loop run to completion, taking the actions you were trying to stop.
- A degraded mode that fails immediately because it has no traffic in normal operation and has silently rotted.
- Switch flips not recorded, so a mystifying behaviour change hours later turns out to be a flag someone left off.
- So many switches that nobody knows which to use under pressure, and the on-call reaches for a full disable because it is the only one they trust.
- A per-tool disable that leaves the model still being told the tool exists, so it keeps trying and every attempt returns an error the model then tries to work around.
- "Rollback is the kill switch." Rollback is minutes and all-or-nothing. A kill switch is seconds and surgical, and the two solve different problems.
- "One switch is enough." A single disable is so blunt that people hesitate to use it, and hesitation during a harmful-action incident is the expensive part.
- "The switch means we can experiment freely." It bounds the duration of harm, not its existence. Actions taken in the first thirty seconds are still taken (Canarying a Model or Prompt Change).
- "If the flag service is down we can still deploy." You can, and it takes minutes, which is the situation the switch existed to avoid. Cache the last known value and fail to the restricted behaviour.
Operating it
Evidence is the signal, not the intention. Rollback is sometimes 'you cannot, and that is the point'.
- Someone on call can disable a single tool in production in under a minute, without a deploy, and demonstrate it.
- Propagation time is a measured number, not an assumption.
- The degraded mode is exercised regularly — in a drill or by a small share of traffic — and its behaviour is known.
- Every switch flip appears in the change feed with an actor and a time.
- The switch is its own rollback: flipping it back restores full behaviour immediately. That symmetry is why it is the right instrument during an incident.
- It does not reverse actions already taken. Compensation — refunding, retracting, correcting, notifying — is separate work, and knowing in advance which tool actions are compensable is part of designing the agent (Approval Gates and Risk Classes).
- Leaving a switch off indefinitely is a silent capability loss. Every flip needs an owner and a review date, or the agent quietly degrades into a system nobody remembers crippling.
- Automate the enforcement: the check itself must be code on the path, not a convention.
- Automate hard-limit triggers where the criterion is unambiguous — a per-request or per-hour budget ceiling, a loop iteration cap, a guardrail trip rate (Budgets, Limits and Termination).
- Keep the judgement flips human. "The agent is being weird" is not a machine-evaluable condition, and an automatic disable on a noisy signal will take your agent down during an unrelated dependency blip.
- Automate the record of every flip, and a reminder for any switch that has been off for longer than its review window.
- Every switch is a code path that must exist, be tested and be maintained. Five levels is five paths, and untested paths are where the next incident lives.
- Runtime evaluation adds a lookup to the request path, which is latency and a dependency — mitigated by caching with a short TTL, which trades propagation speed for resilience.
- A powerful switch is a powerful thing to get wrong: whoever can disable a tool can also cause an outage by disabling the wrong one, so it needs authorisation and an audit trail (The Audit Trail).
- Degraded modes need product decisions — what does the user see — which is work that has to happen before the incident, when it feels hypothetical.
Where this applies
This domain is unusually tool- and organisation-dependent. These labels say what each claim is specific to, and what a different platform, provider or organisation does instead.
- GENERALAny system that takes autonomous actions needs a fast, granular stop. The requirement predates agents — payment processors and trading systems have had them for decades — and the granularity levels are the part specific to tool-using agents.
- TOOL-SPECIFICPropagation speed depends on the flag or config system: a store with server-side streaming updates propagates in seconds, while polling with a 60-second interval means a 60-second worst case. Measure yours; do not adopt a vendor's figure.
Where the depth lives
This domain teaches delivery and operation, and hands the mechanism off to the domain that owns it.