An AI agent incident response plan should stop unsafe actions, preserve evidence, revoke or reduce authority, reconcile every external side effect, communicate with affected owners, and require tested corrective action before restart. Small businesses do not need an enterprise command centre, but they do need named decision-makers, accessible logs, vendor contacts, rollback methods, and a rehearsed workflow that works when the agent is still acting.
Playbook
An AI agent incident response plan should stop unsafe actions, preserve evidence, revoke or reduce authority, reconcile every external side effect, communicate with affected owners, and require tested corrective action before restart. Small businesses do not need an enterprise command centre, but they do need named decision-makers, accessible logs, vendor contacts, rollback methods, and a rehearsed workflow that works when the agent is still acting.
Scope and Guidance Status
Reviewed on 30 July 2026, this is an operational response template, not legal advice or a substitute for a regulatory reporting assessment. Use the separate EU AI Act and GDPR incident reporting workflow when personal data, serious harm, or regulated systems may be involved.
NIST SP 800-61 Rev. 3 is cybersecurity guidance that integrates incident response across preparation, detection, response, and recovery. The voluntary NIST AI RMF Core calls for defined accountability, incident identification, information sharing, and contingency processes for third-party AI failures.
The NCSC secure AI deployment guidance recommends AI-specific incident procedures, trained responders, backups, and useful audit logs. The OWASP Top 10 for Agentic Applications supplies threat scenarios involving goals, tools, identity, supply chain, memory, code execution, inter-agent communication, and cascading failures.
These authorities support the control objectives. The exact severity model, roles, and response times below are recommended practice.
Define an AI Agent Incident
Open the AI response plan when an agent:
• Takes or attempts an unauthorised action.
• Exposes, alters, deletes, or misroutes data.
• Sends an incorrect high-impact communication.
• Executes code or accesses a system unexpectedly.
• Uses a tool outside its intended scope.
• Repeats actions or creates duplicate side effects.
• Accepts malicious instructions from content, tools, or memory.
• Loses its human-approval control.
• Produces a material discriminatory or unsafe outcome.
• Cannot be reliably stopped or reconstructed.
• Changes behaviour after a model, prompt, or dependency update.
Quality defects can use a lighter path. A typo in a draft is not handled like an agent that issued refunds.
The Incident Control Framework
Use six verbs: detect, contain, preserve, reconcile, recover, learn.
1. Detect
Detection sources include policy blocks, unusual tool sequences, cost spikes, customer complaints, reviewer overrides, vendor notices, security alerts, and reconciliation mismatches.
Every alert needs:
• Workflow and trace ID.
• Observed event.
• Potential impact.
• Current action status.
• Owner and escalation route.
2. Contain
Contain at the narrowest level that stops harm:
1. Pause the specific workflow.
2. Disable the risky tool operation.
3. Reduce the agent to read-only.
4. Revoke its token or service identity.
5. Block the affected integration.
6. Isolate the environment.
7. Pause the provider or model only when necessary.
Do not rely on telling the model to stop. Enforcement should occur in orchestration, identity, policy, or integration layers.
3. Preserve
Capture:
• Original alert and timestamps.
• User, service, and agent identities.
• Prompt, policy, model, workflow, and tool versions.
• Retrieved documents and memory references.
• Tool requests and responses.
• Approval events.
• Before and after state.
• Errors, retries, and network destinations.
• Vendor status and communications.
Preserve raw evidence with access controls. Work from copies where possible. Do not let routine log retention delete records during investigation.
4. Reconcile
An agent incident can leave valid-looking changes across several systems. Create an action ledger:
Action: CRM field changed; Intended?: No; Authorised?: No; Actual state: Still changed; Corrective action: Restore prior value; Owner: RevOps
Action: Email sent; Intended?: No; Authorised?: No; Actual state: Delivered; Corrective action: Notify recipient; Owner: CS lead
Action: Task created; Intended?: Yes; Authorised?: Yes; Actual state: Duplicate; Corrective action: Close duplicate; Owner: Ops
Reconciliation is not the same as rollback. A sent message cannot be unsent reliably; it needs a compensating response.
5. Recover
Recovery requires:
• Root cause understood enough to prevent immediate recurrence.
• Credentials rotated or constrained.
• Affected state corrected.
• New control implemented.
• Regression case added.
• Staging and shadow tests passed.
• Monitoring active.
• Business owner approves restart.
Restore permissions gradually. Read-only or draft-only operation can validate the fix before external actions resume.
6. Learn
Complete a blameless but accountable review:
• What failed technically?
• Which assumption was wrong?
• Why did controls not prevent or detect it?
• What increased or reduced impact?
• Did the vendor meet its obligations?
• Which test, alert, permission, or training must change?
• Who owns each corrective action?
Track corrective actions to closure.
Severity and Authority Matrix
Define internal severity by consequence:
Severity 1: Critical
Continuing material harm, uncontrolled privileged action, large sensitive-data exposure, payment or destructive action, safety impact, or inability to contain.
Authority: incident commander may disable the workflow immediately and escalate to executive, legal, security, privacy, and relevant external support.
Severity 2: High
Customer-facing or employee-affecting error, limited sensitive-data event, repeated unauthorised attempt, or material integrity issue with known containment.
Authority: workflow paused; business and technical owners decide recovery.
Severity 3: Moderate
Incorrect internal action, recoverable duplicate, policy block revealing a weakness, or repeated quality failure.
Authority: constrain workflow and fix before expansion.
Severity 4: Low
Minor draft defect with no external side effect or sensitive data.
Authority: backlog or normal quality process.
These are internal categories. They do not determine whether an event meets a statutory reporting definition.
First-Hour Runbook
1. Open the incident record.
2. Name the incident commander and scribe.
3. Record detection and awareness times.
4. Pause or constrain the workflow.
5. Revoke exposed agent credentials.
6. Preserve logs and configuration versions.
7. Identify external actions still in flight.
8. Notify business, technical, security, privacy, and legal owners.
9. Contact the vendor if its system or evidence is needed.
10. Start the action ledger.
If the team cannot complete these steps without one absent administrator, the workflow has a resilience problem.
Implementation Steps Before an Incident
Assign roles
• Incident commander.
• Technical containment owner.
• Business reconciliation owner.
• Security and privacy lead.
• Legal and reporting contact.
• Communications owner.
• Vendor liaison.
• Restart approver.
One person may hold several roles in a small company, but each responsibility must be explicit.
Build controls
• Per-agent identity and revocable credentials.
• Tool-level kill switches.
• Read-only fallback.
• Append-only audit events.
• Before-and-after state.
• Idempotency and rollback.
• Offline backups for critical resources.
• Vendor emergency contact and export path.
Run tabletop exercises
Test at least:
• Prompt injection causes an unauthorised tool request.
• CRM cleanup changes the wrong records.
• Agent sends a customer message without approval.
• Provider becomes unavailable during a multi-step action.
• Tool credentials are exposed.
Measure time to pause, find affected actions, and decide restart.
Evidence and Artifacts
• Response plan and contact tree.
• Severity and authority matrix.
• System, data, and dependency inventory.
• Kill-switch and credential-revocation instructions.
• Evidence-preservation checklist.
• Action-ledger template.
• Vendor incident obligations.
• Notification decision links.
• Recovery and restart checklist.
• Tabletop results.
• Post-incident review.
• Corrective-action tracker.
Common Failure Modes
The only stop control is a prompt. The agent can continue through another path.
The team disables the model but leaves queued actions. Messages or updates still execute.
Logs show requests but not state changes. Reconciliation becomes guesswork.
Everyone assumes the vendor is investigating. No one owns customer impact.
The workflow restarts after one successful test. Edge and adversarial regressions remain.
The incident review blames the reviewer. The system design that made an unsafe approval easy remains unchanged.
Corrective actions have no deadline. Temporary controls become permanent weaknesses.
SMB Incident Plan Checklist
• [ ] Define what opens the AI incident process.
• [ ] Name commander, containment, reconciliation, legal, and restart owners.
• [ ] Maintain vendor emergency contacts.
• [ ] Give every agent a revocable identity.
• [ ] Implement tool and workflow kill switches.
• [ ] Provide read-only or manual fallback.
• [ ] Preserve traceable audit events.
• [ ] Record before and after state.
• [ ] Maintain an external-action ledger.
• [ ] Separate rollback from compensating action.
• [ ] Link regulatory reporting assessments.
• [ ] Test recovery before restart.
• [ ] Add each incident to regression evaluations.
• [ ] Exercise the plan with realistic scenarios.
• [ ] Track corrective actions to closure.
For the wider permissions and ownership model, see the AI agent governance guide.
FAQs
What is different about AI agent incident response?
Agents can make multi-step decisions and create side effects through trusted tools. Response must therefore address goals, prompts, memory, identity, tool calls, queued actions, and business-state reconciliation.
Is turning off the agent enough?
Not always. Revoke credentials, stop queued jobs, inspect downstream tools, preserve evidence, and reconcile actions already completed.
Who should approve restart?
The business risk owner should approve restart with technical and incident input. The person who implemented the fix should not be the only approver for a high-impact workflow.
How often should an SMB test the plan?
Test before external action is enabled, after material architecture changes, and periodically based on impact. Run an additional exercise after a serious near miss.
Should every AI error become an incident?
No. Define thresholds. Minor draft defects can use quality management, while unauthorised actions, data events, external harm, and loss of control require incident handling.
Get a 20-Minute AI Workflow Audit
AI Operator can run a focused tabletop, test containment and evidence, and produce a practical response and recovery plan for one workflow.