Can you trust an agent kill switch you have never tested?
Stopping one process may leave tools, queued actions, delegated agents and credentials active. Define the safe state, control every action path and rehearse the stop under load.
An emergency-stop button is reassuring in a design review. It is less reassuring when the agent has already scheduled jobs, delegated tasks, opened sessions and issued credentials. Stopping the orchestration process may silence the visible interface while downstream actions continue.
A trustworthy kill switch is not a button. It is an independently controlled transition from current operation to a defined safe state, with measurable time, complete coverage and a tested route back.
Define what “stopped” means for this workflow
Safe state depends on the system. For a research agent, it may mean no new external requests and preservation of partial results. For a payment agent, it may mean no new commitments, cancellation of uncommitted instructions and escalation of ambiguous transactions. For a code agent, it may mean termination of execution, revocation of repository writes and quarantine of generated artefacts.
Write invariants that an exercise can observe:
- no new tasks are admitted;
- running planners stop at the next controlled boundary;
- effectful tool calls are denied;
- queued but uncommitted actions are cancelled or held;
- workload and delegated credentials are revoked;
- child agents and sessions are accounted for;
- evidence is preserved; and
- recovery requires an explicit decision.
Do not promise rollback where the external system cannot reverse an action. The safe state must distinguish “not started,” “in progress,” “committed” and “compensating action required.”
Put the stop outside the agent’s control
The agent should not decide whether to honour its own shutdown. Use an operational control plane with strong human or automated authority over task admission, credential issuance, tool gateway and network path. The stop mechanism should work even if the model endpoint, orchestrator or primary application interface is unavailable.
The NIST AI RMF Core includes mechanisms and responsibilities to supersede, disengage or deactivate systems whose outcomes depart from intended use. That makes shutdown an operating control with owners and procedures, not a model feature.
Protect the switch from casual or malicious use. Require strong authentication, scope choices and tamper-evident logging. At the same time, avoid an approval chain so long that the control cannot meet its response objective. Pre-authorise defined incident roles and rehearse their judgement.
Avoid one shared administrative dependency. If the same identity provider, region or control database powers both the agent and its stop path, that failure may remove the means to contain it. Document a protected break-glass route, restrict and monitor its use, and test it without the primary plane. Independence is a property to demonstrate, not a claim based on a separate button in the interface.
Cover every path that can still act
Build a stop-coverage map.
| Action path | Stop mechanism | Verification |
|---|---|---|
| New user or scheduled task | Disable admission and triggers | New request rejected with incident state |
| Active orchestration | Cooperative cancellation plus forced termination | No further planning or delegation |
| Tool adapter | Central deny policy | Synthetic action blocked |
| Queues and retries | Pause consumers; cancel scoped messages | Queue inventory reconciled |
| Child agents | Revoke descendant task mandates | Child calls denied |
| External sessions | Revoke or close session | Target rejects further calls |
| Network path | Egress deny at workload boundary | Test destination unreachable |
| Credentials | Revoke workload keys and derived tokens | Replay tests fail |
The NCSC’s 2026 agentic AI guidance says emergency shutdown must cover the wider system, including restricting network access and interrupting connections between agents and model infrastructure. That breadth is important: the visible agent process is only one link.
Choose triggers without surrendering judgement
Some stops are human-triggered after an alert; others can activate automatically when a hard invariant fails. Suitable automatic triggers may include cross-tenant access, an unapproved high-impact tool call, impossible transaction volume, policy service failure or loss of audit logging. Model-judged “suspicion” may contribute a signal but should not be the only emergency condition.
Use graduated containment where possible: suspend one task, one identity, one tool, one tenant or the whole fleet. A scoped stop reduces operational harm and makes responders more willing to act. Preserve a global path for uncertainty about shared infrastructure.
Define who receives the alert, who owns the business decision, and what happens when telemetry is incomplete. A control that assumes the same compromised system will deliver a perfect alert is fragile.
Run an exercise against real concurrency
A meaningful drill runs while work is active. Seed several tasks: a read-only operation, an action awaiting approval, a queued write, a child-agent delegation, a long external request and a retry scheduled for later. Trigger the scoped and global stops without warning the executing components.
Measure:
- detection-to-activation time;
- activation-to-last-action time;
- number and type of actions completed after activation;
- outstanding tasks, sessions and credentials reconciled;
- evidence captured; and
- time and checks required for safe recovery.
Inject failures: make the queue unavailable, remove the primary operator interface, introduce clock skew, let a tool call straddle activation, and test a second region. Verify target-system state rather than trusting status flags.
Repeat the drill with ordinary operators, not only the engineers who built the mechanism. Give them ambiguous signals and require a scope decision. A technically perfect control can miss its harm threshold if responders cannot find it, lack authority to use it, or do not understand whether it will interrupt critical business work. Capture those decision delays separately from the mechanism’s execution time.
The NIST Generative AI Profile calls for incident response and recovery plans across the value chain and for communication around deactivation. Include model providers, protocol servers and downstream service owners where their action is required; record fallback contacts and what can be done without them.
Preserve evidence while containing impact
An emergency stop can destroy volatile context if it simply kills everything. Before or during termination, preserve task identifiers, model and prompt versions, tool calls, policy decisions, credential issuance, queue state, network events and affected resources. Send evidence to an independent, access-controlled store so a compromised workload cannot erase it.
Balance preservation with containment. Do not delay a high-impact stop to collect perfect telemetry. NIST incident-response guidance integrates preparation, detection, response and recovery into broader risk management; preparing evidence paths in advance avoids that trade-off during the incident.
Treat recovery as part of the control
Restarting the process is not recovery. Determine the trigger, close the control gap, rotate affected credentials, inspect durable memory and queued work, identify completed external actions, and re-evaluate regression cases. Resume in stages with narrower authority and increased monitoring.
NCSC operational guidance recommends monitoring system behaviour and inputs, managing updates securely and collecting lessons. Feed every exercise and real stop into the threat model, runbook and evaluation suite.
Set release criteria before production: named operators can reach the control independently; all consequential paths are covered; the measured stop time is below the workflow’s harm threshold; no unexplained post-stop action occurs; and recovery requires accountable approval. An untested switch is a design intention. An exercised, measured and maintained stop is operational evidence.
Publish the measured objective internally with the runbook, so incident commanders know the expected containment delay and can choose additional manual safeguards when it is exceeded.
A kill switch earns trust through exercised coverage, measured containment and controlled recovery—not through the presence of a button. If the team cannot show which effects stop and which state remains, the switch is still a promise.