What is an AI agent kill switch?

AI agents need a kill switch because they now take actions on real systems, and some of those actions go wrong faster than a person can step in. A chatbot that says something wrong produces a bad sentence. An agent that does something wrong can delete a table, email a customer list or pull credentials from a cloud metadata endpoint, all in the time it takes you to read this line.

Agents go rogue for ordinary reasons. A web page carries hidden instructions. A tool description has been tampered with. A goal drifts over 30 steps until the agent is solving a problem nobody asked it to solve. All it takes is an agent with access and a plan that went sideways.

The clearest public example so far is the incident covered in our OpenAI and Hugging Face incident timeline. Hugging Face counted about 17,600 actions by rogue agents. They ran through shell commands, raw HTTP and cloud metadata calls, paths an LLM, MCP or API gateway never sees. That detail matters for everything that follows, because a switch can only stop what it can see.

Controls built into the model or the agent harness help, but they cannot act as a kill switch, because the controlled party is also the control. System prompts, model guardrails and harness policies all live inside the thing they are meant to restrain.

Picture a teenager handed the house rules and the only key to the front door. A clever one reads the rules for what they leave out. Agents do something similar: they reason, and an agent that can read its own rules can also reason its way around them, especially when a prompt injection has given it a new goal.

There is a practical limit too. Each harness carries its own policy, so a company with agents on three frameworks has three rulebooks and no single view across systems or agents. These tools still earn their place. Ackuity, the Agent Execution Control Switch, runs alongside them, and our comparison of Ackuity and model guardrails covers how the two fit.

A gateway can stop the agent traffic that passes through it, but most agent actions never pass through one. LLM, MCP and API gateways sit on a few well-marked roads, and agents also use the back roads.

Think of a toll booth on a highway. It sees every car that drives through it and none of the cars that take the side streets. Of the 11 kinds of action an agent can take, 3 pass a gateway: LLM calls, MCP tool calls and API calls. Eight never meet one:

• CLI commands
• HTTP probes
• SQL queries
• IMDS metadata calls
• Credential searches
• Memory writes
• RAG retrieval
• A2A hand-offs

Even for traffic it does see, a gateway sees the call, not the context. It knows a request went to a database. It does not know which user asked, what the agent was told to do or what it did five steps earlier. Its rules look at one request at a time, so an attack spread across several harmless-looking steps slips past. Gateways, identity tools and SIEMs remain useful, and Ackuity feeds them the context they are missing. Our page on Ackuity and AI gateways goes into detail.

An AI agent kill switch should sit beside the agent, in the execution path: not inside the agent, not at the gateway. Close enough to see the agent's intent, plan and history, and far enough away that the agent has no control over it.

We call that spot, not inside the agent and not at the gateway, the Goldilocks zone. Inside the agent is too close, because the agent can reason around its own rules. Out at the gateway is too far, because most actions never pass and the context is missing. Beside the agent, every action has to go through the switch before it reaches a shell, a database or another agent, and the switch has the full story when it decides.

A kill switch stops the whole agent. A control switch stops the one action that is wrong and lets the rest of the work continue. Most incidents call for the second.

Take a hypothetical support agent that has handled 400 refunds correctly today. Refund 401 goes to an account that does not belong to the customer. Shutting the agent down stops refund 401. It also stops every good request queued behind it and leaves someone to investigate and restart. Blocking refund 401, or sending it to a person, fixes the actual problem.

Quarantine still has a job. It is the right last resort and the wrong first move. NVIDIA's Open Agent Safety Platform, launched on September 28, 2026, is a good market example. Its Sentry component runs on BlueField-4 hardware, and NVIDIA says it can quarantine an agent that tries to move outside its boundaries in milliseconds. NVIDIA OpenShell, part of the same platform, shows the placement idea: each agent runs in a sandbox, and a supervisor beside each sandbox is the agent's only way out, inspecting outbound HTTP, GraphQL and MCP traffic against policy before it leaves. Our explainer on what NVIDIA OpenShell is covers the platform, and kill switch vs control switch covers the trade-off in more depth.

Ackuity is an NVIDIA Inception member and is building an integration with OpenShell's supervisor middleware. The integration is in development; details are on our NVIDIA OpenShell integration page.

An Agent Execution Control Switch checks each agent action against its full context and a library of known attack patterns, then picks a response sized to the risk, all before the action runs. Ackuity is the Agent Execution Control Switch AI builders add to their agents, verifying every action before it runs.

The context comes from the Agent Security Context Graph, which assembles 29 signals across six dimensions for every action: the user, the agent, its intent and goal, the target system and data, its tools and supply chain, and its history. The context graph is built outside the agent, so the agent cannot edit it.

Detection is neurosymbolic. Rules, behavioral baselines and small language models each look at the action, and their findings are correlated across steps in real time. The checks cover 60+ threat models in 14 categories, mapped to NIST, OWASP and MITRE ATLAS, from memory poisoning to MCP threats.

Then the response ladder picks one of five decisions, in proportion to severity and confidence:

1. Allow: signed, logged and run.
2. Constrain: data masked or scope narrowed, then run.
3. Human in the loop: paused until a person approves it.
4. Block: dropped before it reaches the target.
5. Terminate: container shut down, kept for catastrophic cases.

Below the block threshold, Ackuity can alert your SOC, and it logs each action with its query, chain of thought and the data it touched. A decision takes 40 to 100 ms. That figure is decision time, measured separately from end-to-end latency.

You add Ackuity without changing agent code, through one of three ways in:

• Sidecar: an open source sidecar runs in the agent's pod, and an init container reroutes its traffic. The agent never knows. This gives the deepest coverage.
• API injection: for Copilot Studio and similar platforms where you cannot run a sidecar.
• Event pull: Ackuity reads events from OpenTelemetry, Langfuse or LangSmith. It is observe-only and the fastest way to start.

You choose per policy whether the sidecar fails open or fails closed, and a sidecar failure affects one pod, not your whole estate. Your data stays in your own cloud account. For stricter requirements, Ackuity can hold the agent's credentials and run the action on its behalf, handling mTLS. The full list of connectors is on our integrations page.

1. It runs outside the agent, so the agent cannot edit, disable or argue with it.
2. It sees every kind of action, including shell commands, SQL queries, metadata calls and A2A hand-offs that never reach a gateway.
3. It decides with context: who the user is, what the agent was asked to do and what it has already done.
4. It decides before the action runs, with a decision time you can measure.
5. It responds in proportion, able to constrain, pause or block one action, with whole-agent shutdown kept for catastrophic cases.
6. It has a failure mode you choose, open or closed, and a failure stays contained.
7. It keeps a record of each decision and its evidence, and that record stays in your environment.

NVIDIA, OpenShell and BlueField are trademarks of NVIDIA Corporation.