Is killing the process enough to stop an agent from paying?

Only if you are certain the key is not held anywhere else. Terminating the process stops that instance, but another instance, a copy on another machine, or an attacker who exfiltrated the key can all still sign. If compromise is suspected, revocation is the stop with a real guarantee.

What is an onchain kill switch for an agent?

Revoking the session key's authority at the account, so the account rejects its signatures no matter who holds it. Enforcement sits with the validating side rather than in the software being stopped, which is what makes it hold against a process that is compromised or malfunctioning.

Why do session keys need short expiries?

Because expiry is the only stop that does not require anyone to notice a problem. It fires during exactly the failure modes where monitoring also failed. Re-registering keys regularly is modest overhead that converts your kill switch from a decision into a default behaviour.

Should the agent be able to revoke its own key?

No. If the agent's key can revoke, whatever compromised the agent can also block revocation. The controlling authority has to sit outside the blast radius of the thing it is meant to stop, which usually means a separate key held and reachable by a person.

What limits actually bound losses from a runaway agent?

A cap over a rolling period rather than per transaction, a small working float topped up on a schedule, and a rate limit on payments per minute. The first two bound the total, and the rate limit buys the time that monitoring and human response both need to be useful.

Building a Kill Switch for an Agent That Pays

A reliable stop for an autonomous payer needs onchain revocation of the spending key, not just termination of the process. Killing the process stops that instance; revoking the session key stops every holder of it. Short expiries, per-period caps, and a pre-tested revocation path give you a stop that works when you do not control the process.

Three different stops

Stopping the process. Terminating the agent stops the instance you are looking at. It is fast, it needs no onchain action, and it is the right first move when you control the runtime and trust that the key is not elsewhere. What it does not do is stop anything else holding the same key: another instance, a copy on a different machine, or an attacker who exfiltrated it. If the reason you are stopping the agent is that you suspect compromise, this is the weakest of the three and the one most likely to feel sufficient.

Revoking the key. Removing the session key's authority at the account means the account rejects its signatures regardless of who holds it. This is the stop with an actual guarantee behind it, because enforcement sits on the side that validates, not in the software you are trying to stop. It costs a transaction and it requires that the revoking authority is available.

Letting it expire. A session key registered with a short expiry stops working on its own. This is the only stop that does not require anyone to notice a problem, which makes it the one that works during the failure modes where monitoring also failed. It is also the least responsive, since it fires on a schedule rather than on demand.

These compose. Expiry is the floor, revocation is the deliberate action, and process termination is the fast partial measure you take while the transaction confirms.

Why client-side stops are not controls

A flag that tells the agent to stop paying, a configuration value it reads, a feature toggle in its own code: all of these depend on the agent behaving. They are useful for ordinary operations and worthless in the cases that motivate a kill switch, because a compromised or malfunctioning process is exactly the thing that will not honour them. The test to apply is whether the stop still works if the process actively ignores it. If the answer is no, it is an operational convenience rather than a boundary.

Making revocation something you can actually execute

Know who can revoke, and make sure they are reachable. Revocation is a transaction signed by the account's controlling authority. If that authority is a key held by one person who is asleep, your kill switch has a single point of failure with a time zone. Decide this deliberately: who holds it, how they are reached, and what happens if they are unavailable.

Keep the revoking authority separate from the agent. If the agent's own key can revoke, then whatever compromised the agent can also prevent revocation. The controlling authority must be outside the blast radius of the thing it is meant to stop.

Pre-fund and pre-test the path. A revocation transaction needs gas on the account that sends it, and a path nobody has exercised is a path that fails at the worst moment. Run it in a test environment, then run it once against production on a key you were going to rotate anyway.

Script it, do not document it. Under pressure, a documented procedure involving several manual steps produces errors. A single command that revokes a named key, with the address resolved from configuration rather than typed, removes the most likely failure.

Decide in advance what gets revoked. Revoking one key stops one spender. If an agent holds several, or if several agents share a pattern, you want a defined scope: this key, this agent, or every key of this class. Working that out during an incident wastes the window in which revocation matters.

Watch for the gap before confirmation. Between deciding to revoke and the transaction confirming, the key still works. On a fast network that gap is short and not zero, so terminating the process remains worth doing immediately even though it is the weaker stop.

Bounding damage so the stop matters less

Per-period caps, not just per-transaction caps. A per-transaction limit constrains one payment. An agent in a loop can make many payments that each pass it. A cap over a rolling window is what bounds total loss during the interval before anyone reacts, and it is the limit that most directly determines the cost of a bad day.

Keep the float small and top it up. The amount reachable by the session key is the real exposure. A small working balance refilled on a schedule caps damage structurally, without depending on any limit being configured correctly. A large balance with careful limits is a worse design than a small balance with simple ones.

Rate limit the agent's payment path. A cap on payments per minute turns a runaway loop into a slow leak, which gives monitoring time to fire and a human time to act. Without it, the interval between the first bad payment and the hundredth can be shorter than any alerting pipeline.

Alert on rate and on novelty, not only on totals. Spend approaching a cap is a late signal. Payments per minute exceeding normal, or a first payment to a new recipient, both fire earlier.

Prefer short expiries over long ones with revocation. Re-registering a key regularly is mild operational overhead that converts your stop from something requiring a decision into something that happens by default. Long-lived keys shift the burden onto detection, which is the part most likely to be missing.

Frequently asked questions

Is killing the process enough to stop an agent from paying?: Only if you are certain the key is not held anywhere else. Terminating the process stops that instance, but another instance, a copy on another machine, or an attacker who exfiltrated the key can all still sign. If compromise is suspected, revocation is the stop with a real guarantee.
What is an onchain kill switch for an agent?: Revoking the session key's authority at the account, so the account rejects its signatures no matter who holds it. Enforcement sits with the validating side rather than in the software being stopped, which is what makes it hold against a process that is compromised or malfunctioning.
Why do session keys need short expiries?: Because expiry is the only stop that does not require anyone to notice a problem. It fires during exactly the failure modes where monitoring also failed. Re-registering keys regularly is modest overhead that converts your kill switch from a decision into a default behaviour.
Should the agent be able to revoke its own key?: No. If the agent's key can revoke, whatever compromised the agent can also block revocation. The controlling authority has to sit outside the blast radius of the thing it is meant to stop, which usually means a separate key held and reachable by a person.
What limits actually bound losses from a runaway agent?: A cap over a rolling period rather than per transaction, a small working float topped up on a schedule, and a rate limit on payments per minute. The first two bound the total, and the rate limit buys the time that monitoring and human response both need to be useful.