An AI agent kill switch is a control that halts an agent from outside its own loop: it ends the process, revokes the agent’s access, stops it from restarting, and records what happened. It matters because agents take actions, not just produce text, and an agent that is looping, misconfigured, or compromised can keep acting until something other than the model itself says stop. This week CrowdStrike made the idea a shipping product, and the same week showed why one switch is not enough.
What CrowdStrike announced
On November 3, 2026, at Fal.Con Europe in Barcelona, CrowdStrike introduced an AI Kill Switch inside Falcon Guardian. According to the company, it:
- terminates unauthorized agents in real time, enforced at the Gateway first and “soon on the endpoint”
- blocks a terminated agent from running again anywhere in the organization
- can cut the agent’s network access
- logs every intervention in an audit trail
The press release frames this as part of a broader “AI security and safety” push for enterprises, and CSO Online’s coverage positions it as a response to agents that act outside their mandate, whether through a bug, a bad prompt, or an attacker.
At the same event CrowdStrike said it had agreed to acquire Fiddler AI, an agent observability company, and Dreadnode, an AI security testing firm. The combined price was reportedly around $495 million, per the Wall Street Journal via Yahoo Finance. Read together, the three moves sketch a pipeline: watch what agents do, test how they break, and stop them when they do.
Why a kill switch alone is not enough
The most useful comment on the launch came from CrowdStrike itself. Forbes reported that the company’s chief product officer said a kill switch on its own is not “sufficient.” An outside expert quoted in the same piece warned that working around a kill switch is within the capabilities of production agents today: an agent that can spawn subprocesses, call other agents, or persist state somewhere the switch does not reach can outlive a single termination.
Forbes also noted that Congress is reportedly reviewing an “AI Kill Switch Act,” which would make this a compliance question rather than a product preference.
The same week supplied a concrete example of the problem. On November 6, The Hacker News reported research showing that a malicious browser extension could approve prompts and run code through Claude Desktop via Claude Dispatch. The agent itself did nothing wrong by its own lights; the approvals looked legitimate. A gateway kill switch watching for “unauthorized agents” would have seen an authorized one. That is the gap: the switch has to be triggered by something, and the trigger is the hard part.
| Control | What it catches | What it misses |
|---|---|---|
| Gateway kill switch | Agents calling models or tools through a monitored path | Agents using local models, unmonitored APIs, or stolen sessions |
| Endpoint kill switch | Processes on managed devices | Agents running in cloud sandboxes or a contractor’s laptop |
| Credential revocation | Any further authenticated action | Work already done, data already sent |
| Step and cost caps | Runaway loops | A short, well-targeted bad action |
| Human approval gate | Irreversible actions | Fatigue, rubber-stamping, spoofed approvals |
No single row is enough. The useful setup is the whole table.
How a small team builds its own kill switch
You do not need an enterprise security platform to get most of the value. If you run agents in production, even one, these seven controls are a weekend of work and will save you a bad month.
1. Hard step caps
Every loop gets a maximum iteration count. Not a soft target, a hard exit. Agents that “almost finished” at step 50 should fail and page a human, not continue to step 500.
2. Token and cost budgets
Set a budget per run and per agent per day, in dollars, and check it before each model call. Cost is the fastest signal that something is wrong; a stuck agent spends before it does damage.
3. Allowlisted tools
An agent gets the tools its job needs and nothing else. Do not hand a research agent a shell. If a tool can delete, send, pay, or deploy, it belongs behind a gate (see 7).
4. One revocable credential per agent
Never let agents share a service account. Each agent gets its own short-lived token or key, scoped to the minimum, so revoking one agent is a single call and the audit log attributes actions correctly.
5. A stop flag the loop checks every iteration
Store a flag somewhere the agent process cannot write, such as a database row or a feature flag service. The loop reads it before every action. Flip it from a dashboard, a Slack command, or a monitoring alert. This is your kill switch; everything else is what makes it reach.
6. An audit log you can read
Log every tool call with the agent ID, inputs, outputs, cost, and timestamp, to a store the agent cannot modify. When something goes wrong, the question is always “what did it do before we noticed,” and you need to answer it in minutes.
7. Human approval before irreversible actions
Anything that cannot be undone (sending email to customers, making payments, deleting data, merging to main) pauses and waits for a person. Make the approval come from a channel the agent does not control; the Claude Dispatch research is exactly why.
A minimal loop with these controls looks like this:
def run(agent, task, max_steps=40, budget_usd=5.00):
spent = 0.0
for step in range(max_steps):
if control_plane.stop_flag(agent.id):
audit.log(agent.id, "stopped_by_flag", step)
agent.revoke_credentials()
return "stopped"
if spent >= budget_usd:
audit.log(agent.id, "budget_exceeded", step, spent)
return "halted"
action, cost = agent.next_action(task)
spent += cost
if action.tool not in agent.allowed_tools:
audit.log(agent.id, "tool_denied", action)
return "halted"
if action.irreversible and not approvals.wait_for_human(agent.id, action):
audit.log(agent.id, "approval_denied", action)
return "halted"
result = tools.run(action, credential=agent.credential)
audit.log(agent.id, "tool_call", action, result, cost)
if agent.done(result):
return result
audit.log(agent.id, "max_steps", max_steps)
return "halted"The point is not the code. It is that the agent never decides whether it may continue; the surrounding system does.
Our take
CrowdStrike’s launch is good for the field because it treats agents as processes to be governed rather than chatbots to be prompted carefully. The acquisitions of Fiddler and Dreadnode suggest the company understands that termination is the last step, not the first. The honest admission that a switch is not “sufficient” is worth more than the feature.
For most teams the lesson is simpler. If you are running agents, you already need a stop flag, a budget, and an audit log. Build those now, before any vendor, legislation, or incident forces the question. If you are new to the territory, start with what an AI agent actually is, then look at the tools we track for options that ship these controls out of the box. We cover launches like this one every week in the newsletter.
Questions, answered
What is an AI agent kill switch?
A kill switch is a control that stops an AI agent immediately, outside the agent's own reasoning. It typically terminates the running process, revokes the agent's credentials, blocks it from restarting, and records what it was doing when it was stopped.
What does CrowdStrike's AI Kill Switch do?
It is a Falcon Guardian feature announced on November 3, 2026 that terminates unauthorized agents in real time at the gateway, blocks them from running again across the organization, can cut their network access, and logs each intervention. Endpoint enforcement is described as coming soon.
Can a kill switch stop every rogue AI agent?
No. CrowdStrike's own product chief said a kill switch alone is not sufficient, and researchers note a capable agent may work around a single control. Pair it with step caps, budgets, allowlisted tools, and human approval before irreversible actions.