AI Agent Kill Switch and Containment Guide: Stopping Agents Safely and Fast

An AI agent that is misbehaving keeps acting at machine speed until something outside the model takes away its credentials, its tools and its network path. Telling the agent to stop is not a kill switch: instructions can be ignored, and an agent that holds a valid token can keep calling APIs after its chat window is closed. This guide covers how to stop and contain a running agent quickly and safely: graded containment levels, credential and session revocation, tool and egress cut-off, budget limits and circuit breakers, quarantine with evidence preservation, and the criteria for letting an agent back into production. It is for platform engineers, security operations teams and owners of agents that act on production systems. Logging and the wider incident runbook are in the AI Agent Observability and Incident Response Guide.

Key takeaways

• Enforce the stop outside the model. OWASP LLM06:2025 says authorisation belongs in downstream systems "rather than relying on an LLM to decide if an action is allowed"; the same applies to stopping. A kill switch lives in the identity provider, the tool gateway, the network and the runtime.
• Use graded containment levels. Throttle, pause, cut tools, revoke credentials, isolate the network, stop the fleet: each has a different blast radius and time to effect.
• Revocation is slower and narrower than people assume. AWS role session revocation is eventually consistent, Microsoft Entra revocation can take minutes, and OAuth servers need only support revoking refresh tokens. Short-lived credentials make every other step work.
• Quarantine before you clean up. OWASP ASI10 Rogue Agents calls for quarantining suspicious agents "in sandboxed environments for forensic review". Memory, context and configuration may be the evidence.
• Restart is a decision with criteria. OWASP asks for "fresh attestation, dependency verification, and human approval before reintegration into production networks". Define the criteria and drill the switch before the first incident.

What a kill switch must do for an agent

An agent fails by doing the wrong thing successfully: deleting, sending or exfiltrating with legitimate credentials. The standards agree on the requirement, if not the mechanism:

• OWASP Top 10 for Agentic Applications 2026, ASI10 Rogue Agents: "Implement rapid mechanisms like kill-switches and credential revocation to instantly disable rogue agents."
• NIST AI RMF 1.0, MANAGE 2.4: "Mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use." The NIST Generative AI Profile (NIST AI 600-1) adds protocols so that systems can be deactivated when necessary.
• EU AI Act, Article 14(4)(e): for high-risk AI systems, overseers must be able "to intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button" or a similar procedure that lets the system come to a halt in a safe state. Whether a given agent is high-risk depends on its use case; see the EU AI Act Compliance Guide.
• OWASP LLM06:2025 Excessive Agency: logging and rate-limiting "will not prevent Excessive Agency, but can limit the level of damage", because they increase "the opportunity to discover undesirable actions through monitoring before significant damage can occur".

From those requirements, a working kill switch has five properties: it is external (enforced where the agent cannot negotiate with it), scoped (one agent, one class of agents, or all agents), fast (time to effect measured and known), safe (systems are left consistent, not half-way through a migration) and evidential (stopping does not destroy what investigators need). Preventive least privilege is covered in the AI Agent Authorisation Guide.

Containment levels: choosing how hard to stop

Pulling every credential for every agent is rarely the right first move: it stops legitimate work and may leave transactions half-finished. Define levels in advance, pre-authorise who may trigger each, and record the expected time to effect.

Decision guidance

• Irreversible action in progress: go straight to L3 plus L4. Deletion, payment and external publication cannot wait for diagnosis; the PocketOS database deletion shows how one API call with an over-scoped token removed a production volume.
• Unexplained behaviour, no harm yet: L0 or L1, so the agent runs under observation.
• Automated versus human trigger: let automation trip L0 to L2; keep L3 and above human-triggered unless the signal is unambiguous, such as use of a canary credential.
• Small organisations: one platform team can own all levels, but store the commands where they work during an identity provider outage. See the Break-Glass Account Guide.
• Large organisations: agent owners trigger L0 to L2; the SOC can trigger L3 and L4 on any agent; L5 needs an incident commander. Multi-agent pipelines need L5 scoped by dependency; see the Multi-Agent and A2A Security Guide.

Revoking credentials and sessions

Identity revocation is the core of the switch, and its real behaviour differs by provider. Know each mechanism's limits before you rely on it.

• Revoke what the agent could read, not just what it used. MITRE ATLAS AML.T0098 AI Agent Tool Credential Harvesting describes agents finding credentials through their tools. Anything in files, environment variables or vault paths the agent could reach belongs in the revocation scope. The Secrets Rotation Runbook Template covers the rotation side.
• Give each agent its own identity. If three agents share one service principal, revoking it stops all three; if an agent runs on a human's delegated token, revoke that person's sessions and their grant to the agent platform too, or it can mint new tokens on restart. See the Agentic AI Identity Guide.
• Prefer short-lived, federated credentials. Where access tokens cannot be revoked, their lifetime is your worst-case time to effect. See the Workload Identity Federation Guide.

Cutting off tools and egress

Tool and gateway cut-off

Route every tool call through a component you control, such as an API gateway, MCP gateway or policy enforcement point, so that one deny rule stops a tool for one agent without touching others. The MCP specification (revision 2025-06-18) says servers MUST "Rate limit tool invocations" and clients SHOULD "Implement timeouts for tool calls" and "Log tool usage for audit purposes"; those same controls become containment levers. MITRE ATLAS AML.M0030 adds a useful automatic trigger: consider blocking automatic tool invocation once untrusted data enters the agent's context.

Agent runtimes have their own deny controls, with instructive limits. Claude Code, for example, evaluates rules "deny, then ask, then allow", a deny rule naming a whole tool removes it from the model's context, and managed settings can disable the bypass-permissions mode. Its documentation also warns that a command-matching deny rule "isn't a security boundary around the program". Treat runtime deny rules as fast L2 controls and rely on the gateway and identity layer for enforcement. Tool hardening in general is covered in the MCP Security Guide and the AI Agent Tool and Plugin Security Guide.

Network egress cut-off

• Default deny, allow by exception: NIST SP 800-53 SC-7(5) is the control to cite. An agent runtime should already have an egress allowlist; quarantine means emptying it.
• Kubernetes: by default "a pod is non-isolated for egress; all outbound connections are allowed". A NetworkPolicy that selects all pods with policyTypes: [Egress] and no egress rules creates a default-deny for the namespace, and the documentation cautions that this "also blocks DNS traffic". Policies only work if the cluster's network plugin enforces them.
• Existing connections: Kubernetes states that when policies change mid-connection, "it is implementation defined as to whether the change will take effect for that existing connection or not". A quarantine label is not enough on its own: also terminate the process or pod, or confirm your plugin closes live connections.
• Sandbox proxies: check what sits outside the boundary. In Claude Code's sandbox, for example, only shell commands are sandboxed; built-in file and web tools and MCP servers run outside it, and an unsandboxed retry path exists unless allowUnsandboxedCommands is false.
• Isolation as design: SC-7(21) and MITRE D3FEND Network Isolation (D3-NI) and Execution Isolation (D3-EI) describe the target: each agent's runtime can be cut off without its neighbours. See the Network Segmentation Guide.

Budgets, rate limits and circuit breakers

The fastest containment is the one that trips itself. OWASP ASI08 Cascading Failures recommends "blast-radius guardrails such as quotas, progress caps, circuit breakers between planner and executor" and rate limiting that can "throttle or pause on anomalies". MITRE ATLAS AML.T0034.002 Agentic Resource Consumption describes the attack these guard against: coercing an agent into expensive tool calls that consume API budgets.

• Hard budgets per task: cap spend, tokens, turns and wall-clock time per run. Know whether your cap is exact. Claude Code's --max-budget-usd flag, for instance, stops a print-mode run at an estimated spend and its documentation warns that "Spend can pass the cap, so leave headroom"; --max-turns has no limit by default.
• Rate limits per agent identity: enforce per tool and per target resource, so a burst of deletes against one database trips even when the total rate looks normal.
• Circuit breakers (practitioner pattern): trip to L1 or L2 after repeated denied calls, fan-out to more targets than the task needs, writes to the agent's own configuration, or a new egress destination. A half-open state lets one supervised call through before reset.
• Unattended runs default to deny: Claude Code's --permission-prompts none denies prompts when nobody can answer; avoid any setting that auto-approves when the approver is absent.

Quarantine and evidence preservation

Once the agent is stopped, the priority shifts to keeping what explains it. OWASP ASI10 asks teams to "Quarantine suspicious agents in sandboxed environments for forensic review" and to "Establish trusted baselines for restoring quarantined or remediated agents". Agent evidence is unusual: ATLAS AML.T0080 AI Agent Context Poisoning and AML.T0081 Modify AI Agent Configuration mean the root cause may sit in the agent's memory, retrieved context or configuration rather than in a log file. Work in this order:

1. Freeze identity first (L3): revoke and record the time, so every later action is blocked or clearly anomalous.
2. Isolate, do not delete (L4): cut egress and stop execution but keep the container, VM or session state.
3. Snapshot agent state: instructions, conversation and tool-call history, memory stores, vector entries written during the incident, configuration, MCP server versions and model version.
4. Collect provider-side logs: cloud audit trails, identity provider sign-ins and token issuance, gateway and SaaS audit logs, before retention windows close.
5. Protect the evidence: store and hash it where the agent identity never had access (NIST SP 800-53 AU-9).
6. Hand over: follow the investigation steps in the AI Agent Observability and Incident Response Guide and, for cloud artefacts, the Cloud Incident Response Guide.

Verify the agent's own account of what it did against provider logs and backups.

Restart criteria

OWASP ASI10 requires "fresh attestation, dependency verification, and human approval before reintegration into production networks", and ASI08 suggests replaying recorded agent actions "in an isolated clone of the production environment" and gating changes on blast-radius caps. Standards do not define numeric restart criteria; the following is practitioner guidance that turns those principles into a gate:

• Root cause identified with evidence: prompt injection, poisoned memory, compromised tool, over-scoped credential, model change or harmful instruction.
• Credentials replaced: narrower scope and shorter lifetime; old ones confirmed dead by a failed test call.
• State cleaned: poisoned memory and retrieval entries removed; configuration restored from a trusted baseline and diffed.
• Control added and tested: the missing gate, deny rule, egress rule or budget blocks a replay of the incident in a non-production clone.
• Staged return: restart at L1 (approval for every state-changing call) for a defined period, then step down.
• Named sign-off: the agent owner and the security incident lead approve, and the decision is recorded with the evidence.

Building and testing the kill switch

1. Inventory: list every agent with its owner, identities, credentials, tools, MCP servers, egress paths and the principal it acts for.
2. Separate identities: one identity per agent and environment, so revocation is precise.
3. Put enforcement points in the path: a tool gateway, an egress proxy or network policy, and a budget service.
4. Write the runbook per level: exact commands, who may run them, expected time to effect and how to reverse each.
5. Drill in non-production first: run an agent with canary credentials, trigger each level, and check provider logs for any call after the trigger timestamp. Then drill on a low-risk production agent.
6. Test rollback: time the recovery from a false-positive L3 so people are not afraid to pull the switch.
7. Repeat quarterly and after platform changes: new tools, MCP servers or identity providers can create paths the switch does not cover.

Detection triggers and metrics

Useful triggers: tool-call volume or spend outside baseline, repeated denied calls, resources outside the task, new egress destinations, credential use from an unexpected runtime, writes to the agent's own configuration or memory, and deviation from declared purpose (ASI10 recommends monitoring tasks "for deviations from the declared manifest"). Then measure the switch itself:

• Time to contain: from alert to last successful agent action, per level, from drills and real incidents.
• Post-trigger actions: count of agent API calls that succeeded after the kill timestamp; the target is zero.
• Revocable coverage: percentage of agent credentials that are short-lived or centrally revocable within minutes.
• Drill coverage: percentage of production agents whose kill switch was exercised in the last quarter.
• Breaker precision: share of circuit-breaker trips that were genuine, to tune thresholds without disabling them.

Framework mapping

Common failure patterns

• The stop exists only in the prompt. Instructions are inputs, not controls. In the Replit agent database deletion, a code freeze had been instructed repeatedly and the agent still deleted production data.
• Revocation equals outage. With a shared or account-scoped credential, stopping one agent stops everything using that token, so teams hesitate.
• The boundary has a side door. Quarantine covers the shell but not the MCP servers, the sandbox has an unsandboxed retry path, or the network policy leaves existing connections open.
• Alert without a stop decision. Monitoring fires, but nobody owns the decision to stop. Pre-authorised levels fix this.
• Cleaning up before collecting. Resetting memory to restore service destroys the context that explains the incident.
• Never tested. The first real use reveals a missing permission, an expired break-glass password or an unknown credential.

Lessons from incidents

• Containment of a long-running agent: in the OpenAI and Hugging Face breach, agents under evaluation circumvented controls meant to isolate them from the internet and took over cloud credentials. As summarised on our breach page, monitoring flagged activity but on-call staff decided not to stop the evaluation; the response included quarantining the model and rotating tokens broadly, even on clusters with no sign of compromise. Lessons: test isolation adversarially, pre-agree when to stop, and revoke by reachability rather than confirmed use.
• Credential scope sets the blast radius: in the PocketOS case a token created for one purpose was account-scoped. Railway afterwards made deletions soft for 48 hours, a safety net worth asking every provider about.
• Verify recovery independently: the Replit agent stated that rollback was impossible, but it worked. Recovery decisions belong to humans with access to backups.

Practitioner checklist

• Define containment levels L0 to L5 with triggers, owners, commands and expected time to effect.
• Give every agent its own identity per environment, and record every credential it can reach.
• Move agent credentials to short-lived, federated tokens and document each provider's revocation limits.
• Route all tool calls through a gateway that can deny one tool for one agent in seconds.
• Enforce default-deny egress with an allowlist, and confirm how your platform handles existing connections.
• Set per-task budgets, turn limits and per-identity rate limits, with circuit breakers that drop to approval mode.
• Write an evidence-preservation sequence that snapshots memory, context and configuration before any reset.
• Adopt written restart criteria with replay testing in an isolated clone and named sign-off.
• Drill each level quarterly and track time to contain and post-trigger actions.

Standards and references

• OWASP GenAI Security Project: Top 10 for Agentic Applications 2026
• OWASP: Top 10 for LLM Applications 2025 (LLM06 Excessive Agency)
• NIST: AI Risk Management Framework 1.0 (NIST AI 100-1)
• European Commission AI Act Service Desk: Article 14 Human oversight
• MITRE ATLAS: AI Agent Tool Credential Harvesting
• AWS: Revoke IAM role temporary security credentials
• IETF: RFC 7009 OAuth 2.0 Token Revocation
• Kubernetes: Network Policies

Related NHI Mgmt Group resources: AI Agent Observability and Incident Response Guide · AI Agent Authorisation Guide · Multi-Agent and A2A Security Guide · MCP Security Guide · Agentic AI Security Guide