Kill switch, pause and rollback: what 'stop the agent' has to stop

Every agent vendor says there is a kill switch. Ask what it stops. Usually the answer is "new runs". The run that is halfway through paying invoices keeps going. The batch queued behind it keeps going. The job scheduled for 2am starts on time. The agent still holds a live token to your ERP. That is not a kill switch. It is a sign on the door.

In one sentence: stop has to reach the action in flight, the queue, the schedule and the credentials, and resuming needs as much care as stopping.

/01Where it comes from

Industrial machines have emergency stops. The AI Act borrows the idea. People overseeing a high-risk system must be able "to intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure"¹. The Act adds a condition that is easy to skip. The procedure "allows the system to come to a halt in a safe state"¹.

NIST's AI Risk Management Framework asks for the organisational side. Manage 2.4 asks that responsibilities are "assigned and understood, to supersede, disengage, or deactivate AI systems" that behave outside their intended use². Mechanism and responsibility. A button nobody is allowed to press fails the second half.

Deployers of high-risk systems have a matching duty. If they have reason to think the system presents a risk, they inform the provider and the authority "and shall suspend the use of that system"⁴. You cannot suspend what you cannot stop.

/02What it actually is

Four targets. A real switch covers all of them.

1. The action in flight. The agent has sent "schedule payment" and is waiting for the ERP. Stopping the agent now does not recall the request. What you can control is the next action. The switch must stop the agent before it sends another. It must also record that the last one's outcome is unknown.

2. The queue. Agents often plan a batch: forty invoices, one after another. Stop has to empty or freeze the queue. Otherwise a stopped run leaves thirty-nine actions for the next worker to pick up.

3. The schedule. Many agents run on a timer. Kubernetes shows the trap. You can suspend a CronJob, but that "does not affect Jobs that the CronJob has already started"³. And the resume has its own warning: when suspend is lifted on a CronJob with no starting deadline, "the missed Jobs are scheduled immediately"³. Pause an agent for a week, resume it, and a week of runs may fire at once.

4. The credentials. An agent that is stopped but still holds a valid token can be restarted by anyone with access to it. For a serious incident, revoke the agent's credentials in the target systems. It is the only stop that holds even if the rest of the stack misbehaves.

Here is how the controls line up. It is illustrative.

/03Pause, stop and rollback are different

Pause freezes the work and keeps it. Use it when something looks wrong and you need an hour. The queue waits. Resume carries on.

Stop ends the work. Queued actions are cancelled and recorded as cancelled. Use it when the agent is doing something it should not.

Rollback undoes what happened. For money it usually does not exist. A payment that reached the bank cannot be un-sent by the agent. It can only be reversed by a person, through a recall or a credit. So plan reversal, not rollback. Know who in finance does it and how long it takes. Make sure the record tells them exactly which actions to reverse.

/04What it is good at, and what it is not

Good at. Limiting damage once you know something is wrong. Buying time for a person to look. Proving to an auditor that oversight is more than a policy line.

Not good at. Noticing. A switch only helps once someone decides to press it. That is a monitoring question: which signals tell you to stop, and who watches them. A spend cap is a switch that presses itself.

Where it goes wrong. The switch lives in the vendor's console and your team has no login. Or it sits with an engineer who is asleep. The AI Act says the oversight people must be able to use it¹. Put it in their hands.

/05What to check

1. /01

   What exactly does your stop button stop? New runs, the in-flight step, the queue, the schedule?

2. /02

   Who can press it, and do they have access today?

3. /03

   After a stop, what does the record say about the last action? Done, failed, or unknown?

4. /04

   What happens on resume? Do missed scheduled runs all fire at once?

5. /05

   How fast can you revoke the agent's credentials in each target system?

6. /06

   Who reverses a payment the agent made, and from what list?

Run the drill before go-live. Start a real batch in test, press stop halfway, and time it. Then read the record.

/06Where it is going

Our view: pause and stop become first-class, audited actions, the way approvals already are. Regulators will ask who pressed stop, when and why, and what happened to the queue. Tools that treat stop as "disable the bot" will look thin next to ones that stop cleanly and say so in the record.

/07Gatehouse fit

Gatehouse checks each action before it runs and stops it if the rules say no, so the stop sits in the path rather than in the agent. Every action that did land is in the record, chained by SHA-256, which gives your finance team the exact list to reverse. A global pause across all runs is a question to ask us directly, with a drill on a simulated batch. See the Gatehouse page for where the check sits.

/08At a glance