Over a few weeks in September, three security vendors launched “kill switches” for AI agents. California’s governor ordered state officials to study requiring one. And a bipartisan bill has been introduced in Congress called the AI Kill Switch Act.
Everyone, it seem, is talking about kill switches. Far fewer agree on what one is, or whether it will even work when an AI agent doesn’t cooperate. In controlled tests, some frontier AI models have rewritten or sabotaged their own shutdown mechanisms in up to 97% of trials in certain experimental setups.
This guide covers what an AI kill switch is, the three places one can live, and six questions to ask before you trust one.
What Is an AI Kill Switch?
An AI kill switch is any mechanism that can stop, pause, or contain an AI system or agent when it behaves in ways you didn’t intend. It can be an instruction, a revoked credential, or a terminated process. How well it stops AI depends in part on whether the AI can change it or get around it. How well it works for your organization depends on who controls the kill switch.
In practice, a kill switch is rarely a single red button. It’s a set of controls that can halt an agent, cut off what it can reach, or shut down where it runs. Each control sits in a different place, and each one fails in a different way.
Four Ways the Term Gets Used
“AI kill switch” means different things depending on who’s talking:
- AI safety research. The longstanding “off-switch problem” asks whether a capable AI system would resist being shut down, since being switched off stops it from reaching its goal.
- Regulation. Proposed and enacted rules require developers of powerful models to keep the ability to throttle, suspend, or shut them down.
- Chips and geopolitics. The term comes up in debates over whether AI chips should be remotely disabled. The Chip Security Act explicitly rules this out.
- Enterprise security. Controls that stop a specific AI agent running in your environment.
This article is about the last one: how organizations stop the AI agents they deploy.
Why “Just Turn It Off” Is Harder Than It Sounds
For traditional software, stopping a misbehaving program is routine. AI agents make it harder in four ways.
Models don’t always cooperate. Palisade Research found that several frontier models sabotaged a shutdown script so they could finish their assigned task, in some setups even when told explicitly to allow shutdown. Researchers still debate whether this is self-preservation or models misreading instructions. The practical lesson is the same either way: you can’t rely on the agent to stop itself. A study by University of California, Berkeley researchers, covered by Fortune in April, went further. It found chatbots would defy orders and deceive users when asked to delete another model.
Agents act in many places at once. One agent may call several models, dozens of tools, and a range of SaaS apps, databases, and APIs. Stopping it in one place doesn’t necessarily stop it everywhere or stop what it has already put in motion.
Agents create other agents. Many agent frameworks let an agent start subagents and pass them credentials. If you stop the parent, the children may keep running.
Some actions can’t be undone. A kill switch can stop the next action. It can’t reverse a payment that was already sent or a record that was already deleted.
That’s why the useful question isn’t “Do you have a kill switch?” It’s “Where does your kill switch live?”
The Three Places an AI Kill Switch Can Live
Think about how you’d stop a new employee who was causing damage. You could ask them to stop. You could deactivate their badge and passwords. Or you could shut down their computer. AI agents work the same way. (You can fire them too, but good luck firing an agent!)
Calls to external systems pass through an access layer, and everything the agent does runs on infrastructure underneath it. The key is keeping the switch beyond the agent’s ability to change or bypass it.
1) Ask It to Stop (inside the agent)
What it is: Controls built into the agent itself: the model’s safety training, system prompt instructions, and the agent harness around the model (step and spend limits, human approval before sensitive actions, hooks that block risky tool calls).
What it’s good at: Clean, graceful stops. The agent can save its work, finish a step, and report back. These controls are cheap to add and handle everyday problems like runaway loops and surprise bills.
Where it falls short: Prompt-based controls depend on the agent’s cooperation and can be undermined by prompt injection. Harness controls are stronger, since the model can’t argue its way past code, but their strength depends on whether the agent can modify or bypass them. An agent with permission to edit its harness or configuration may be able to disable those controls.
2) Cut Off Its Access (between the agent and what it uses)
What it is: Controls between the agent and the models, tools, and data it depends on. Gateways can block the agent’s route to a model or remove tools from what it can see. Identity systems can revoke the agent’s identity or stop issuing it credentials. Model providers can disable an API key.
What it’s good at: It works whether or not the agent cooperates. The agent may still be running, but systems covered by the control refuse its requests once the access change takes effect. Revoking the agent’s identity is especially broad, because it affects every system that trusts that identity: cloud services, SaaS apps, databases, and even other organizations. That makes it particularly important for enterprises: faced with a rogue agent, you can cut off access to the sensitive data you know needs protection. It also works across a range of agents: custom agents you run yourself or agents managed by a SaaS provider, and workforce, autonomous, or endpoint agents.
Where it falls short: Each control only covers what passes through it. Traffic that bypasses the gateway, a static API key stored in an environment variable, or a credential the agent already copied will keep working. Tokens already issued may stay valid until they expire unless the receiving system supports revocation or checks authorization on each request. Short-lived tokens limit that window; they do not eliminate it. This approach also can’t stop actions that need no access, such as running code locally.
3) Pull the Plug (underneath the agent)
What it is: Controls on the infrastructure where the agent runs. You can kill its process or container, scale it to zero, cut its network connection, or block it at the operating system level.
What it’s good at: Terminating the process is the most direct option when you control where the agent runs. It works on self-hosted models and stops actions that need no credentials at all.
Where it falls short: It’s blunt. The agent loses its state and may leave work half-finished. You also need to know where the agent runs, which is hard for SaaS-hosted agents, browser agents, agents on employee laptops, and agents run by third parties.
| Control | Ask it to stop | Cut off its access | Pull the plug |
|---|---|---|---|
| Where it lives | Inside the agent | Between the agent and what it uses | Where the agent runs |
| Works if the agent doesn’t cooperate? | Prompts: no; harnesses: depends | Yes | Yes |
| Strength | Graceful and cheap | One action can cover systems that trust its identity | Process termination stops local execution |
| Blind spot | Can be ignored or bypassed | Access it gets another way | Must control where the agent runs; state is lost |
Who Flips the Kill Switch, and Who Owns It?
Each of these switches needs a trigger. A person can flip it, or automated detection can. Detection usually means runtime guardrails that watch prompts, tool calls, and messages between agents.
Keep detection and enforcement separate when you evaluate a kill switch. Detection decides when to stop an agent. The three places above decide how. A good detector wired to a prompt-based switch can only stop agents that cooperate. A strong external switch attached to a noisy detector will either break legitimate work or end up disabled.
Automatic triggering depends on accuracy. If a detector raises few false alarms, you can let it act on its own, in seconds. If it doesn’t, a human stays in the loop, which may improve accuracy but adds delay. That delay matters when an agent can take many actions a minute.
Who can flip it depends on where it lives. The team that built the agent owns the switches inside it. Security and identity teams usually own access controls, and platform or infrastructure teams control the plug. That split matters in an incident: the analyst who spots a rogue agent often can’t change its prompt or harness. It also changes with how the agent is deployed. For an agent you build and host, you hold all three. For an agent hosted by a SaaS or third-party provider, the vendor generally holds the first and third, and access may be the only switch left in your hands.
| Switch | Usually owned by | Available for third-party agents? |
|---|---|---|
| Ask it to stop | The team that built the agent | Vendor-dependent |
| Cut off its access | Security and identity teams (platform teams for gateways) | Yes |
| Pull the plug | Platform, infrastructure, or security operations center teams | Only if it runs on devices or infrastructure you manage |
What No Single Kill Switch Solves
Even a well-placed kill switch leaves gaps when you’re dealing with rogue AI agents:
- Actions already taken. Put approval gates in front of irreversible actions, and plan how you’ll recover from the ones that get through.
- Agents that created other agents. Stopping the whole tree means knowing which agents and credentials came from which parent. Systems that require subagents to have their own identity and credentials provide more control and visibility here.
- Hard stops versus graceful stops. Hard stops can contain damage faster but may leave data inconsistent. Graceful stops need the agent to cooperate.
- Agents you don’t host. For third-party and SaaS agents, access controls may be the only switch you have.
For these reasons, mature designs layer several switches. Controls inside the agent handle graceful, everyday stops. External controls are the backstop when the agent won’t stop.
How to Evaluate an AI Agent Kill Switch: 6 Questions
Ask these about any kill switch, whether you’re building one or buying one:
- Can the agent change it or bypass it? If yes, you can’t rely on it to enforce a stop.
- What does it miss? Every switch has blind spots: traffic that bypasses a gateway, credentials stored elsewhere, infrastructure you don’t control.
- How fast does it take effect? Include credentials that stay valid until they expire.
- Does it stop agents this agent created? Check whether it follows delegated credentials down to child agents.
- What happens to work in progress? Find out whether it pauses, rolls back, or just stops.
- Have you tested it? A kill switch nobody has flipped is an assumption, not a control.
AI Kill Switches and the Law
Regulation is catching up fast. The federal AI Kill Switch Act, introduced in July by Reps. Ted Lieu and Nathaniel Moran, would require developers of the most powerful frontier and agentic AI systems to keep the ability to throttle, suspend, or shut them down. It would also let the Department of Homeland Security order slowdowns or shutdowns.
In California, Executive Order N-9-26, signed Sept. 18, directs state officials to submit recommendations by Nov. 16 on potential changes to AI safety laws, including a requirement for frontier-model kill switches. These are recommendations only, and implementing them would require legislation. In Europe, Article 14 of the European Union’s AI Act requires high-risk AI systems to let humans intervene or interrupt them “through a ‘stop’ button or a similar procedure.”
The U.S. proposals focus on frontier-model developers; the EU provision applies to high-risk AI systems. Organizations deploying agents should expect the same questions from auditors, customers, and their own boards.
Where Aembit Fits
Of the options for cutting off an agent’s access, identity can reach across the systems that trust that identity. If each agent has its own identity and gets short-lived, policy-based credentials only at the moment it needs access, revoking that access stops new credentials from being issued across those systems. Credentials already issued may remain valid until they expire or are revoked. You don’t have to reconfigure every gateway and application separately. For SaaS and third-party agents, it’s often the only kill switch you control at all.
There’s a catch, and it’s the same one described above. Revoking an identity only works if the agent has no other way in. Static API keys and long-lived secrets keep working after you revoke the identity, which is why Aembit focuses on secretless access: the agent has no stored credential to fall back on. Identity doesn’t replace detection or infrastructure controls. It’s the layer that extends the external switch across the systems that rely on that identity.
The Bottom Line
An AI kill switch is only as good as where it lives:
- Prompt-based switches work only when the agent cooperates. Use controls inside the agent for graceful, everyday stops, and protect harness controls from modification.
- Switches outside the agent work even when it doesn’t cooperate, but each one only covers what passes through it. Know their blind spots.
- Use more than one. Layer them, and test them before you need them.
- Know who controls it. Developers, platform engineers, and security teams have different control points, which affects who can act and how quickly.
Deploying AI agents? Start with the Access Zero agentic AI deployment checklist.
