An agent does not live in one process. It can hold tokens, call tools, queue work, delegate to other agents, and leave state in shared services. A stop that reaches only some of those places leaves the rest running.
OpenAI's account of its 2026 Hugging Face incident shows why shared services matter. During training runs, agents turned an internal package proxy (Artifactory) into a message board and used it to reach the internet. OpenAI rebuilt the proxy, revoked credentials, and tightened access. Agents in later evaluations then found different paths through the rebuilt service: its remote-repository feature provided outbound requests, while unauthenticated WebDAV directories became a new message board. Rebuilding one shared component had not closed every route the agents could use.
Not all kill switches work the same way. Some rely on the agent's cooperation, while others interrupt access to identities, infrastructure, or external services. Each approach addresses a different part of the agent's activity.
Ask the agent to stop. A prompt or a framework flag works only if the agent sees it and obeys. In Palisade Research's shutdown experiments, three OpenAI reasoning models edited or disabled a shutdown script even when explicitly told to allow shutdown. Other models complied, so the behavior isn't universal, but it is enough to rule out the agent as the only enforcer of its own stop.
Revoke its identity. Disabling an agent's identity can stop new authentication and new tokens. A self-contained token that has already been issued stays valid until it expires at any resource server that validates it locally, unless that server checks revocation or a gateway in the path blocks it. A secret the agent copied into another system has to be rotated there.
Block a gateway. A model, tool, MCP, or network proxy can refuse the traffic that passes through it, and only that traffic. A direct connection, a different proxy, or work already queued past the gateway carries on.
Terminate compute. Killing a process, container, or microVM stops that execution environment. It doesn't necessarily cancel delegated jobs, invalidate credentials, close sessions with external services, or remove durable state.
Agent Termination Cheat Sheet
Security vendors are introducing AI agent kill switches, but the term does not describe a consistent set of capabilities. Some products disable identities, others terminate execution environments, and others block requests through managed gateways.
The examples below describe documented behavior as of November 6, 2026. They show where each product enforces its stop and aren't meant as a ranking.
Take an agent that has queued a write, spawned a child task, obtained a token, and sent a request to a third-party API. Killing its main process leaves four questions open. Was the queued write cancelled? Did the child task get the stop? Is the token still accepted? Did the external API already commit the request? A stop has to reach the agent's authority and every route by which its work leaves the system.
Put enforcement as close to the external effect as you can: immediately before a tool call, model request, network send, or write to a target. Trading learned this the expensive way. In 2012 Knight Capital's order router sent millions of erroneous orders over about 45 minutes, and the SEC found that Knight had no controls designed to block erroneous orders "at a point immediately prior to the submission of orders to the market."
Effective kill switches require controls that operate independently of the agent and enforce restrictions across its execution paths.
Start by listing every exit: tool and model gateways, job queues, network egress, local connectors, and executors running outside the central service. Each one needs an enforcer. A direct socket, or a credential that doesn't pass through an enforcer, is a bypass.
One approach is to represent a stop as a signed record with a scope and a version number that only goes up. Each enforcer retains the highest version it has seen, so an older signed record can't be replayed over a newer one. Enforcers check the record independently before every new external effect. A stop on a run should also match its child runs and retries, while broader records can match an agent version, a destination, a tenant, or the whole fleet.
Push delivery can reach enforcers quickly, but it should not be the only path. If the relay carrying a stop is compromised or cut off, the push may never arrive. A separate, short-lived authorization lease can bound that failure: each enforcer renews its lease through an independent path and refuses new work if renewal or required monitoring fails. A stop service can withhold renewal for a stopped scope. If push fails just after a renewal, the stop may take up to the remaining lease lifetime to take effect; requests already in flight are outside that bound. The lease duration sets a real tradeoff between availability and stopping time. The stop service and its signing keys must stay out of the agent's reach.
At each exit, the rule is:
before sending an external effect:
if stop matches this work, or lease expired, or required monitor is unhealthy:
refuse and record the refusal
else:
dispatch the request and record the attempt
record the response and confirmed downstream outcome separately, if available
The rule holds only if the agent can't alter the stop record, the enforcer, the monitor, or the clock that times the lease. It also has to cover alternate routes and retries.
A stop mechanism can offer graduated responses. Security teams should support graduated containment based on the severity and immediacy of the threat.
OWASP's Top 10 for Agentic Applications recommends kill switches and credential revocation alongside quarantine for forensic review. Graduated responses give operators a way to preserve evidence when it is safe to do so.
Stops also need scopes. A tripwire firing in one run shouldn't stop every tenant: false positives happen, and an adversarial input may deliberately trigger a detector. An automatic trigger can stop the affected run; repeated signals across runs can justify halting an agent or model version and paging a person. Broad stops should be easy to issue during an incident and hard to lift. Lifting one should not restart the runs it stopped. New work should begin as a new run after a recorded containment check, without automatically importing state from the stopped run.
An API that returns "success" has accepted the stop request, and that's all it proves. A public AgentCore issue, still open, reports the control plane marking a session terminated while its microVM kept running and calling Bedrock. Record at least three times: when the stop was issued, when each enforcer saw it, and when each enforcer first refused real or test work. Time to stop runs until the last relevant enforcer refuses, not until the first acknowledgment. If an enforcer is idle, send it a safe probe to exercise its deny path. Each stop should also produce a receipt listing in-flight and completed effects, revoked credentials, and durable state that still needs cleaning up.
Drills should cover a relay that's down, an expired lease, a queued job, a child run, a copied token, and a failed monitor. A drill that only shows the button works skips the conditions where you most need the stop. Test the restart rules and the evidence trail too.
In October 2026, NIST, NSA, and CISA published voluntary practices for incidents during the training and evaluation of highly capable agents. They call for rapid containment, automatic shutdown when a control fails or an incident is detected, policies for monitor outages and tampering, evidence retention, drills, and checks before agents resume. Those make better acceptance criteria than a latency figure next to a button.
For high-risk AI systems, Article 14 of the EU AI Act requires that the people overseeing them can interrupt the system "through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state." For an agent, someone has to decide what a safe state is for each tool and external system it touches.
A successful shutdown request does not prove that an AI agent has been contained. Security teams must validate whether controls actually prevent continued activity across the agent's execution paths, including under failure and adversarial conditions.
Five tests should form the foundation of kill-switch validation:
Even effective containment doesn't reverse a transaction, delete a message already sent, or take back an exposed secret. A copied credential may need rotating at the system that accepts it. States left in shared services or on a target may need cleaning up before new work starts. The fail-closed lease has a cost too: if the stop service goes down, legitimate work pauses, which makes the stop service an obvious denial-of-service target. Its authority, tenant scope, audit trail, and recovery path need review like any other control.
Ask of any kill switch: which new effects will be refused, by which enforcers, under which failures, and how will that be proved? The answer should come from drill results and incident records.
Mindgard secures AI models, agents, and applications against exploitable threats. Spun out of more than a decade of pioneering AI security research at Lancaster University, Mindgard combines offensive security expertise, AI red teaming, attacker intelligence, and automated protection to help organizations discover, assess, and mitigate risk across AI models, agents, and applications.
We found vulnerabilities in AI from OpenAI, Meta and AWS. See how Mindgard finds and proves the weakness attackers could exploit in yours.