AI Agent Incident Response Playbook
Contain an AI agent incident by stopping unauthorized tool actions, preserving evidence, and checking downstream impact. Then identify the failed boundary, repair it, and verify recovery before restoring the agent's authority.
Updated September 11, 2026 ยท James Benton. This playbook is an operational checklist. Adapt its owners and containment mechanisms to the systems you actually operate.
1. Triage and appoint an incident owner
Record the detection time, affected agent, environments, available credentials, suspicious actions, and known customer impact. Assign an incident commander and a technical owner for each affected system. Treat suspected data exposure, unauthorized payments, and destructive actions as urgent even before the cause is known.
Separate a wrong answer, a blocked tool attempt, and a completed unauthorized action. They require different responses. Escalate based on impact and remaining authority, not on the agent's explanation or a single anomaly score.
2. Contain at the side-effect boundary
- Disable the affected action path or revoke the relevant credential. Use the narrowest scope that reliably contains the incident; use broader isolation when scope is unknown.
- Pause schedulers, queued jobs, retries, and delegated agents that can continue the action. Updating a prompt or policy does not necessarily cancel work already dispatched.
- Check policy propagation and caches across every executor. Confirm that old approvals and active sessions cannot continue to authorize new actions.
- Inspect in-flight requests at the destination. Cancel or reconcile them using that system's supported procedure; do not assume they stopped with the agent process.
- Run a safe negative test and inspect downstream logs to prove the affected capability is blocked.
Do not promise a universal five-minute containment time. Measure time to effective blocking in your own exercises. If an approval-only mode still permits sensitive output or ungoverned tools, it is not sufficient containment.
3. Preserve evidence without expanding exposure
Capture relevant policy versions, action identifiers, authorization records, execution outcomes, deployment versions, timestamps, and destination-system audit events. Preserve originals and record who collected each item. Restrict access and avoid copying secrets or unnecessary personal information into tickets.
ExecLayer's authority receipts can help link decisions to outcomes. Verify signatures using trusted keys and correlate records with the target system. Signed records protect the integrity of what was recorded; they do not establish completeness or prove that unrecorded activity never occurred.
4. Identify the failed boundary
| Observed evidence | Interpretation to investigate | Next check |
|---|---|---|
| Denied request, no downstream action | The tested boundary blocked the attempt | Investigate repeated attempts and possible compromise |
| Denied request, downstream action occurred | Possible bypass, race, or mismatched records | Trace credentials, adapter, action ID, and timestamps |
| Allowed request caused harm | Potential policy, state, or approval failure | Replay the decision with the original inputs and policy |
| No matching authorization record | Possible uncovered path or evidence loss | Inspect target logs, retention, and alternate executors |
A prohibited attempt alone does not mean the control failed. The key question is whether the prohibited effect occurred. Likewise, a valid signature does not show that the underlying permission was appropriate.
5. Repair and test before restoring authority
Correct the identified cause: excessive credential scope, permissive rules, stale state, missing approval binding, unsafe retry behavior, or an uncovered tool path. Preserve the original evidence before changing the system. Reproduce the incident safely, then verify the repaired path rejects it.
- Run the original failing case and legitimate neighboring cases.
- Test changed parameters after approval, expired policy, and revoked credentials.
- Exercise concurrent requests and retries against idempotent test destinations.
- Confirm denial and outcome records can be joined by action ID.
- Restore a limited workload, watch destination-system results, and define conditions for immediate isolation again.
6. Close with evidence and ownership
Document the event timeline, confirmed impact, remaining unknowns, containment proof, root cause, repair, and recovery tests. Assign each follow-up an owner and due date. Engage the appropriate legal, security, or privacy lead to assess notification obligations; this playbook does not prescribe a universal reporting deadline.
Track detection-to-containment and containment-to-recovery separately. Retest the kill switch and credential revocation path after integration changes. Use the governance checklist and runtime enforcement guide to turn the incident's lessons into release tests.
Frequently Asked Questions
Is a denied tool call an enforcement failure?
Not by itself. Correlate the denial with downstream evidence. A denied request that never executed indicates the tested boundary worked, although the attempt may still warrant investigation.
Does changing the policy stop in-flight work?
Not necessarily. Check queued jobs, retries, cached policies, active sessions, and already-dispatched requests at the downstream system.
When should an agent return to production?
After the cause is addressed, containment and recovery tests pass, and an accountable owner approves a limited restoration with monitoring and a working isolation path.