The AI agent kill switch: containment without evidence is not control

Every vendor selling into this space now has a kill switch slide. Revoke the token, freeze the session, take the fleet dark. What almost none of them show is the second half of the sentence: after you pull it, can you tell a board, a regulator or your own incident review what fired, what it stopped, and who authorised it.

A kill switch that leaves no record of why it triggered, what state the agent was in, and who pulled it is not a control. It is an outage with a story you will have to reconstruct from memory. Containment and evidence are the same problem, not two projects on different roadmaps, and the rest of this article treats them that way.

What "kill switch" has to mean

The phrase gets used loosely, so it is worth separating three scopes that require different mechanisms.

Agent level. Stopping one running agent: terminate its process or session, revoke its credentials, and prevent it from issuing further tool calls.

This is the scope most vendor marketing means when it says "kill switch," and it is the one CSO Online found least mature in practice: one CTO quoted in its coverage of agent kill switches said flatly that "none of the vendors are really providing that, not even Anthropic," describing manual disable-and-terminate as something teams have to build themselves rather than buy (CSO Online).

Tool-class level. Stopping a category of action across every agent that can invoke it: no agent anywhere in the estate may call the payments API, the code-deploy pipeline, or an external email send, regardless of which agent asked.

This is a scoped block, not a shutdown, and it is usually the correct first response to a suspected compromise because it preserves everything the agent was doing that had nothing to do with the risky capability.

Estate level. Taking every agent in an organisation offline. This is the option that gets the most attention and is used the least, because the blast radius of the stop is often worse than the blast radius of the incident it is answering.

The NCSC's August 2026 guidance on agentic AI is blunt about needing this option in reserve regardless: organisations should retain the ability to "pull the plug" immediately, meaning stopping processes, restricting network access and interrupting agent-to-model communications rapidly (NCSC, Managing the cyber risk of agentic AI).

A programme that only has one of these three scopes will reach for the wrong one under pressure: agent-level tools get used at estate scale because nothing narrower exists, or estate-level shutdowns get avoided because the cost is too high, leaving a compromised agent running.

Halt semantics: what actually has to stop

"Stop the agent" is not one instruction, it is at least three, and skipping any of them leaves a gap.

In-flight actions. A tool call already dispatched to an external API does not roll back because you killed the session that issued it. If the agent had just triggered a payment, a deployment, or a delete, that action is either already committed or in a state your halt mechanism needs to know how to check and, where possible, cancel or compensate.

Killing the process without checking in-flight state gives you the comfort of a stopped agent and an uncontained action still executing.

Queued work. Orchestration layers hold work the agent has scheduled but not yet started: follow-up tasks, sub-agents it spawned, retries queued after a transient failure. A halt that only touches the running process leaves this queue live, and it will resume the behaviour you just stopped as soon as something picks it up.

Credential revocation. The agent's session token, API keys, and any short-lived credentials it minted for sub-tasks need to be invalidated, not just have their calling process killed. An agent with a still-valid credential is contained only until something else, including a retry job or a copy of its own output, uses that credential again.

Halt semantics that only cover the first of these three are the most common gap in kill switch designs, because "stop the process" is the easy 80% and the queue and the credentials are the unglamorous 20% that actually determines whether the agent is contained.

Proving the halt took effect

Firing the kill switch is an instruction, not an outcome. The instruction can be dropped, delayed, or partially applied, particularly across a distributed agent estate where the halt has to reach an orchestrator, a credential store, and however many tool integrations the agent was mid-call with.

Proving containment means checking, not assuming: that the agent's credentials are confirmed revoked at the issuing system, not just requested; that no new tool calls appear under its identity after the halt timestamp; and that queued or scheduled work tied to it has been cancelled rather than merely paused.

Without that check, "we hit the kill switch" is a claim, not a fact, and it is exactly the kind of claim that falls apart under a post-incident review when someone asks how you know it worked.

The evidence record of the trigger

This is the part the SERP for this topic mostly skips. Plenty of writing on kill switches covers the mechanism of stopping; almost none of it covers what you need to have recorded about the stopping itself.

A Forbes Technology Council piece arguing against treating kill switches as a governance strategy makes a related but different point: that most organisations cannot inventory their agents well enough to know a kill switch is needed, and that emergency shutdown is "only the last mile of agent governance" (Forbes). That is a fair criticism of kill switches as a whole strategy.

It still leaves the last mile itself unaddressed: when the switch does fire, what does the record need to contain.

At minimum, an evidence record of the trigger needs the detection signal that caused the halt (which policy, threshold or anomaly fired), the exact scope that was halted (which agent, which tool class, which estate segment), the timestamp and sequence of the halt reaching each affected system, and the identity of the human or automated approver who authorised it.

Without this, you cannot answer the three questions any serious post-incident review or regulator will ask: why did it fire, what did it actually stop, and who is accountable for the decision. A kill switch without this record is indistinguishable, from the outside, from a system that just crashed.

Test it before you need it

A kill switch you have not fired outside of a drill is a kill switch you do not actually know works.

Test at all three scopes: kill one agent's session and confirm its credentials are dead within your target window; block a tool class and confirm every agent that tries it is refused, not just the one you tested against; and run a full estate halt in a controlled window and confirm the queue drains rather than resuming on restart.

Each test should produce the same evidence record a real trigger would, so the first time you generate that record is not during an actual incident.

Where regulation already points this way

The EU AI Act's Article 14 on human oversight requires that high-risk AI systems let the people responsible for oversight "intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state" (EU AI Act, Article 14(4)(e)).

"Safe state" is doing real work in that sentence: a halt is only compliant if the state it leaves the system in is one someone can inspect and account for afterwards, which is an evidence requirement, not just a stop requirement.

The NCSC's agentic AI guidance points the same direction from the security side rather than the compliance side.

Its earlier post on adopting agentic AI is explicit that responsibility has to be assigned before deployment, including "who can stop it," and states plainly that "if you cannot understand, monitor or contain an agent's actions, it is not ready for deployment" (NCSC, Thinking carefully before adopting agentic AI).

Its August 2026 follow-up ties this to logging directly, recommending immutable logs and captured chain-of-thought traces so agentic activity can be reviewed like any other privileged user activity inside a security operations function (NCSC, Managing the cyber risk of agentic AI). Neither document treats the stop and the record of the stop as separable.

How Quox handles this

Quox's approach treats the trigger, the halt and the record as one mechanism rather than three. Practically, that is two named controls: E-STOP halts a single agent and DEFCON RED steps the whole instance down, enforced server-side at every dispatch chokepoint, killing live loop sessions at the turn boundary, and failing closed if the halt store is unreachable.

Only a human administrator can set or release either one, an agent cannot reason its way past its own shutdown, and the trigger and release land in the same evidence trail as the actions they stop.

Alongside them, AOCL gates hold actions for named human approval before they execute and fail closed, a policy deny hard-stops the node, a breached budget blocks the next run before it starts, and the loop-stuck detector kills a wedged live session. Our machine-readable facts file (explained at /for-ai) carries each of these as a dated, source-cited claim, including the one dispatch path not yet gated.

VOLT produces evidence bundles for what happened, and those bundles verify offline, so proving a halt took effect does not depend on trusting the same live system that was just contained. WARD publishes signed hash-chain tips to external witnesses, so the record of a trigger cannot be quietly edited after the fact by whoever is trying to explain it away.

These four protocols, AEE, AOCL, VOLT and WARD, are currently filed as IETF Internet-Drafts: individual submissions, not standards, carrying no IETF endorsement, and due to expire on 4 March 2027 unless refreshed. That is the honest state of where this sits today.

What they describe is a way of making sure that when something gets stopped, the answer to "why, what, and who" already exists rather than needing to be reconstructed afterwards.