The Big Red Button Myth
I spend much of my time these days focused on securing AI and agents and one of the hottest topics in the industry at the moment is that of an AI “Kill Switch”.
It is also among the biggest misperceptions, which is why I want to take some time to write about the topic.
It comes up in public discourse, vendor marketing, policy maker dialogue, the CISO and security leadership dinners and roundtables I’ve been participating in and among the Fortune 500 customers I work with.
On the surface, it is marketed as one big red button, but in reality it is various controls and methodologies across the stack and how it manifests in practice varies depending on if you are a frontier model provider, policy maker, enterprise or security practitioner, as well as depending on the environment the model and agent are deployed in.
One of the best articles I’ve read on this topic is from Kevin Skapinetz titled “There Is No AI Kill Switch (there are a dozen)”. In the piece, Kevin rightly points out how “killing” a model or agent looks different depending on deployment scenarios and the stakeholders involved.
People are also using the word “kill” when in reality it may mean:
Stopping work in progress
Pausing execution while keeping state
Containing inside a tighter boundary
Revoking access
Rolling back side effects
Another key point Kevin made is that only a handful of the options truly stop work in progress, such as killing a process, labs shutting down a model run, or shutting off the underlying services, while everything else lets the action in flight continue.
Every step also requires someone (or something, if it’s another agent) to notice, someone or something to decide, and something to enforce and marketing is focused on enforcement, while providing little details around detection and authorization, which inevitably gets murky in a real organization and running production workloads where disruption has business implications.
I understand how “kill switch” became the favorite catch-all term at the moment, because it sounds incredibly straightforward and effective, but as longtime security practitioners know, reality is far more nuanced than that.
So let’s walk through how kill switch became a headline, what’s marketing hype vs. technical reality, what a kill switch really is layer by layer, how it changes depending on the deployment scenario, and what happens after the “switch” is flipped.
How “Kill Switch” Became the Headline
First up is how the topic of a kill switch became a headline and the incidents that contributed to it, as well as the legislation and policy proposals that followed.
It should come as no surprise that the OpenAI and Hugging Face incident was a major part of this narrative, since it dominated headlines throughout the summer, and was a key part of Black Hat where the OpenAI team presented, directly engaging the cyber community. I’ll avoid rehashing the details of the incident though, as they have already been discussed ad nauseam.
One key thing to note in the incident that ties to this conversation is that the agent had found a JWT signing key and minted its own valid short-lived identity tokens and 24-hour forged service-account tokens, building a self-respawning fleet across various nodes. This meant revoking individual tokens or deleting pods couldn’t stop it until the signing key was rotated and the access broker was shut down.
There are other public examples tied to OpenAI as well, such as a DNS egress incident in September where they documented it in a follow-up misalignment report, showing how a P0 alert was raised, a human acknowledged it and a run was killed, but an automatic stop failed and the team spent several hours discussing/debating prior to authorizing to kill the run.
Google’s Threat Intelligence team has also documented how in a 2025 Salesloft Drift campaign actors were able to export Salesforce data and search it for secrets such as AWS keys (something that is now being done via ARTEX and automation), and the Google report showed that revoking the app’s OAuth token misses credentials already copied.
Following these incidents and others we saw various legislative and policy proposals either directly or implicitly advocating for a “kill switch” or mechanisms to shut down model and agent activities.
California SB 1047 (which was vetoed) called for a “full shutdown” across training models and compute clusters
California EO N-9-26 Directive 3 asks for recommendations by Nov 16, 2026 on a “frontier-model kill switch” with independent verification
EU AI Act Article 14(4)(e) requires high-risk systems to have a human-triggered “stop” button that halts in a “safe state” and NIST’s AI RMF Manage 2.4 pairs deactivation mechanisms directly with assigned human responsibility
Ironically nearly every mandate targets the model providers (the brain) while enterprise deployers own the runtime, identity, and network controls (the body and the hands).
While I understand the desire from lawmakers and policy circles to push for the ability to disrupt model activity, I also think it is creating a false sense of security by focusing primarily on the frontier corporations while ignoring the enterprises where the models and agents get deployed, and even more so when it comes to self-hosting and open-weight options where no single provider holds the “switch”.
Marketing Hype vs. Technical Reality
Now to point out the technical realities vs. the increasing marketing hype around this term.
While many vendors have begun to adopt the concept of a kill switch in their marketing copy, product documentation, and social media activity, there is a difference between the hype and reality.
There’s currently no independent benchmark that measures agent stop latency today and often while vendor press releases promise instant stops, their own technical docs carry real caveats and the details vary based on the type of agent, deployment scenario and other factors.
The most notable of course is CrowdStrike. While they weren’t the first vendor to use the term, they are the largest, and made the most waves with their announcement. They marketed the capability as taking control when agents go rogue, and in their launch blog it describes blocking model access at connected AI gateways.
However, endpoint termination was listed as coming “soon”, with no specific details around identity, SaaS, or browser layers and as practitioners in this space know, local or open-weight models don’t necessarily reach the gateway and endpoint coding agents or coworking tools can do quite a lot on the endpoint before traffic to a gateway occurs. This is important given endpoint coding agents have been the dominant deployment pattern throughout 2026, consisting of the bulk of usage.
Okta is another major vendor who pitched an “instant kill switch” in its gateway blog but the PR had a footnote tied to runtime-layer kill switch functionality down to already-issued tokens slated for GA in Q4.
MuleSoft launched an Agent Kill Switch GA in September of this year that provides a scoped, reversible freeze with a tamper-evident audit log, specifically for traffic passing through MuleSoft proxies.
Then you have the CSPs. Google Gemini Enterprise Agent Platform documents that its fastest stop is deleting the deployed agent, which is destructive, and gateway deny rules take ~2 to 7+ minutes globally. Meanwhile, AWS Bedrock AgentCore StopRuntimeSession terminates one session and its streams immediately, while policies only screen API paths explicitly configured (AWS StopRuntimeSession, AWS policy examples).
There’s also the labs and protocols such as MCP and A2A, where OpenAI’s Agents SDK defaults to run_in_parallel=True, meaning an agent can start executing before a guardrail tripwire fires (OpenAI Agents SDK). Meanwhile, MCP cancellation states receivers “MAY ignore” stop requests in some cases (MCP spec), and A2A states “success is not guaranteed” (A2A spec).
None of this is to say the vendors are being dishonest. They are indeed building out the capabilities needed to disrupt model and agent activity. It is just that the reality is much more nuanced than the headlines, as you can see it depends on the type of agent, deployment scenario, platforms involved, traffic flow and other criteria.
Ideally this nuance isn’t lost on the security buyers and practitioners on the other end of these purchasing decisions or expectations.
What a Kill Switch Really Is
Now that we’ve addressed the market side of things, let’s briefly walk through what a kill switch really is, layer-by-layer at a high-level.
Also, I want to note that this isn’t an exhaustive list either, and there will be more mechanisms to “kill” model and agent activity as well, but this is a good subset to discuss initially.
Model Access
First is model access (aka the brain). In late 2025 and throughout 2026 I’ve referred to the LLM/Model as the brain, and the agents as the hands and feet of AI and agentic systems. In the case of the model, the lab-level run termination or blocking model inference can function as the switch.
Then you also have AI gateways, which are primarily effective when every agent routes through a managed gateway, but as I can tell you from working with F500 organizations, the reality on the ground is much more complex, often involving rampant shadow usage, traffic not going through gateways, organizations having multiple disparate gateways and more.
This approach also is ineffective against local models, open-weights and unmonitored API keys.
Identity and Token Revocation
Next up you have identity and token revocation. This involves activities such as disabling an agent identity, revoking OAuth tokens, and propagating continuous session revocation. This comes with its own limitations, such as Microsoft Entra access tokens living 60-90m by default, conditional access not applying when an agent identity blueprint requires a token to create new agent identities, and revocation failing if an agent holds copied secrets or signing keys.
Networking and Egress
Another key mechanism involves the network. This includes egress allowlists and DNS/network isolation enforced outside the agent. In the OpenAI Sept 2026 incident I mentioned above, it involved an escape via DNS, and Anthropic’s containment testing showed an agent exfiltrating data 24 out of 25 times through an allowed domain, proving every permitted destination acts like a capability grant.
Processes, Sessions and Tool Permissions
This layer pairs killing the process or container (kubectl, EDR, StopRuntimeSession) with relaunch blocking (admission policies, host quarantine, scale-to-zero), plus pre-tool hooks and Cedar/gateway authorization (Claude Code hooks, AWS AgentCore policy). Even here, orchestrators can respawn killed pods unless blocked, and tearing down shared runtimes can kill healthy agents alongside the bad one—again, there’s nuance here.
Compute Gating, Infrastructure, and Spend Caps
VM/sandbox isolation (AWS Nitro sandboxes, Strands Box), cluster power-off, and financial circuit breakers/card limits. It’s worth noting that some such as NVIDIA have publicly stated “there is no kill switch” built into their GPUs. We continue to see a robust ecosystem of sandboxes and activity in this space, so I would keep an eye on it for sure as it will evolve.
As you’ll notice across all of these mechanisms, the key is that the authorization cannot live inside the model’s reasoning loop, which is a point made by CoSAI and OWASP Agentic Top 10. You’ll also notice among these options and mechanisms there are major considerations for shared infrastructure and workloads, business disruption and a balance to be found between mitigating cyber risk while potentially introducing operational risks.
Runtime enforcement of AI and agent activity must be deterministic and not left to probabilistic reasoning.
How the Kill Switch Changes by Deployment Scenario
I mentioned earlier how the kill switch changes depending on the deployment scenario, so let’s take a look at that.
Frontier Labs and Policy
Starting at the “lower” level of the stack sits the frontier labs and policy, either their own, or increasingly, especially in the face of political shifts in the U.S., regulations or Federal and State policies they may fall under.
The labs control training clusters, eval harnesses, and hosted APIs and face government shutoff or export mandates as we’ve seen, along with emerging regulatory requirements around model releases and gating.
Their hard problem is internal authorization, automated anomaly triggers, and preventing self-respawning eval agents, as we’ve seen in some of the past incidents where fully “killing” a run was more problematic than at first glance.
SaaS Agents
SaaS agents reinforce the tradeoffs we make in the shared responsibility model, and in the age of AI, agents in this deployment pattern run on someone else’s compute and network. Customers primarily hold two levers, which are vendor platform pauses, which include unpublished latencies and blind spots for unregistered shadow agents, and OAuth/identity revocation which leaves exported data or copied secrets untouched.
This also makes major assumptions about IdP integration and assumes the SaaS tenant, accounts, and agents are running under organizationally federated and governed identities, which is far from universal in my experience.
Endpoint and Coding/Cowork Agents
As I mentioned earlier, Menlo’s latest 2026 State of Enterprise AI highlights that Coding agents have experienced the most YoY growth and consume the majority of enterprise spend. This primarily has been done through endpoint coding agents in 2026 (although we’re seeing the rise of managed agents).
In this deployment scenario, organizations control the workstation, making EDR process kills, relaunch blocks, host egress filtering, and strict OS sandboxing the primary stops. That said, as I covered in my Human-in-the-Loop (HITL) illusion article, Anthropic found users approved roughly 93% of permission prompts, and VM sandboxes kept host EDR blind inside the VM.
The same isolation that keeps Claude contained also keeps host-based EDRs and responses out in some cases. As described by Anthropic, Claude Cowork appears to be an opaque hypervisor process and it can’t inspect the guest.
That said, Anthropic has responded to this with a beta option to allow IT and security admins to run a sensor inside the VM, so EDRs can see Claude activity within the VM. It works by having Claude’s VM copy your vendor’s sensor package into the VM upon starting.
Cloud and Custom Homegrown Agents
Last but not least we have cloud and custom homegrown agents. In this case builders can control the full stack if it is engineered before launch, including isolated per-session teardown, scoped model/tool proxy freezes, short-lived workload identities with signing-key isolation, out of band egress allowlists, subagent tracking and compensating transactions.
Where and how security teams invest first depends on what their agent deployment and utilization footprint looks like, and what their security tech stack has or doesn’t. It also depends on where they have the opportunity to exert effective governance and security and if they have been building robust collaborative relationships with other teams such as cloud, IT and of course their business peers.
The key point is that each layer looks different in terms of the technical integration and deployment realities and the extent to which an organization can “kill” activity and how.
After the Switch Trips
While nearly all of the discussion around kill switches thus far, and among the industry has focused on the “kill”, very little, if any, of the conversation has focused on what happens after that.
One cool resource I came across when preparing this article was the “COMPEL” framework, which tracks Mean Time to Kill (MTTK) alongside Mean Time to Acknowledge, targeting under 60 seconds after a breach.
However, real world scenarios and telemetry show enforcement is fast while alerting, pre-authorization, and decision ownership are where things can and will stall in the enterprise.
In OpenAI’s post Hugging Face incident document, they expect paged teams to pause activity if they cannot rule out a false positive within 30 minutes. I understand the delay, since training runs are incredibly costly, but in an age of “machine speed” attacks, or rogue agents, 30 minutes is a ton of time for things to be impactful.
Organizations will need to define their own SLAs around when to kill an agent, and who has the authorization to do so, which requires understanding the business criticality of the agent and processes it supports and what the impact to the business would be if it is disrupted.
Then you have verification and subagent cleanup. Stopping one process may leave behind spawned subagents, scheduled jobs, cloned repos, and valid tokens unless verified across process, token, and egress logs.
You also need to account for rollback, continuity and human handoff. Most switches stop the next step while leaving deleted databases or external changes intact. True recovery will require action logging, backups and compensating transactions. This includes plans for operating without the agent, and a clean handoff to a named human owner to pick up where the agent may have left off.
These more nuanced considerations have come up time and time again in the CISO and security leader conversations I’m having. Security leaders know for example, the first time we mistakenly “kill” an agent that disrupts a business critical process, we will be far more reluctant to ever do so again, because the last thing any of us want is to perpetuate security’s reputation as being a business blocker or the “office of no”.
Closing Thoughts
There’s obviously much more I can say about this topic and it is one the industry will continue to navigate as we look to move from talking point to real-world tactic to govern and secure AI deployments.
However, I wanted to put some thoughts together here, clarify what I feel like is becoming a bloated catch-all term, and highlight some of the nuance that the media, policy makers and marketers miss when it comes to organizations looking to implement a “kill switch” for their models and agents.
Understanding what your organization’s risk tolerance is, having a rigorous inventory of your AI estate and having real capabilities for runtime enforcement will dictate how much of this is a performative activity of security theater or actual capability your organization has.
You’ll notice how the public discourse on this topic has hyper focused on the technology aspect, as we always do, while neglecting people and process, which is inarguably more important and will play more of a key role in how this all plays out in practice.
As I like to say, security is a process, not a product.
Stay resilient.