Incident runbook

What to do when an agent does something that nobody expected. A runbook is a guide with steps for an incident.
The first 5 minutes stop the damage: cut the write tools, change to read-only, shut down. Then you diagnose with the action log and communicate. At the end, you write a blameless postmortem: an analysis of what failed in the system, not of who failed.
Copy the block with the button in its corner, or open the file on GitHub.
# Runbook: incident with [agent name]

<!--
How to use this template:
- A runbook is the written procedure for acting in an incident.
- Fill it in before the agent goes to production. During an incident there is no time to look for things.
- Test the switches once every [period]. An untested switch doesn't count.
- Each step is an instruction. Follow them in order.
-->

## Keep at hand

- Agent owner: [name, contact]
- On call: [rotation, contact]
- Incident lead: [role]
- Cut write tools: [command or panel]
- Switch to read-only: [command or panel]
- Shut down the agent: [command or panel]
- Human fallback queue: [where]
- Action log: [where and how to query it]
- Revoke the agent's credentials: [how]
- Cancel pending approvals and queued jobs: [command or panel]
- Revoke or rotate the model provider's API key: [how]

## Symptoms

Use this runbook if you see at least one of these:

- The agent took an action nobody expected: a message, a payment, a deletion, a data change.
- Spend rises outside the normal range.
- The log shows the same call over and over (a loop).
- Complaints arrive about made-up answers or someone else's data.
- The agent read content with odd instructions (possible prompt injection).
- The gate (the control that stops actions before they run) blocks many more actions than usual.

## First 5 minutes

1. Open an incident channel and write down the time (UTC). Name one person as incident lead.
2. If the agent is still acting externally, cut its write tools.
3. If you don't know which tool causes the damage, switch the agent to read-only.
4. If the damage continues, shut the agent down. Send new cases to the human queue.
5. Cancel pending approvals and any queued, retrying or scheduled jobs.
6. If you suspect injection or a data leak, revoke the agent's credentials.
7. If spend is running away, revoke or rotate the model provider's API key.
8. Don't delete or edit anything. Save a copy of the log and the traces (the step-by-step record of each run).

Don't ask the agent to explain what it did. Its explanation is not evidence. Look for the answer in the log.

## Diagnosis with the action log

| Question | Where to look | Answer |
|---|---|---|
| What was the first anomalous action, and when? | Log, sorted by time | [...] |
| What content did the agent read right before? | Run trace | [...] |
| Did the action go through the gate? At what level, under which rule? | Log: level and rule | [...] |
| Did someone approve it? With what information in front of them? | Log: authorization | [...] |
| Which credential did it use, and what scope did it have? | Log (identity) and credential manager | [...] |
| Which data, customers or amounts did it touch? | Log: parameters | [...] |
| Can it be reverted? Are the backups there? | Backups in the other account | [...] |

## Communicate

- Within [n] minutes: internal notice to the owner, security and [team].
- If customers are affected: a message with what happened, what we did and what they need to do. Write times and facts, no "may have".
- If personal data is involved: tell [data protection lead]. That person checks the legal notification deadline in each country.
- Next update: every [n] minutes until closed.

## Turning it back on

Turn the agent back on when all of this holds:

- [ ] We understand the cause.
- [ ] There is a new control that doesn't depend on the prompt.
- [ ] The case is in the evaluation plan and the agent passes it with pass^k.
- [ ] The agent returns in read-only or confirm mode, and moves up in stages.

## Blameless postmortem

<!--
The postmortem is the written analysis after the incident.
Look for the control that was missing, not for the person who made a mistake.
Ask "why did the agent have that permission?" before "who left it there?".
Write the timeline in simple past tense, with times.
-->

- Summary (three sentences): [...]
- Impact: [customers, amounts, data, time]
- Timeline (UTC): [time: event]
- Cause: [which control was missing or failed]
- What worked: [...]
- Actions, with owner and date: [...]

## Why this is here

- A production database and its backups were deleted through a token (credential) with too much scope. People who discussed the case read it as a permissions and backup failure: *An AI agent deleted our production database* (Hacker News, 2026).
- Teams that let an agent query production databases do it with controls already in place: stopping queries that don't end, a read-only role and a way to recover a dropped table: *Are people actually letting AI agents run SQL directly on production databases?* (r/dataengineering, 2026).
- If an agent deleted a database or leaked data, the scope was already wrong. Whoever builds and deploys the agent is accountable, not the agent: *AI agents aren’t ‘going rogue.’ Frontier labs are skipping security basics.* (r/cybersecurity, 2026).