The AI Kill-Switch Problem Is That There Is No Kill Switch

The AI industry appears to have reached a rare point of agreement: every autonomous agent needs an AI kill switch.

The trouble starts when somebody asks what the button is wired to.

All useful buttons. Just don’t assume any one of them shuts down the factory.

Enterprise AI is starting to look a lot like that factory. Depending on the technology, hitting the big red button might terminate the process running an agent, revoke its credentials, block its next tool call, cut network access or prevent a specific business action. Those are all legitimate forms of stopping and containing an agent.

Imagine a factory where every vendor installs a red emergency-stop button. One shuts down the robot arm. Another stops the conveyor belt. A third disables employee badges. Another closes the loading dock. Each button works exactly as advertised.

Coordinating one agent is hard enough. Containing one that has already delegated work to other agents is harder.

Agents can reach SaaS applications, databases, browsers and cloud services, invoke tools through MCP servers and hand jobs to other agents. A compromised agent might alter a customer record, initiate an unauthorized payment or send sensitive data somewhere it should not go.

So when a vendor says it has an AI kill switch, the useful follow-up is: Which part are you killing?

What is emerging is less a universal off button than a kill-switch stack, with different controls positioned at different points in an agent’s path.

The boundaries are fuzzy. AWS, Microsoft, CrowdStrike, ServiceNow and others are wiring their emergency brakes into different parts of the agent delegation chain and control plane.

Meanwhile, enterprise adoption is moving fast. KPMG found that 62% of large organizations were building, deploying or developing AI agents in 2026, up from 53% just a quarter earlier, while the share developing multi-agent systems jumped to 25% from 6%. McKinsey found 40% of large enterprises were already scaling agents, up from 27% a year earlier.

And the complexity is increasing with the adoption. Anthropic found 57% of organizations are already using agents for multi-stage workflows, and 81% plan to tackle more complex agent use cases this year.

As part of this series, Security Point Break spoke with AWS, CrowdStrike, Google Cloud, Salesforce, ServiceNow, Okta and Zscaler about what each can actually stop.

One finding quickly emerged, these vendors do not fit neatly into a single control-plane layer. Many are stretching across several.

AWS, for example, can terminate an AgentCore runtime, block tool calls at the gateway and enforce credential revocation through AgentCore Identity. CrowdStrike ties agent behavior to endpoint, identity, network and downstream execution telemetry. Zscaler similarly argues that its controls extend beyond the network into agent lineage, identity, cloud and endpoint enforcement.

What follows is a map of who claims to control what — and where those controls begin to overlap.

The Process Kill Switch

The most literal approach is to kill the place where the agent is running.

The theory is straightforward: if the agent’s reasoning and actions depend on a live process, terminate that process and you cut off its ability to keep executing from that environment. It is the closest AI-agent equivalent to pulling the plug on a running program.

Amazon Bedrock AgentCore runs individual agent sessions inside dedicated Firecracker microVMs. In plain English, if an agent handling a customer-support task starts behaving badly, AWS can terminate the isolated runtime hosting that session rather than simply asking the agent to stop.

AWS says terminating the session destroys the microVM and sanitizes its memory. But the company does not treat that as the entire kill switch. AgentCore separates runtime control from its Gateway and Identity controls, allowing customers to terminate the runtime, block future tool calls or revoke credentials independently.

Limits exist. Killing the engine is not always the same as undoing everything the agent may already have set in motion.

Google Cloud draws a similar distinction between stopping local execution and sending cancellation requests to remote agents. Salesforce offers another variation: an Agentforce agent can be stopped and quarantined inside the Salesforce environment, cutting off further processing and access.

Think of these as variations on the process kill switch: stop the worker, stop the runtime hosting it, or freeze the environment in which it can continue acting.

The Identity Kill Switch

Another school of thought says: take away the agent’s keys.

Okta’s Agent Gateway strategy includes kill-switch capabilities designed to revoke active tokens and terminate sessions associated with a compromised agent. That puts identity, what the agent is and what authority it possesses, near the center of containment.

Okta is hardly alone there. Microsoft’s Entra Agent ID gives autonomous agents distinct identities and extends Conditional Access and risk-based access controls to them. Administrators can block risky agent identities or restrict which resources they may access.

Delinea approaches the same problem from privileged identity, adding Runtime Authorization that can approve or deny an agent’s actions after it has authenticated.

These are variations on the identity button. The agent may still exist, but its badge no longer opens the door.

The Action Kill Switch

Sometimes killing the whole agent is overkill.

ServiceNow comes at the problem from another direction: killing an agent may be unnecessarily blunt.

Its AI Control Tower uses a graduated containment model. An organization can monitor an agent, pause it, restrict its privileges, deactivate it and later reinstate it. The company’s AI Passport is meant to carry a representation of what the agent is authorized to do so enforcement layers can decide whether a particular action should proceed.

“Real governance is graduated. It’s more like a dimmer switch,” said ServiceNow Group Vice President of AI Product Management Nenshad Bardoliwalla.

The company demonstrated the distinction with a refund agent authorized to issue refunds of no more than $25. An $18 request passed. A $40 refund reached the runtime and was rejected because the action exceeded the agent’s authority and required human review.

Nothing crashed. Nobody yanked the proverbial power cord. The system simply refused to let the agent do that particular thing.

That may be closer to where mature agent security is heading. A good control plane should not have to euthanize an otherwise useful agent every time it approaches a boundary. Sometimes containment should mean narrowing the agent’s world until the risky action becomes impossible.

The “kill switch” metaphor survives because it is vivid and easy to understand. The actual security model is becoming much more granular.

AWS AgentCore Gateway works at a similar decision point by evaluating individual tool calls and blocking those that violate policy before they reach the tool. Delinea’s Runtime Authorization likewise evaluates commands, queries and tool calls while a session is underway.

This is the action button: let the agent continue working, but stop the particular thing it is trying to do.

AWS itself cautions against treating a single control as complete containment. In its written response to SPB, the company said the larger problem requires layers spanning runtime isolation, credential revocation, policy enforcement and cross-vendor signal sharing.

The Execution and Network Kill Switch

CrowdStrike’s answer is to treat the execution chain itself as part of the containment problem.

Falcon Guardian connects prompts, agent identity, tool calls and skill use with process, filesystem and network telemetry on downstream systems. When work moves downstream, CrowdStrike says it can trace the execution chain and blast radius rather than assuming the incident ended with one process.

“The goal isn’t to stop one process and assume everything downstream stops with it,” CrowdStrike Chief Product Officer AJ Shipley told SPB.

Zscaler’s AI-SPM and AI Access products similarly emphasize lineage and policy as activity moves among agents, endpoints, cloud and SaaS systems. Barracuda’s AI Data Security puts yet another control point in the traffic path, at the network edge, where organizations can apply policy before requests reach an AI service.

The idea is straightforward. Engineering it across multiple agents, systems and vendors is considerably harder.

These are versions of the execution and network button: follow where the agent goes and cut off paths it should no longer be able to use. That is the moment the big red button starts looking more like a collection of circuit breakers.

The Infrastructure Kill Switch

NVIDIA takes the same instinct – keep enforcement outside the agent – and pushes it closer to the hardware.

Its OpenShell runtime puts an agent inside a sandbox and governs what files, processes, networks and services it may use. Outbound requests are checked against policy before they leave. Sentry adds an optional watchdog on NVIDIA BlueField hardware separated from the host running the agent, giving the infrastructure another place to quarantine a workload if it crosses its prescribed boundary.

OpenShell is the fence. Sentry is the guard standing somewhere the prisoner does not control.

There is a reason that idea keeps resurfacing in different forms across the market. Model instructions and behavioral guardrails matter, but they are not the same thing as an independent system capable of saying no.

AWS’s Firecracker isolation overlaps with that philosophy. It puts hard technical boundaries around the workload instead of relying entirely on the agent to behave.

Think of it less like telling a reckless driver to slow down and more like putting the car on a test track with concrete barriers it cannot move.

This is the infrastructure button: build the fence somewhere the agent cannot simply rewrite the rules.

One Agent, Several Red Buttons

Put these approaches side by side and the market looks less confused than it first appears.

Identity systems are well positioned to withdraw authority. Cloud platforms can terminate workloads and police tool calls. Endpoint and security platforms can trace what execution actually touched. Network products can cut connectivity. SaaS and orchestration systems can determine whether a business action falls inside policy. Infrastructure controls can create a boundary beneath the agent that its own reasoning cannot rewrite.

Okta’s Blueprint Alliance, announced Sept. 22 at Oktane 2026 as a cross-industry effort to define a shared security architecture for AI agents, makes that problem explicit. Its framework calls for targeted containment through controls such as rate limiting, token revocation, session termination and network quarantine, followed by access recovery after the agent is re-attested. It also calls for cross-vendor risk signals so a detection in one control plane can trigger action in another.

Okta Chief Product Officer Ely Kahn told SPB that the company’s emerging kill-switch model is also designed to use risk signals from partners such as CrowdStrike. If an agent crosses a risk threshold, those signals could help trigger disconnection from resources.

That is the right ambition. It is also substantially harder than publishing a common diagram.

A CrowdStrike detection has to mean something actionable to an identity provider. The identity provider’s revocation has to reach the runtime soon enough to matter. The runtime has to know what work has already been delegated. A gateway has to distinguish a legitimate call from the next step in an incident. A SaaS platform may have to decide whether to reject work that originated with an agent another vendor has just declared compromised.

Some of those integrations exist. Others are roadmap items. Others depend on open standards, implementation choices and whether the relevant activity crossed a control point capable of seeing it in the first place.

That gap, between a collection of kill switches and coordinated containment, is the real story.

The agent may be dead. Its work may not be.

The trouble begins where one control ends and another begins.

The agent may be dead. Its work may not be.

What CISOs Should Mean When They Say ‘Stop the Agent’

For security buyers, the phrase AI kill switch is therefore becoming less useful as a product requirement unless it comes with a second sentence.

The due-diligence questions are more revealing: What exactly gets stopped — a process, session, credential, connection or action? What happens to work the agent already delegated? Can a signal from another security platform trigger containment automatically? What state, queued work or external activity survives? Where does the vendor’s enforcement boundary end, and what has to happen before the agent can safely return?

Those were the questions SPB put consistently to vendors while reporting this series because the answers expose far more than whether a console contains a red button.

The industry’s early answers also suggest that the eventual winner may not be whichever company claims ownership of “the kill switch.” Enterprises are unlikely to let one provider own every identity, runtime, application, network and piece of infrastructure involved in agentic work. More likely, several controls will need to cooperate, with each one capable of vetoing the part of the system it actually governs.

Which brings the paradox back around.

Everyone has an AI kill switch. Many of them work.

The harder question is whether the other switches know when one has been thrown — and whether they can stop the work before the agent’s last instruction becomes somebody else’s problem.

Next: The AI Agent Is Dead. Its Work Isn’t.