Disclosure: BlueBear builds an agent platform with a credential and policy boundary, so we have a commercial interest in the containment section. This playbook is written to be run against any stack, and it names our own implementation only where a concrete field or behaviour makes the point clearer.
The short answer: four stages differ, and scoping is the one that surprises people
If you already have an incident response process, most of it transfers. Four stages do not, and the second and third are where teams lose hours.
| Stage | Ordinary IR | Autonomous agent IR |
|---|---|---|
| Detect | An alert fires on an error or an anomaly | Usually a person notices an effect — a wrong record, a customer email. Everything returned 200. |
| Contain | Isolate the host, block the address, disable the account | You cannot page the agent. Revoke what it can reach: credential, then connection, then runtime. |
| Scope | Which systems did the attacker touch? | Every run that identity made in the window, not the one you noticed. An agent repeats. |
| Remediate | Patch, rebuild, restore | Reverse the effects and change the policy. Never the prompt. |
This extends the existing AI agent incident response runbook, which covers the wider process and the roles; this piece is only about the four stages that behave differently.
Detection: the alarm is a person, so shorten the path to them
Accept the premise rather than fighting it. The characteristic agent incident is a permitted action that should not have been taken, and it produces no error. Your alerting will not see it.
What to do with that: make the human path fast. Two things are cheap and disproportionately effective. First, whatever the agent changes should be identifiable as agent-changed in the downstream system, so the person who sees the wrong record knows to raise it as an agent issue rather than as a data problem. Second, the support and operations teams who will actually notice should know that an agent incident is a thing and who to tell — this is a five-minute briefing that saves a day.
The detections you can automate are mostly rate and shape: a sudden change in the number of write operations, an operation class that has not been used before, an approval gate firing far more or far less than usual. These are worth having and will not catch the important case.
Containment: revoke the capability, not the process
The instinct is to kill the agent. That stops new runs and does nothing about the credential, which is what the incident is actually about and which may be usable from somewhere you are not looking.
The order that works:
- Revoke or rotate the credential at the boundary that holds it. If the agent holds the credential rather than a boundary, this step is a deploy, and your containment time is now measured in the length of your release process.
- Disable the connection or the specific operations. Narrower than revoking a credential and often enough — if the problem is one operation, disabling that operation keeps the rest of the system running.
- Stop the runtime. Last, because it is the least effective and the most disruptive.
Two properties determine whether this takes minutes or hours, and both are decided long before the incident. Can you revoke without a deploy? In our gateway, revoking a tenant API key is a status transition scoped by tenant rather than a code change, and keys are stored as a hash so a revoked key cannot be recovered from the database. Is the credential held by a boundary or by the agent? If the agent holds it, everything above is slower.
Test both. A containment step nobody has run is a containment step that will not work at 2am.
Scoping: every run, not the run
This is the stage that is genuinely different and the one that most often turns a two-hour incident into a two-week one.
A human attacker does a small number of things. An agent does the same thing repeatedly, on every input that matched. So the question is never "what did this run do" — it is "what did every run by this identity, in this boundary, in this window, do".
Answering that requires three fields recorded at the time: the actor, the boundary, and a run identifier tying each run's actions together. If those were recorded, scoping is a query. If they were not, scoping is an estimate, and you will have to tell whoever asks that it is an estimate.
This is the moment when a gap in your own recording becomes expensive rather than theoretical. It is worth naming one of ours: our session records carry a last_error column, and in our production database it is populated in none of the error rows — sessions are marked failed and the field that would say why is empty. The schema is right and no producer writes it. That specific shape of gap, a correct field with no writer, is the one that hurts during scoping, and it is worth auditing for in your own system while nothing is on fire. The reconstruction drill is a cheap way to find them.
Reversal: a workstream, not a step
Ordinary IR mostly stops things. Agent IR also has to undo things, and that is a separate workstream with its own owner.
Use the reversibility sort: freely reversible actions need a list and a script; actions reversible with effort need a list, an owner and a decision about whether reversal is worse than the original error; irreversible actions need a communication plan rather than a technical one.
The trap is double-reversal. If reversal is itself performed by automation and is not idempotent, running it twice creates a second problem. Idempotency is worth designing for on the reversal path specifically, because that path runs under time pressure with people improvising.
Remediation: change the policy, never the prompt
There is a strong temptation, after an agent incident, to add a sentence to the system prompt telling it not to do that again. Resist it, for three reasons: it is not a control, because the agent can be argued out of it; it produces no record, so it cannot be evidenced as remediation; and it will silently stop working at the next model change.
The durable remediations are:
| Remediation | What it changes | Evidenced by |
|---|---|---|
| Narrow the scope | The credential reaches fewer operations | The connection definition, before and after |
| Add an approval gate | The action class now requires a human | The policy, plus approval records once it fires |
| Make the write idempotent | A retry cannot double an effect | The idempotency requirement recorded on the action |
| Add the missing field | Next incident's scoping is a query | The record schema, and a stored row proving it is written |
All four are visible to a reviewer. None of them depend on the model behaving.
What to prepare before you need it
- A written answer to "how do we revoke this agent's access in under five minutes", tested.
- The scoping query, written and run once against normal traffic so you know it works and how long it takes.
- The reversibility sort, so the reversal workstream starts from a list rather than from a discussion.
- A named owner for reversal who is not the person doing containment.
- A one-page briefing for support and operations on what an agent incident looks like and who to tell.
If you operate in a regulated industry
Two extra obligations usually apply. Scoping accuracy becomes a reporting input, so the estimate-versus-query distinction above has consequences beyond engineering. And remediation has to be evidenced, which is another reason a prompt change is not an acceptable answer. Audit trails for financial services covers the evidence a review will ask for.
If you resell this to customers
Add a stage: notify by boundary. You need to know which customers were in scope before you can tell them, which again depends on the boundary being on the record rather than derivable from a query someone writes under pressure. Workspace boundary access control covers where that comes from.
Do this next
Time your revocation. Pick one agent, and measure how long it takes to make its credential unusable — with a stopwatch, in a non-production environment. That single number tells you more about your readiness than any document, and if it is measured in hours you now know the first thing to fix. Then read least privilege for AI agents to shrink the surface, or the security evaluation checklist if a vendor is part of the answer.
Questions people actually search for
- autonomous ai agent breach incident response runbook
Four things differ from ordinary incident response and the rest is the same. You cannot page an agent, so containment is revoking what it can reach rather than telling it to stop. Scope is every run that credential ever made, not the one that was noticed, because an agent repeats. Reversal is a distinct workstream because agents write, so the response includes undoing effects rather than only stopping them. And the fix is a policy or scope change, never a prompt change, because a prompt is a request rather than a control.
- how do you contain a compromised ai agent
Revoke the capability, not the process. Killing the agent stops new runs and does nothing about the credential, which may be usable from elsewhere and is what the incident is actually about. Containment order that works: revoke or rotate the credential at the boundary, disable the connection or the specific operations, then stop the runtime. Being able to do the first two without a deploy is what makes containment minutes rather than hours, and it is worth testing before you need it.
- typescript ai agent security incident response playbooks
The language matters less than where enforcement sits, but there is one implementation-specific point worth making. In a typed codebase the temptation is to express permissions as types and validate at the call site, which is a compile-time guarantee about code you wrote and no guarantee at all about what an agent chooses at run time. The control has to be an evaluated decision at the execution boundary that produces a record, not a type that produces confidence.
- how do you scope an ai agent incident
By actor and credential over the whole exposure window, not by the run that raised the alarm. An agent repeats: whatever went wrong once probably went wrong on every similar input since the exposure began. The query you need is every run by that agent identity, in that boundary, in that period, with the actions each one took - which is only answerable if actor and boundary were recorded at admission. If they were not, scoping is an estimate and you will have to say so.
- what should you do after an ai agent incident
Change the policy or the scope, and resist changing the prompt. A prompt change is not a control, produces no record, and cannot be evidenced as remediation to anyone who asks. The durable fixes are narrowing what the credential reaches, adding an approval gate on the specific action class, making the write idempotent so a retry cannot double an effect, and adding the field whose absence made scoping hard.