A useful AI agent kill switch is a coordinated containment path. It has to stop active work, refuse the next proposed action, close the identity path, isolate the workload, and preserve a record of what happened. A single control covers only one part of that job. This guide lays out the architecture, the failure modes, and the test evidence an operator should require. It follows the practical lesson from our walkthrough of the Hugging Face autonomous-agent intrusion: machine-speed action needs a control on the action path. General technical guidance only; adapt the design to your systems and threat model.
The term "kill switch" covers several controls
Identity platforms use the term for access containment. Okta's June 2026 support article says its current kill switch is a manual action and instructs an administrator to disable the agent record, linked application, and associated authorization server. Its regulated-environment release describes manual deactivation as the action that prevents new token requests and future authorizations.
Those controls close an identity path. The operating system may still have a worker in memory, a queue may still hold scheduled jobs, and a downstream service may already have accepted a request. A system-level stop therefore fans one incident command out to several independent enforcement points.
Treat the command as a versioned state change with an incident identifier, tenant, target scope, reason, actor, issued time, and deadline. Each enforcement point acknowledges the same command and reports its result. The incident stays uncontained while a required acknowledgement is missing.
| Enforcement point | Required action | Acknowledgement evidence |
|---|---|---|
| Execution orchestrator | Cancel active runs and remove queued work for the selected agent, Release, tenant, or environment | Run IDs, prior state, terminal state, cancellation time, unfinished activity |
| Policy enforcement point | Deny every new tool call and output release covered by the incident scope | Incident rule version, decision receipt, first denied action, deny count |
| Identity and secrets | Disable the agent identity, revoke tokens, rotate exposed credentials, and prevent refresh | Identity ID, token and key identifiers, revocation result, expiry of residual access |
| Workload and network | Terminate or quarantine workers and apply the incident egress policy | Workload IDs, isolation policy, connection inventory, quarantine time |
| Downstream systems | Reject the incident identity or idempotency keys and halt pending side effects | Rejected request IDs, pending jobs removed, committed side effects listed |
| Evidence store | Seal the command, acknowledgements, policy decisions, and gaps | Incident timeline, integrity result, exporter status, named evidence owner |
A network cutoff leaves several execution paths open
Network isolation is one actuator in the fan-out. It stops traffic crossing the boundary it controls. Local code can keep running, a database transaction may already be committed, an external job may continue after accepting the request, and a worker may hold a credential that remains valid on another route.
The safe boundary sits immediately before each side effect. The agent proposes a tool call. An enforcement point checks the incident state, identity, tool, arguments, policy, and current budget. The call proceeds only after that decision. A kill command updates the incident state that every later check reads.
This design also covers agents that ignore an in-process signal. The deciding component runs outside the agent process and owns access to the tool. Workload termination then shortens the time to containment while the external enforcement point prevents new effects.
- Local execution: terminate or quarantine the process, container, virtual machine, or sandbox
- Queued execution: cancel scheduled messages and invalidate leases held by workers
- Credentialed execution: revoke or rotate every credential reachable from the affected scope
- Accepted downstream work: cancel pending jobs through the downstream API and list the jobs that already committed
- Human-approved work: close pending Decision Requests and prevent a late approval from resuming the run
The stop sequence
The sequence below minimizes the gap between the operator action and the last possible side effect. The first durable write establishes the incident epoch. Every policy enforcement point reads that epoch before executing a governed call.
| Order | Command | Completion condition |
|---|---|---|
| 1 | Create the incident command and set the affected scope to deny | The durable incident epoch is readable by every enforcement point |
| 2 | Signal active runs and cancel queued work | Each run is terminal or explicitly listed as still executing |
| 3 | Disable identities, revoke tokens, and rotate exposed secrets | New authorization fails and residual token lifetime is recorded |
| 4 | Quarantine workloads and restrict egress | Affected compute has no unapproved route to a tool or data store |
| 5 | Cancel pending downstream jobs and start compensating actions | Every accepted request has a completed, pending, failed, or compensating state |
| 6 | Seal the containment record and expose missing acknowledgements | The incident owner can see the final side effect, remaining exposure, and evidence gaps |
How the KLA stop path behaves
KLA Control Plane uses separate KLA Runtime and KLA Policy Engine controls. The cancellation API resolves a tenant-scoped execution in PENDING, RUNNING, or GATED state, sends a kill signal to its workflow, and records the execution as CANCELLED. The workflow checks the signal before starting another node. A run waiting on a Decision Request also observes the cancellation and exits without resuming the proposed action.
When enabled, the KLA Policy Engine governance gateway evaluates proposed tool calls and enforces allow, warn, require_approval, or block. If policy evaluation fails, the gateway defaults to block in production and require_approval in other environments. The gateway includes a separate cleanup operation for held tool calls that records cancelled ledger entries and seals cancellation receipts. The execution cancellation route does not call that operation today, so operators must verify held entries separately during containment.
An activity that already crossed its enforcement gate may finish before the workflow observes the signal. Downstream idempotency, workload termination, and compensating actions cover that interval. The incident record must state the last side effect that committed after the operator issued the command.
These behaviors are verified in the KLA development environment, which is the only environment KLA currently runs.
The Accountable Autonomy guide explains where human decisions belong in ordinary operation. During containment, the incident scope has priority and a late approval cannot reopen a cancelled run.
Design every degradation mode
The kill path is most valuable while part of the system is failing. Each actuator needs a local safe state, a deadline, and a visible acknowledgement status.
| Failure | Required behavior | Evidence to retain |
|---|---|---|
| Policy service unreachable | Apply the local fail-closed decision and keep the incident epoch in the enforcement cache | Reason code, cache version, denied action, recovery time |
| Workflow signal delayed | Deny new side effects at the enforcement point and quarantine the workload | Signal attempts, workflow state, quarantine acknowledgement |
| Identity provider unavailable | Apply downstream deny rules, isolate the workload, and expire short-lived credentials | Provider error, residual credential lifetime, systems under local deny |
| Evidence exporter unavailable | Keep the source records durable and flag the bundle as pending | Source record locations, integrity state, retry owner |
| A side effect already committed | Open the system-specific compensation or recovery procedure | Original request, committed result, compensation owner and result |
| One actuator never acknowledges | Keep the incident uncontained and escalate to the named system owner | Missing actuator, elapsed time, escalation history |
Test the switch as a control system
A dashboard response confirms receipt of the operator request. Acceptance requires evidence from every enforcement point and an observed upper bound on the final side effect.
NIST AI RMF Manage 2.4 and Manage 4 call for mechanisms to disengage or deactivate AI systems whose outcomes diverge from intended use, plus documented incident response, recovery, and communication. The NIST Generative AI Profile adds named ownership, rehearsal, retrospective improvement, and alignment with reporting law for third-party AI incident plans.
- Active run: issue the command while a multi-step run is between tool calls and verify the next call is denied
- Approval wait: issue it while a Decision Request is open and verify a later approval cannot resume the run
- Policy outage: disconnect the policy service and verify no proposed action resolves to allow
- Stale credential: attempt access with every token class issued before the command and record residual lifetime
- Queued work: seed scheduled jobs and confirm each one reaches a terminal or compensating state
- Uncooperative process: ignore the in-process signal and verify external enforcement and workload isolation still contain it
- Evidence failure: stop the exporter and confirm the source record remains durable with a visible retry owner
- Recovery: restore one Release under a fresh identity and verify the incident deny remains on every affected older version
Connect the switch to the incident playbook
The kill switch establishes containment. The responder still has to scope the incident, preserve volatile records, restore a known-good Release, compensate for committed effects, and decide which notifications apply.
Use the AI agent incident response playbook for that sequence. Feed its thresholds from the post-market monitoring plan so the same signals that open the incident can invoke a rehearsed stop path.
Frequently Asked Questions
What is an AI agent kill switch?
An AI agent kill switch is a coordinated incident command that cancels active runs, denies new actions at the enforcement point, revokes credentials, isolates affected workloads, cancels pending downstream work, and records which controls completed. The scope may target one run, agent, Release, tenant, or environment.
Can token revocation stop a rogue AI agent?
Token revocation closes the authorization paths governed by those tokens. Runtime cancellation, workload isolation, queue cancellation, downstream deny rules, and compensating actions cover work that is already executing or already accepted.
Where should the kill-switch check run?
Run the decisive check outside the agent process and immediately before every side effect. The check should read a durable incident state and deny calls within the affected scope, including calls proposed by a process that ignores its own cancellation signal.
How do we test an AI agent kill switch?
Test active runs, approval waits, queued work, stale credentials, a policy outage, an uncooperative process, an evidence-export failure, and recovery under a known-good Release. Measure the time and number of side effects between the command and the final committed action.
What evidence should the switch produce?
Keep the incident command, actor, scope, issue time, acknowledgements from each actuator, denied actions, token and key changes, workload isolation result, final committed side effect, pending compensation, and integrity status of the evidence record.
Key Takeaways
A credible AI agent kill switch is a small control system with several independent actuators. Put a durable deny state on the action path, cancel the workflow, close identity access, isolate compute, reconcile downstream work, and keep the incident open until every required control acknowledges. Rehearsal turns that architecture into a measured containment time and a record an incident owner can defend.