If the model can ignore it, it’s not a kill switch. It’s a suggestion.
Parent halt with children still running isn’t containment.
Real kill switch: outside the model loop, tool-gateway block, propagates the full run graph.
Can’t prove the subtree stopped = didn’t kill.
What an AI agent kill switch is
An AI agent kill switch is an out-of-band control plane — outside the model’s prompt and reasoning loop — that deterministically blocks further agent actions. Its stop state is checked by the runtime and the tool gateway before an action executes. It can revoke or isolate credentials. It records who stopped what, at what scope, and why.
The model does not get a vote.
That matters because production agents are not chat UIs. Once they retrieve context, call tools, write to systems, and hand work to other agents, they sit in the privileged runtime layer — identity, permissions, policies, and revoke authority have to live around the model, not inside it. A kill switch is the emergency edge of that control plane: when something is already wrong, you need stop to mean stop without waiting for the model to cooperate.
If cooperation is required, you built a suggestion.
What is not a kill switch
A prompt that says “stop if unsafe” is not a kill switch. The model can ignore it. Children never saw the change.
A UI button that flips a flag in the orchestrator but never hits the tool gateway is not a kill switch. New tool calls can still land.
Killing the parent process while child runs keep their own sessions and tokens is not a kill switch. You stopped a process. You did not contain the graph.
A feature flag with a multi-minute cache is not a kill switch either. By the time every path notices, the damage is already in flight.
Soft pause is useful. Soft pause is not kill. Soft pause is recoverable quarantine — suspend the thread or queue, resume later. Kill is emergency containment: block new high-impact actions, revoke grants, audit the subtree. Circuit breakers and writes-disabled degrade sit in the same family as pause; they reduce blast radius. They still fail the containment test if descendants keep acting under live credentials.
Kill switch vs soft pause vs prompt instruction
| Mechanism | Where | Model can ignore? | Contained if children exist? |
|---|---|---|---|
| Prompt instruction | Prompt | Yes | No |
| Soft pause | Control plane | No, if enforced at choke | Only if every descendant checks it |
| Kill switch | Control plane + gateway | No | Only if stop propagates + creds revoked |
Read the last column twice. Soft pause only contains if every descendant checks the same flag. Kill only contains if stop propagates through the run graph and credentials for the subtree are revoked — requested and confirmed.
Parent halt ≠ containment
Delegation is where most “we killed it” stories quietly fail.
When a coordinator spawns specialists, those children often get their own run IDs, sessions, and short-lived tokens. They do not inherit stop unless you built lineage and a governance check on every child path. Without explicit stop propagation, the failure mode is this: you halt the parent, the children keep writing, emailing, or spending under grants that are still live.
Stop is a graph operation, not a process kill.
The same gap shows up as delegation leakage and non-interruptible execution: a handoff that silently expands authority, or a long workflow you cannot interrupt mid-path. Boundaries constrain what an agent may see, call, and change. A kill switch is what you use when something already crossed — or when you need the whole subtree drained before the next tool call lands.
If policy lives only inside the orchestrator’s own code path, children that never re-enter that path never see the stop. That is not an edge case. That is the architecture.
How a production kill switch must propagate
Treat kill as a graph op. Minimum bar:
- Lineage at spawn. Every spawn records parent run ID → child run ID. No edge, no containment. You cannot drain a subtree you never tracked.
- Dual choke. Consult kill in the agent runtime and in the tool gateway before execute. One check the model can talk past is a suggestion with better branding. The gateway is the final enforcement point: once a kill is set, it must deny new high-impact actions.
- Subtree drain + revoke. Targeting the parent marks all descendants draining or stopped. Revoke tokens and grants for parent and children. Log confirmations, not only requests. Order matters: block new actions for the entire subtree first, then propagate cancellation and revoke its grants. Do not wait for cooperative draining before enforcing the block.
- Block-new vs cancel-in-flight — be honest. Blocking new actions is the hard requirement. Canceling in-flight tool calls is best-effort. Long calls may still complete. Plan compensation or rollback for side effects that already landed. Pretending cancel is synchronous is how teams invent a false sense of stop.
- Fail closed. If the kill store or policy service is unreachable, deny new high-impact actions. Do not fail open into autonomy because the control plane hiccuped.
- Audit. Record actor, scope, reason, timestamp, affected run IDs, and revoke status (requested vs confirmed). If you cannot answer those fields after a stop, you do not have operational kill — you have a button.
Shipper checklist for the same bar:
| Check | Pass |
|---|---|
| Lineage | Every spawn: parent → child run ID |
| Dual choke | Kill read in runtime and tool gateway |
| Graph kill | Parent target drains all descendants |
| Revoke | Parent + children tokens; confirmations logged |
| In-flight | Cancel best-effort; compensate landed side effects |
| Fail closed | Kill store down → deny high-impact actions |
| Audit | actor, scope, reason, run IDs, revoke status |
| Drill | Prove children stop — only publish measured numbers |
Framework-agnostic: single chokepoint for actions, kill flags at the scopes you need (run / tenant / global / tool / writes-disabled), short TTL on any cache in front of the kill store, gateway duplicate check, lineage registry, credential revoke, audit fields, and a drill that actually proves children stop. Do not publish a latency number you have not measured.
Proof you killed
If you cannot show every descendant stopped and revokes confirmed, you did not kill.
“Parent status = stopped” is not proof. Proof is: every child run ID in the lineage received the stop, no new tool calls passed the dual choke for that subtree, and revoke confirmations are logged for every grant that subtree held.
That is an observability problem as much as a control problem. Stop without reconstructability is an opaque halt. Observability without stop is forensics after the fact. You need both: traces that tie kill events to the execution graph — session IDs, tool-call lineage, policy decisions, side-effect IDs — so you can answer what ran after the flip and what did not.
Drill the graph. Prove children stop under your own measured SLO. If you do not have a measured number, do not invent one in the runbook or the blog.
Where this sits
Kill is the emergency layer on the production control plane. Identity, permissions, and revoke authority reduce how often you need it. Execution boundaries constrain the path while the agent is still acting. Observability proves what stop actually did. Least privilege and approval gates shrink the blast radius. Kill still has to exist — and it still has to propagate — for the moment boundaries were not enough.
FAQ
Does a kill switch cancel in-flight tool calls?
Best-effort only. The hard requirement is blocking new actions at runtime and the tool gateway. Long calls may still complete; compensate or roll back landed side effects. Do not claim synchronous cancel unless your stack actually provides it.
Should I soft-pause first or hard-kill?
Soft pause when you need recoverable quarantine and every descendant checks the same flag. Hard kill when you need emergency containment: block new high-impact actions, revoke grants across the subtree, audit. Soft pause that orphans children is not safer — it just fails quieter.
Can killing one agent leave others running?
Yes, unless kill is a graph operation with lineage. Child runs with their own sessions and tokens can keep going until the subtree is marked, the dual choke denies them, and their credentials are revoked and confirmed. Sibling runs are outside that subtree unless you target a shared ancestor or a broader scope.
Does a markdown policy file (or “KILLSWITCH.md”) count as a kill switch?
No. A file the model is asked to read is still inside the suggestion loop. A kill switch lives outside the model loop and is enforced at the runtime and tool-gateway chokepoint whether or not the model cooperates.