An AI agent kill switch is a prepared set of actions that stops an agent and removes its ability to move money, across every layer where that ability lives: the running process, its credentials, its tools, its token allowances, and any authorizations it already signed. Stopping the process is the easy part. An agent that granted an allowance or signed an authorization an hour ago can still lose funds after it is shut down, because those permissions live onchain or in someone else's hands.
This article walks through revocation layer by layer, states what each step stops and what it does not, and ends with a short runbook. It complements two related guides: Human Approval for AI Agent Transactions covers how transactions are approved before they happen, and the pre-launch security checklist covers what to set up before an agent gets funds. This one covers what to do when it must stop now.
Key facts at a glance:
OWASP's agent cheat sheet asks teams to retain evidence of observed "circuit-breaker behavior" for production agents (OWASP).
A token approval lets a contract spend tokens "at any time" until it is revoked (Revoke).
Safe smart accounts let owners change the owner list and threshold, and adding or removing a module requires the threshold (Safe docs).
In Eco's Sauce SDK, launched October 28 2026, a signed authorization can be cancelled by nonce, but a cancellation that lands after the transaction ran changes nothing (Sauce docs).
What Is an AI Agent Kill Switch?
An AI agent kill switch is the set of steps that halts an agent and revokes every permission it holds to move funds. A complete one covers the process, the signing credentials, tool access, onchain allowances, and outstanding signed authorizations. A switch that only stops the process leaves the onchain permissions active.
The phrase suggests a single button. In practice, an agent's ability to move money is spread across systems that do not share an off switch. The model runs in one process. Its tools may run in another, such as an MCP server. Its key may sit in a wallet file, a key service, or a smart account. Its past actions may have left allowances on token contracts and signed messages that anyone holding them can submit. Each needs its own revocation step.
The OWASP AI Agent Security Cheat Sheet treats this as an engineering requirement: for production agents, teams should keep evidence of the approval, denial, timeout, or circuit-breaker behavior they observed in testing. That means the kill switch is tested, not assumed.
Who Should Be Able to Stop an Autonomous Agent?
At least one named person who does not depend on the agent to act, with access to every revocation layer: the host, the signer, the allowances, and any multisig the agent belongs to. That person should hold those permissions independently of the agent's own credentials, so a compromised agent cannot lock them out.
Two design choices make this possible. First, keep the stopping authority on a different key or account from the agent's. If the agent's key is the only one that can change its limits, a hijacked agent can loosen them. Eco's Sauce security notes describe this exact case: an agent running under the user's account can change its own policy file, and a loosened policy lifts its limits.
Second, prefer setups where the agent is never the sole authority. On a Safe smart account, owners and the confirmation threshold can be changed, so humans holding a threshold of keys can remove an agent's key as an owner. Eco's broader article on security risks of autonomous AI agents discusses governance of who can stop an agent.
How to Stop an AI Agent Before It Moves Money, Layer by Layer
Work from the fastest step to the most durable. Stop the process, cut signing access, disable signing tools, tighten or freeze wallet limits, revoke token allowances, and cancel any signed but unsent authorizations. The first three stop new actions; the last two remove permissions the agent already granted.
Layer | Action | Stops | Does not stop | Source |
Process | Kill the agent process and its scheduler | New decisions and tool calls | Anything already signed or approved onchain | |
Signing access | Revoke the agent's key in the key service, or move funds out of its hot wallet | New signatures from that key | Allowances and signed messages created earlier | |
Tools | Restart MCP servers without signing tools | Signing through those tools | Other signing paths on the same machine | |
Account | Remove the agent as an owner or module on a multisig | Agent-initiated execution through the account | Actions confirmed before removal | |
Allowances | Revoke token approvals the agent granted | Later spending by approved contracts | Spending that already happened | |
Signed authorizations | Cancel outstanding signatures by nonce; let short deadlines expire | Submission of cancelled signatures | Signatures already submitted; cancellations undone later |
Process and tools
Stopping the process and its scheduler halts new decisions. If the agent uses MCP servers, restart them without signing tools. For Sauce, the agent docs describe sauce mcp --no-wallets, which disables local wallet tools while still allowing unsigned transaction building. That only covers that server; the security notes warn that other tools on the same machine, such as a raw keystore or cast wallet, can still sign with the same key file.
Signing access
The durable fix is removing the key's usefulness. If the key lives in a service, disable it there. If it is a local hot wallet, move the balance to a wallet the agent never touched. Because the Sauce docs describe wallet files as hot wallets that should hold small balances, the amount to move is small by design.
What Does a Kill Switch Not Undo?
A kill switch does not reverse settled transactions, does not cancel allowances on its own, and does not recall signed authorizations already in someone else's hands. Onchain transfers are final. Each of these needs its own revocation step, and some losses that happened before revocation cannot be recovered.
Three cases cause most surprises.
Allowances. A token approval is a standing permission on the token contract. Revoke notes that a contract with permission to spend tokens can spend them at any time. Killing the agent does not touch it. Revoke it with a separate transaction.
Signed authorizations. Many systems let an owner sign a message that someone else submits. Eco's Sauce security notes call a signed cook "a cheque": whoever holds it can cash it once until it expires. Cancel by nonce with sauce sign --cancel, and note two limits: a cancellation that lands after the cook ran changes nothing, and a later cook can clear a cancelled nonce, so cancellation does not replace removing the signer's access.
Settled transfers. Public chains do not reverse confirmed transactions. Eco's article on when an AI agent sends crypto by mistake covers what recovery options exist.
This is why the strongest kill switch is partly built in advance. Exact approvals instead of unlimited ones, short deadlines on signed messages, and a named submitter for each signature all shrink what is left to revoke when the switch is pulled.
Design Choices That Make an Agent Easier to Stop
Agents are easiest to stop when their authority is small and borrowed. Give the agent a small balance, exact-amount approvals, short-lived signatures, and a role on an account that humans control. Then revocation is a few fast steps instead of a hunt through every contract the agent ever touched.
Small, refillable balances. Keep the agent's wallet at its working balance and refill from a separate process.
Owner-controlled accounts. In Eco's Sauce SDK, a private Pot (the account a program runs from) executes only with the owner's authorization, per Sauce. Revoking the owner key's availability to the agent stops new cooks on that Pot. EVM shared Pots, by contrast, are open to anyone, so they should be funded and emptied in the same transaction.
Sub-keys with narrow scope. The EIP-7702 specification describes sub-keys with weaker permissions, such as spending up to 1% of a balance per day or interacting with one application. A narrow key limits what must be revoked.
Exact approvals. Approve what the next call spends and verify no allowance is left, as the Sauce docs recommend.
Short deadlines and named submitters. An expired signature is worth nothing to anyone who copied it.
Kill Switches for Smart Accounts and Delegated Keys
Smart accounts make agents easier to stop because authority can be split. Humans keep the keys that change owners, thresholds, and modules, while the agent holds a narrow key or role. Revocation then means removing that role through the account, without touching the humans' keys or moving every balance.
On a Safe smart account, owners can be EOAs, other smart contract accounts, or passkeys, and the threshold can be specified and modified. Modules, which execute transactions through alternative access patterns, require the owner threshold to add or remove. An agent connected as a module or a below-threshold owner can therefore be cut off by the human owners in one confirmed transaction.
The EIP-7702 specification describes sub-keys with permissions much weaker than full account access. The narrower the sub-key, the smaller the blast radius while revocation is in progress. Eco's explainers on ERC-7715 wallet permissions and sessions and ERC-4337 agent wallets describe how session-scoped permissions are granted, which is the same surface a kill switch must revoke.
Where Kill Switches Fall Short
Kill switches act after the fact. They cannot reverse settled transfers, and each layer leaves a gap: process kills miss onchain permissions, key revocation misses allowances, and nonce cancellation can be undone by a later transaction from the same account. Speed matters, but prevention through small balances and narrow permissions matters more.
Race conditions. A cancellation or revocation submitted after the agent's transaction lands changes nothing, per the Sauce docs.
Hidden signing paths. Disabling one tool does not disable a key file readable by other tools on the same machine.
Chain coverage. Sauce's Pot and nonce controls apply on Ethereum, Base, Arc, and Solana, where it sends; Solana has a different trust boundary than EVM Pots, per the Sauce docs.
Kill Switch Runbook
Run the kill switch in a fixed order: stop the process, cut the key, disable signing tools, remove the agent from shared accounts, revoke allowances, cancel outstanding signatures, then review logs. Practice it on a test setup before launch so each step has a known owner and takes minutes, not hours.
Stop the agent process and any scheduler that restarts it.
Revoke or rotate the signing key; move remaining funds from the agent's hot wallet.
Restart MCP servers with signing tools disabled.
Remove the agent's key as an owner or module on any multisig, using the human threshold.
List and revoke token allowances the agent granted.
Cancel unexpired signed authorizations by nonce; confirm none were submitted.
Pull logs for every decision and transaction since the last known-good state.
FAQ
These are short answers to the questions developers and operators ask most often about stopping an AI agent and revoking its access to funds. Each answer stands on its own and points to the primary documentation used in this article, retrieved in November 2026, for readers who need the full detail.
Does stopping the agent process stop pending transactions?
No. A transaction already signed and broadcast is outside the agent's control. Revoke allowances and cancel signed authorizations separately.
Can a kill switch reverse a stablecoin transfer?
No. Confirmed onchain transfers are final. Recovery, if any, depends on parties outside the agent's control, starting with the recipient.
Should the agent be able to turn off its own kill switch?
No. Keep the stopping authority on keys and accounts the agent cannot access.
How often should the kill switch be tested?
Before launch and after every change to keys, tools, or accounts. OWASP recommends retaining evidence of circuit-breaker behavior observed in testing.
Where do spend limits fit?
Limits cap damage before a kill switch is needed. See AI Agent Spend Controls.
Sources and Methodology
Retrieved November 9 2026: OWASP AI Agent Security Cheat Sheet, Revoke, Safe docs, EIP-7702, and Eco's Sauce product page, agent docs, wallet policy docs, and security considerations.