How to Deploy an AI Agent Kill Switch That Actually Stops Rogue Agents
A practical guide for security and platform teams: eight places to stop a rogue agent, what each one misses, and how to prove it stopped everywhere.
TL;DR
- Blocking an agent’s next request isn’t the same as stopping it. Work it already started keeps running.
- A real AI agent kill switch does four jobs: refuse new work, cut off access, end running work, and prevent a comeback.
- No single control does all four, so combine them through one response service and verify each one.
Introduction
Suppose a developer asks a coding agent to ship a hotfix. The agent reads the repository, runs a build script, and submits a deployment. Then an operator notices the agent read a suspicious file and blocks its next model request.
The model request is blocked. But the build script keeps running, and the deployment is already on its way to production.
A useful AI agent kill switch must identify every system the agent can still act in and apply a control at the right boundary.
So where can you actually pull the plug? There are at least eight places, from coding-agent hooks and browser extensions to proxies, EDR, identity providers, and agent platforms. Each one stops something different. None of them stops everything.
Here’s how to choose those controls, combine them, and verify that an intervention worked, so that when you hit the kill switch, rogue agent activity actually stops everywhere it’s running.
An AI agent kill switch has four jobs, not one
Before you build a kill switch, decide how much it needs to stop: a single run, one agent, one device, one customer environment, or every agent you have. Then decide what “stopped” actually has to mean.
| Job | How you know it worked | In the hotfix example |
|---|---|---|
| Refuse new work | New requests, tool calls, and scheduled runs get rejected. | The next model request is blocked. |
| Cut off existing access | Keys, tokens, and sessions it already holds stop working. | Its deployment credentials no longer work. |
| End running work | Processes and jobs are confirmed killed or canceled, including work handed off to other systems. | The build script is killed, and the deployment is canceled. |
| Prevent a comeback | Retries, schedulers, replacement workers, and child agents can’t restart it. | A retry can’t start a new run. |
One more rule: keep the off switch out of the agent’s reach. Store the stop state and the credentials your response uses somewhere the agent can’t write to. If the agent can edit its own policy, remove whatever supervises it, or turn its identity back on, it can undo the kill switch.
1. Coding-agent hooks: block the next tool action
Coding agents like Claude Code can run a hook before every tool call. The hook checks a central stop flag and denies the action before it runs. For coding agents, it’s the most direct control point you have.
Block, then halt. Denying one tool call doesn’t stop the agent. It gets the denial reason, keeps working, and may try a different tool. In Claude Code, a PreToolUse hook can block a call (for example, with exit code 2), and returning continue: false with a stopReason stops Claude entirely. Read event names and return values together: the same exit code on the Stop event does the opposite and keeps the agent running. Make sure the hook covers every tool: shell commands, file edits, MCP tools, and subagents. (Claude Code hooks reference)
Keep the hook out of the agent’s reach. Claude Code reloads settings, including hooks, when they change mid-session, so an agent that can write to its project settings can rewrite its own hooks. Deliver kill-switch hooks through managed settings, which lower scopes can’t override. (Claude Code settings precedence) A hook also only governs the client it’s installed in. An unmanaged client skips it entirely.
Fail closed. By default, a PreToolUse hook that crashes, errors out, or times out lets the tool call go through. In recent versions of Claude Code, set onFailure: "block" so a broken hook stops the action instead. (Hook failure handling)
Know the limit. A hook stops the next action, not the one already running. A shell command that has launched, and anything it spawned, keeps going. That’s what happened to the build script in our hotfix example. Pair the hook with EDR or a process supervisor when running work must end.
2. Browser extensions: stop data before it leaves a managed browser
A browser extension can stop a prompt or upload before it’s sent, block navigation, or add rules that block requests to an AI service. It’s the right control for AI used through web apps and browser agents, in browsers your company manages.
Block before the request is sent. Timing decides whether anything is protected. Chrome separates rules applied before a request goes out from rules evaluated after response headers arrive. By then, the server already has the request body. (Chrome declarative request rules)
Block the request, not the button. Hiding a Send button doesn’t block every way to submit. Interception built for a specific app can recognize a prompt or an upload, but it breaks when the app changes. Network rules keep working whatever the page looks like, though they can’t tell what’s inside a request.
Close the side doors. Force-install the extension through enterprise management, and account for other profiles, private windows, and developer tools. Edge’s forced install doesn’t apply in InPrivate mode, and users with developer tools can alter an extension’s code; the DeveloperToolsAvailability policy addresses that gap. (Edge extension policy) Open connections need attention too: Chrome’s webRequest API sees a WebSocket handshake but not the messages sent over it afterward. (Chrome WebSocket limitations)
Know the limit. An extension only covers the managed browser it’s installed in. Personal profiles, unmanaged browsers, and shadow AI like agentic browsers installed outside IT’s control are out of reach, along with native apps, direct API clients, and cloud jobs. A task already handed to a remote agent service needs that service’s own cancellation or access controls.
3. Proxies and gateways: cut off the routes agents must use
An AI gateway can reject model requests from a suspended agent. An API gateway can deny access to tools and business services. A secure web gateway can block outbound destinations. Each works as a kill switch only when the agent’s traffic has no other way out.
Make the route mandatory. Enforce the gateway as the only path, and block direct access through other credentials or endpoints. Tie each policy decision to an authenticated caller. An agent_id header the agent sets itself proves nothing until it’s bound to a trusted identity.
Block where the damage happens. Placement decides the result. Blocking model calls stops the agent’s next request, but a script it already wrote can keep calling database or deployment APIs. An API gateway in front of those destinations stops that too.
Enforce, don’t just watch. A proxy integration has to be able to change and verify policy. Importing its logs gives you visibility, not the power to block.
Know the limit. Gateways rule on new connections, not ones already open. A DNS change doesn’t close an existing connection, and network policy updates don’t reliably end active traffic. Kubernetes, for example, leaves that behavior up to the network implementation. (Kubernetes NetworkPolicy behavior) Agents that never route through the gateway, such as ones talking directly between internal systems, are outside it entirely.
4. EDR and workload managers: end the work that’s already running
When the problem is a process that’s already running, endpoint detection and response (EDR) is where you can stop it. Depending on the product and operating system, that can mean running a response script, killing a process, or isolating the device. For cloud workloads, the container, VM, or sandbox manager plays the same role.
Accepted isn’t done. Microsoft Defender for Endpoint, for example, offers APIs for device isolation and live response. Live response runs scripts from a library, not a direct kill command, and allows one session per device, so an analyst’s open session can block an automated response. If the device is offline, the action waits up to two hours as Pending. (Device isolation, live-response API)
Target the right process. Map the agent run to the exact device and process. A reused PID or a generic name isn’t enough: killing every python or node process breaks unrelated work. Check each action’s granularity too. Defender’s stop-and-quarantine action targets a file hash, not a process, and deletes the file from the device. (Stop and quarantine file API)
Isolating and killing do different things. Isolating a device cuts its network access while local work keeps running. Killing a process stops it, but detached children, remote jobs, or a service manager can keep the work alive. For hosted workloads, also turn off whatever would recreate them, and keep the ability to collect evidence and get status updates during containment.
Know the limit. Confirm the work actually stopped at runtime. Kubernetes warns that force-deleting a Pod removes its API object without waiting for the process on the node to stop. (Kubernetes forced Pod termination) And EDR only reaches machines where it’s installed. Unmanaged laptops, cloud agents, and agents on vendor infrastructure are out of reach.
5. Identity and credentials: take away the agent’s keys
When an agent works across several services, cutting off its identity reaches all of them at once. Disable the agent’s account or grant, revoke the credentials it already holds where you can, and stop it from getting new ones.
Map the whole credential chain. That includes the agent’s own identity, model provider keys, delegated user tokens, cloud role sessions, and credentials it picked up for downstream tools. Each may be revoked a different way.
Close the two common gaps. First, a self-contained access token can be checked locally without asking the issuer whether it was revoked. Rejecting it right away takes an extra check at the resource server, and short token lifetimes only shrink the window. (OAuth token revocation, implementation note) Second, the agent may get a replacement. AWS’s role session revocation denies sessions issued before a cutoff about 30 seconds out, for every user of the role, but new role assumptions after that still succeed. Block the path to new access, not just the old session. (AWS role-session revocation)
Give each agent its own identity. Revoking a shared account takes down every workload that uses it. Separate identities let you contain one agent and leave the rest running.
Know the limit. Established application sessions may survive a revocation, so test them separately. And taking away access can’t recall data the agent has already read.
6. Tool servers and destination services: refuse the action itself
A tool server can refuse an operation even while the agent keeps running. That makes it a useful kill switch for MCP tools, internal APIs, database services and deployment systems.
Check every call against current status. Authenticate the caller, work out its agent and run from trusted information, and check whether the requested capability is still allowed. A suspended agent might lose everything, or a containment policy might allow read-only investigation while blocking writes, sends, and deployments.
Guard the resource, not just the tool. If the agent holds credentials that let it skip the tool server, enforce the block at the destination too, or remove that direct path.
Know the limit. Canceling a call that’s already running is a separate problem. MCP’s cancellation notice is optional, and a server may ignore it if the request can’t be canceled or has already finished. It’s a signal, not a guarantee, and it doesn’t undo side effects. (MCP cancellation specification) Long-running work needs its own handle: task-based requests use tasks/cancel instead. (MCP tasks specification) For other async tools, keep the downstream job ID. Stopping the MCP request alone may leave the job it created running elsewhere.
7. Agent platforms and orchestrators: stop runs and anything that restarts them
Use the platform’s own controls where they exist. Agents built into business platforms can often only be stopped from inside that platform. Amazon Bedrock, for example, lets an agent alias reject invocations with aliasInvocationState=REJECT_INVOCATIONS, and lets you read that state back to confirm it. Other aliases and routes need their own controls, including the test alias TSTALIASID, which points to the agent’s working draft. (Bedrock agent deployment)
Cancel or terminate, on purpose. Temporal treats cancellation as cooperative, so workflow code can clean up; termination skips that. Neither interrupts Activity code already running on a worker. A running Activity only learns to stop when it heartbeats, so one that doesn’t can finish its side effect after the workflow closes. (Temporal cancellation and termination) Cleanup keeps data consistent, but more actions from a possibly compromised workload may be unacceptable. Keep outside access blocked while you decide.
Block new starts. Stop work at the scheduler and the queue consumer, covering retries, delayed messages, webhook triggers, and child agents.
Know the limit. Blocked work doesn’t disappear. Quarantine it until someone decides what to do with it. Replaying it automatically when service resumes can recreate the incident.
8. Expiring permissions and fencing: stop workers you can’t reach
Some workers drop off the network before the kill switch reaches them, then reconnect later. For systems you control, two patterns from distributed systems handle this.
Make permission expire. Give workers short-lived, signed leases. A trusted gateway or supervisor checks the lease and refuses further actions once it expires, unless renewal succeeds. Decide up front how clocks, renewal timing, and failures are handled. You trade some availability for a firm limit on how long a lost worker keeps its authority.
Reject stale owners. A worker that comes back may still hold old authorization. Fencing tokens make the resource reject operations from an outdated owner; Hazelcast documents this for clients that resume after losing a lock. (Fencing-token explanation) An agent system can do the same with an authorization generation: a version number that rises each time permissions are issued. On suspension, raise the generation and have the destination reject anything authorized under the old one. The check has to happen at the destination, as part of the write. A check in the agent followed by a separate API call leaves a race.
Know the limit. An expired lease blocks new checks, not an operation admitted before it expired. And fencing needs support at the destination, or a service that controls the final write. You can’t assume it for arbitrary third-party APIs.
Turn eight controls into one AI agent kill switch
Each control above does part of the job. None of them does all four. When an agent goes rogue, a real kill switch pulls them together: the operator picks the scope once, and a response service turns that choice into every control available in that environment.
| Control | Refuse new work | Cut off existing access | End running work | Prevent a comeback |
|---|---|---|---|---|
| 1. Coding-agent hooks | Yes | No | No | Partly |
| 2. Browser extensions | Yes | Partly | No | Partly |
| 3. Proxies and gateways | Yes | Partly | No | Partly |
| 4. EDR and workload managers | Partly | Partly | Yes | Partly |
| 5. Identity and credentials | Yes | Partly | No | Partly |
| 6. Tool servers | Yes | Partly | Partly | No |
| 7. Agent platforms and orchestrators | Yes | No | Partly | Yes |
| 8. Expiring permissions and fencing | Yes | Yes | No | Partly |
Typical coverage. Your setup may vary.
Record the stop first, then act everywhere. Save the suspension so new work and new credentials are refused right away. Then send out the access blocks, cancellations, and process kills in parallel. Don’t wait on an unreachable laptop before blocking its access to your services.
Track every action until it’s verified. Each action moves through its own states:
| State | What it means |
|---|---|
| Requested | Someone, or a detection, asked for the stop. |
| Accepted | The target system took the command. |
| Applied | That system says the change took effect. |
| Verified | A targeted check confirms it worked. |
| Failed or unknown | It failed, timed out, or there isn’t enough evidence. |
Back to the hotfix. A full stop means the agent’s next tool call is denied, its build script has exited, its deployment is canceled, its credentials no longer work, and a retry can’t start a new run. Each one is verified on its own. Anything still unresolved gets reported, not assumed.
Keep the record. Log who triggered the stop, its scope, the policy version, each system’s result, and when it was verified. Make repeated stop commands safe to process, cap retries, and save enough of the original state to undo only what this stop changed.
Rehearse the kill switch before you need it
Don’t wait for a real incident to find the gaps. A good drill goes beyond an idle agent making a new request. Test:
- A shell command already running, plus a detached child process.
- A tool call that has already started a remote job.
- A valid access token, an open network connection, and an attempt to get new credentials.
- An unreachable endpoint or a disconnected policy service.
- A retry, scheduled trigger, or worker restart after the stop.
- Resuming with work still queued, plus an unrelated policy change.
Time all three moments. Measure when new actions are blocked, when existing access stops working, and when running work actually ends. Note any side effects that finish in between. How much delay you can accept depends on what the agent is allowed to do.
Restart on purpose. Recovery is its own decision. Review the queued work, check the runtime and credentials, then deliberately let the agent resume. A finished deployment, a sent message, or an exported file may need separate cleanup. Restoring access doesn’t undo them.
How we built this into Gödel Gate
Gödel Gate, our runtime security platform for AI agents, has had a layered kill switch for a few months now, and building it taught us most of what’s in this guide. We learned early that no single control would be enough, so Gate uses several at once.
Disarm the agent. A lightweight hook on each agent lets Gate stop it from processing any prompt, tool call, response, or file. An admin can contain one user’s agent or a whole team’s, give a reason, and set an optional time limit. A policy can trigger the same stop automatically.
Kill what’s running. Gate works with the EDR you already have to end the agent’s process.
Cut off the route. Gate adds an access rule for that specific agent at your proxy.
Keep the record. Gate records every lock and release: what was stopped, when, why, and by whom.
Gate covers coding, desktop and browser agents, as well as agents built on AI frameworks. It runs entirely in your environment. It doesn’t replace the controls in this guide. It connects the ones you already have.
If you’re working through the drill above and want to see how it maps to your environment, we’re glad to walk through it.
A kill switch you can prove
In the hotfix, the model request was blocked, and everything else kept going. An AI agent kill switch earns its name only when you know its scope, you’ve measured how fast it works, and you have evidence for every job it claims. Build that in before you hand agents real authority, not after a rogue one finds the gap.
Keep agents safe at runtime
See how Gödel's Gate fits your agent stack.