AI Agent Kill Switches and Rollbacks: Safe Recovery

The first time an automated workflow sends three messages instead of one, the important question is not whether someone can find the stop button. It is whether that button stops the right thing, whether work already in flight is understood, and whether the team can recover without making the incident larger.

Give operators more than one switch

Sometimes the right response is to pause a queue. Sometimes it is to revoke one provider key, disable a single workflow, block one tenant, or require a person to approve every write. Keep those controls outside the agent path so a runaway workflow cannot decide that the switch should be turned back on. Read-only help can often remain available while risky actions are paused.

Be honest about what can be undone

A database update may have a rollback. An email, payment, or external API call may not. For each tool, document whether the team has a true rollback, a compensating action, or only an investigation and notification path. Keep the before-state, provider request ID, idempotency key, and response needed to choose the right recovery.

Stop the damage without deleting the story

When the switch is used, record who activated it, what scope it covered, which release and policy were running, and which task IDs were active. Redact private data, but do not delete the queue and traces before the team knows whether the first request succeeded before timing out. The evidence is what prevents the next operator from repeating the same action.

Practise before you need it

Test a retry loop, a leaked credential, a prompt-injection campaign, and a provider that returns success after the client times out. Confirm that someone can pause work from outside the agent and resume it in stages. Recovery is finished when the new test or guardrail is in place, not when the flag is switched back on.