Prerequisites
Before considering a kill switch, arrange the permissions, environment, and resources you hand an agent so that even a full compromise causes no serious harm. Agent Platform covers the full list, and four points matter most for a kill switch.- Sandbox isolation and network allowlists, so a malfunction cannot spread to other environments
- Permissions granted under least privilege, with the blast radius of every tool identified and minimized
- Recoverability of resource changes tracked and preserved at all times
- Layered audit logs covering input and output, tool execution, and network traffic
Design it as an independent control plane
The phrase kill switch suggests a single button, but what you actually build is a control plane outside the agent that handles detection, judgment, enforcement, evidence preservation, and rollback. Telling an agent in its system prompt to stop under certain conditions carries no force, because a model can probabilistically ignore an instruction in its context. The stopping mechanism has to live in the platform that runs the agent. The control plane stands apart from the agent itself and governs both the agent and its external integrations. It has to satisfy at least three principles.- Non-bypassability, meaning every agent action and every external integration sits under the switch and none of it can route around
- Unreachability, meaning the control plane lies outside what the agent can observe or operate, so the agent cannot alter the control mechanism
- Fail-closed behavior, meaning that if the control plane stops or gets partitioned, the agent stops rather than continues
Stage shutdown across scope and severity
A blanket process kill hits other users when the agent is serving requests from multiple people, and it leaves side effects such as work interrupted mid-flight and external API calls left unhandled. Design shutdown in stages along two axes instead. For scope, provide granularity at the level of an individual run, a specific agent, a specific tool or destination, and everything, then work containment from the smallest effective range outward. For severity, provide stages such as heightened monitoring, escalation to human approval, read-only mode, refusal of new actions, credential revocation, and network cutoff. When stopping a whole session costs little, stop at the run level. When a full stop would be too disruptive, an intermediate stage such as forcing read-only mode keeps the agent alive while preventing further damage.Build triggers from deterministic and non-deterministic checks
You can give users a button they are free to press, but leaving the stop judgment and its timing to a human is genuinely hard. Agents running in the background are barely visible, so pressing a button is not even an option. Implement trigger conditions as automated checks, combining deterministic and non-deterministic ones. Deterministic checks are rules a machine can evaluate, such as refusing a specific tool called with specific arguments, blocking traffic to a destination outside the allowlist, or stopping once execution counts or resource consumption pass a limit. Non-deterministic checks include step-by-step evaluation by a monitoring agent and anomaly detection over output content and behavioral patterns. They catch the unexpected, but the judgment takes time and produces both false positives and misses. Timing matters too. Detect an anomaly before a tool call runs and you prevent the damage. Detect it after and you are too late. When the agent’s natural language output is itself the harm, and streamed output is always visible to the user, the content is already public by the time you detect anything. Agents handling sensitive data such as personal information must not stream straight through to the user. You need buffering or delayed display so a check can run in between, and that means accepting a tradeoff between safety and UX.Layer enforcement with different response times
Revoking permissions on an external service or invalidating credentials can take five to ten minutes to show up in how that service handles API calls, so revocation alone does not stop the agent right away. Resources can still be affected in the meantime, so enforcement needs layers with different response times.- Refusal at the tool gateway stops the tool from running and prevents the resource operation immediately
- Credential revocation carries propagation delay, so treat it as a way to prevent later resumption rather than an immediate stop, and use it when a serious incident calls for a sustained halt
- Network cutoff works as the last resort against traffic that goes through commands rather than tools
Record tamper-proof evidence ahead of time
Without audit logs you cannot identify the resource changes that were half-applied or investigate how far the impact reached after a stop. The evidence that answers these questions has to be recorded before you ever need it.- Which input or instruction started this run
- Which tools were called, with which arguments, and how far they got
- Among external APIs already called, which completed, which are in flight, and which have unknown results
- Which resources changed, and whether each can be rolled back