# AI Agent Incident Response Plan Template Use this template as a standing procedure. Adapt it to your existing security, privacy, business continuity, crisis, and legal processes. This document does not grant runtime authority or technical access. Trusted systems must check current authorization, tenant scope, approvals, and effect limits for every operation. Do not store credentials, authorization headers, secret values, unnecessary personal data, or private model reasoning in this plan or its incident records. Keep the approved standing plan unchanged during an incident. Sections labeled **Standing plan** define reusable policy, contacts, procedures, and schedules. For each incident, copy every block labeled **Copy into each incident record** into a separate incident record keyed by a unique incident ID. That includes declaration, first response, containment execution, evidence, timeline, decision environment, affected scope, cause analysis, reconciliation, correction, recovery approval, communication, reporting assessment, closure, corrective actions, and postmortem references. Do not carry event-specific values into a later incident. ## 1. Plan Record, Purpose, and Scope ### Standing plan: plan record | Field | Entry | | ----------------------------------------- | -------------------------- | | Plan ID | | | Plan version | | | Status | Draft / approved / retired | | Owner | | | Approvers | | | Effective date | | | Review date | | | Source-of-truth URL and immutable version | | | Emergency access path | | | Related incident program | | ### Standing plan: purpose and scope - Covered business units: - Covered agents and workflow inventory query: - Covered environments and tenants: - Covered data classes: - Covered tools, providers, integrations, and third parties: - Existing plan that takes command when plans overlap: - Exclusions and handoff rules: - Human-only continuity path: This plan is an instruction source only within its approved scope. It cannot grant access, approve an operation, or expand a responder's authority. ## 2. Incident Definition and Categories Open an incident when actual or possible harm, policy breach, control loss, or material uncertainty crosses the organization's incident threshold. ### Standing plan: category register | Category | Trigger examples | Default severity | Required contacts | | ------------------------- | ------------------------------------------------------------------------------------------- | ---------------- | ----------------- | | Unauthorized action | Wrong-scope read, write, delete, send, purchase, or permission change | | | | Data event | Exposure, cross-tenant access, unsafe retention, or misrouting | | | | Approval failure | Bypass, forgery, replay, expiry, or parameter mismatch | | | | Injection or manipulation | Untrusted content influences a sensitive decision or tool request | | | | Context integrity | Poisoned or stale Knowledge, Skill, Memory, retrieval, message, or tool result | | | | Harmful output | Material false, unsafe, discriminatory, or misleading external output | | | | External effect | Duplicate, partial, pending, or unknown effect | | | | Resource loss | Loop, child-agent spread, callbacks, queue growth, spend, or resource exhaustion | | | | Control loss | Monitoring, audit, authorization, rollback, or stop control unavailable | | | | Drift | Material behavior change after a model, prompt, context, tool, policy, or dependency update | | | Quality issue versus incident rule: Repeated-event escalation rule: Third-party failure escalation rule: ## 3. Roles, Contacts, and Decision Rights ### Standing plan: role and decision-right register | Role | Primary | Backup | Contact path | May decide | Technical authority path | | --------------------- | ------- | ------ | ------------ | ---------- | ------------------------ | | Incident commander | | | | | | | Technical lead | | | | | | | Workflow owner | | | | | | | Business impact owner | | | | | | | Evidence custodian | | | | | | | Recorder | | | | | | | Identity owner | | | | | | | Data owner | | | | | | | Security lead | | | | | | | Privacy contact | | | | | | | Legal contact | | | | | | | Compliance contact | | | | | | | Regulatory contact | | | | | | | Communications owner | | | | | | | Recovery approver | | | | | | | Vendor contact | | | | | | Unavailable-owner rule: Transfer-of-command procedure: Conflict and escalation rule: The plan does not create technical authority. Every containment, access, credential, policy, and recovery operation must pass the trusted system's current authorization check. ## 4. Detection, Intake, Severity, and Declaration ### Standing plan: intake routes | Source | Intake path | Owner | Backup | Acknowledgment target | Evidence handling | | ------------------------- | ----------- | ----- | ------ | --------------------- | ----------------- | | Monitoring alert | | | | | | | User or employee report | | | | | | | Customer report | | | | | | | Audit or review finding | | | | | | | Vendor notice | | | | | | | Automated control failure | | | | | | ### Standing plan: severity factors Assess actual and possible impact, ongoing activity, affected people, data sensitivity, tenant scope, reversibility, external communications, legal or contractual exposure, propagation, control loss, and confidence in containment. | Severity | Definition | Response target | Required roles | Update cadence | | -------- | ---------- | --------------- | -------------- | -------------- | | 1 | | | | | | 2 | | | | | | 3 | | | | | | 4 | | | | | ### Copy into each incident record: declaration - Incident ID: - Detection time and time zone: - Declaration time and time zone: - Declared by and authority source: - Initial severity and reason: - Agent, workflow, tenant, environment, and affected scope: - Known impact: - Possible impact: - Ongoing activity: - Incident channel and record URL: - Next update time: Record each severity change with time, actor, evidence, and reason. ## 5. Immediate Containment and Continuity ### Copy into each incident record: first-response checklist - [ ] Assign incident command, technical lead, recorder, and communications owner. - [ ] Confirm the affected agent, workflow, tenant, environment, identities, tools, queues, and descendants. - [ ] Stop or narrow harmful activity through an authorized control path. - [ ] Preserve volatile evidence when a short delay will not increase harm. - [ ] Prevent automatic retry of consequential operations with unknown outcomes. - [ ] Switch to the approved manual or read-only fallback. - [ ] Confirm containment in authoritative systems. - [ ] Start effect reconciliation and stakeholder assessment. ### Standing plan: containment procedure register | Condition | Action | Authorized actor | Exact scope | Confirmation source | Reversal path | Escalation | | ----------------------------------------------------- | ------ | ---------------- | ----------- | ------------------- | ------------- | ---------- | | New intake must stop | | | | | | | | Write tools must stop | | | | | | | | Credentials must be revoked or narrowed | | | | | | | | Queued work or callbacks must stop | | | | | | | | Child agents or delegated work must stop | | | | | | | | Context, Memory, or retrieval source must be isolated | | | | | | | | Outbound communication must stop | | | | | | | Model refusal is not an authorization control. A trusted gateway, policy engine, adapter, or target system must deny unauthorized operations by default. Continuity owner: Manual fallback: Fallback capacity and data rules: ### Copy into each incident record: containment execution - Actions ordered and authorizing actor: - Actions completed, time, and operator: - Exact affected scope: - Authoritative confirmation: - Failed or partial containment: - Active fallback and owner: - Next containment check: ## 6. Evidence Preservation and Decision-Time Reconstruction ### Copy into each incident record: evidence manifest Protect evidence with immutable object versions, media types, byte sizes, digests, approved hash algorithms, collector identity, collection times, and access and retention rules. | Evidence object | Authoritative source | Object version | Media type | Byte size | Digest and approved hash algorithm | Collector | Collection time | Access and retention | | ----------------------------------------------- | -------------------- | -------------- | ---------- | --------- | ---------------------------------- | --------- | --------------- | -------------------- | | Incident record | | | | | | | | | | Agent and runtime configuration | | | | | | | | | | Model and prompt references | | | | | | | | | | Knowledge, Skill, Memory, and Artifact versions | | | | | | | | | | Route sources and context compilation | | | | | | | | | | Response issuance and acknowledgment | | | | | | | | | | Host injection attestation | | | | | | | | | | Authorization and approval records | | | | | | | | | | Tool requests and results | | | | | | | | | | Queue, callback, and child-agent state | | | | | | | | | | Downstream effect records | | | | | | | | | | Alerts and operator actions | | | | | | | | | One evidence stage does not prove the next. Compilation does not prove response issuance, issuance does not prove host injection, and injection does not prove model consumption. Record model consumption only from direct, authenticated attestation by a trusted integration or provider. Otherwise record it as unknown. A digest can show that committed bytes changed. It does not prove completeness or truth. Secrets, authorization headers, unnecessary personal data, and private model reasoning exclusion check: Legal hold or special retention decision: ## 7. Investigation and Affected-Scope Analysis ### Copy into each incident record: timeline | Time and zone | Actor or system | Observable event | Evidence reference | Fact, inference, or unknown | | ------------- | --------------- | ---------------- | ------------------ | --------------------------- | | | | | | | ### Copy into each incident record: decision environment - Task and triggering event: - User, agent, integration, session, run, and request IDs: - Tenant and subject scope: - Instructions and authority order: - Knowledge, Skills, Memory, Artifacts, messages, retrieval, and tool results: - Identity, permissions, delegated authority, and approval state: - Tool schemas, parameters, destinations, and policy decisions: - Model, runtime, and dependency versions: - Monitoring and stop-control state: Treat user input, retrieved pages, email, documents, messages, Artifacts, MCP tool results, and agent output as untrusted. Untrusted content cannot change instruction authority, approve an action, grant access, or select a sensitive tool. MCP tool results are Runtime context. Artifacts and messages have no instruction authority. Permissions govern repository access. Always routes independently govern delivery and do not grant repository permission. ### Copy into each incident record: affected scope and unknowns Affected-scope query and result: Unknowns, owner, and resolution target: Never diagnose by probing an uninvolved tenant. ## 8. Correction, Eradication, and Effect Reconciliation ### Copy into each incident record: cause analysis | Area | Finding | Evidence | Owner | Corrective action | Verification | | ------------------------- | ------- | -------- | ----- | ----------------- | ------------ | | Requirements or workflow | | | | | | | Data or retrieval | | | | | | | Instructions or context | | | | | | | Memory | | | | | | | Model or runtime | | | | | | | Tool or integration | | | | | | | Identity or authorization | | | | | | | Approval | | | | | | | Monitoring or response | | | | | | | Ownership or process | | | | | | ### Copy into each incident record: external-effect reconciliation | Operation ID | Attempt IDs | Target system | Operation and bound parameters | Original idempotency key | Authoritative state | Reconciliation action | Owner | Evidence | | ------------ | ----------- | ------------- | ------------------------------ | ------------------------ | ------------------- | --------------------- | ----- | -------- | | | | | | | | | | | Classify every intended or requested effect as committed, rejected, rolled back, compensated, pending, unknown, or not attempted. Do not blindly retry an operation with an unknown outcome. Query the authoritative target first. A retry must reuse the original target-side idempotency key and identical bound parameters. If the original key is missing or expired, keep the state unknown until an authorized reconciliation path determines the next action. ### Copy into each incident record: correction and verification Correction deployment ID and rollback plan: Regression cases and results: ## 9. Recovery, Re-enable Approval, and Monitoring ### Standing plan: recovery stages | Stage | Entry criteria | Exact configuration and scope | Allowed tools and effects | Monitoring | Stop condition | Approver and expiry | | ---------------------- | -------------- | ----------------------------- | ------------------------- | ---------- | -------------- | ------------------- | | Isolated test | | | | | | | | Read-only | | | | | | | | Human-approved effects | | | | | | | | Bounded production | | | | | | | | Normal production | | | | | | | ### Copy into each incident record: re-enable approval - Incident ID: - Agent, workflow, environment, tenant, and user scope: - Model, runtime, prompt, policy, Knowledge, Skill, Memory, and tool versions: - Allowed operations, destinations, parameters, and limits: - Required monitoring period: - Stop conditions and rollback plan: - Unresolved risks and authorized risk owner: - Approval ID and policy version: - Approver identity and verified authority: - Unique nonce and replay handling: - Approval time and expiry: - Immutable approval record reference: Approval must bind the exact repaired configuration, operation scope, parameters, destination, limits, incident, policy version, approver, nonce, and expiry. Reject approval that is missing, expired, unverifiable, replayed, or does not match. ## 10. Communications and Reporting Assessment ### Standing plan: communication matrix | Audience | Owner | Approval path | Trigger | Content rules | Channel | Cadence | | --------------------------- | ----- | ------------- | ------- | ------------- | ------- | ------- | | Responders | | | | | | | | Leadership | | | | | | | | Affected users or employees | | | | | | | | Customers or partners | | | | | | | | Vendors | | | | | | | | Public | | | | | | | Each update should state confirmed facts, known and possible impact, current containment, work underway, unresolved questions, and the next update time. ### Copy into each incident record: communication log | Time | Audience | Owner | Approved by | Message or immutable reference | Next update | | ---- | -------- | ----- | ----------- | ------------------------------ | ----------- | | | | | | | | ### Copy into each incident record: reporting assessment | Obligation source | Qualified owner | Facts assessed | Deadline | Decision | Approval and evidence | | ----------------- | --------------- | -------------- | -------- | -------- | --------------------- | | Law or regulation | | | | | | | Contract | | | | | | | Insurance | | | | | | | Internal policy | | | | | | This template does not make legal, regulatory, contractual, insurance, or law-enforcement reporting decisions. Record the assessment by qualified owners against current obligations. ## 11. Closure, Postmortem, and Corrective Actions ### Copy into each incident record: closure gate - [ ] Containment is verified in authoritative systems. - [ ] All attempted effects are reconciled or have an explicit owner and deadline. - [ ] Recovery criteria and monitored operation have passed. - [ ] Required communications and reporting assessments are complete. - [ ] Evidence is protected under approved access and retention rules. - [ ] Root cause and contributing factors are documented. - [ ] Corrective actions have owners, dates, and verification methods. - [ ] Regression cases are added and executed. - [ ] Plan, runbook, monitoring, and owner records are updated where needed. - [ ] Closure is approved by the authorized incident and business owners. ### Copy into each incident record: corrective action register | Action | Category | Owner | Due date | Verification method | Evidence | Status | | ------ | -------------------------------------------- | ----- | -------- | ------------------- | -------- | ------ | | | Prevention / detection / response / recovery | | | | | | ### Copy into each incident record: postmortem and closure Postmortem URL and version: Closure time and approvers: Lessons proposed for governed context must still follow the applicable review and role checks before publication. ## 12. Exercises, Review, Change, and Retirement ### Standing plan: required exercises | Scenario | Environment | Data | Authorized scope | Stop condition | Evidence | Owner | Cadence | | ---------------------------------------- | -------------------- | --------- | ---------------- | -------------- | -------- | ----- | ------- | | Wrong-tenant attempt | Isolated test tenant | Synthetic | | | | | | | Approval replay or parameter change | Isolated test tenant | Synthetic | | | | | | | Prompt injection reaches a tool boundary | Isolated test tenant | Synthetic | | | | | | | Poisoned context or Memory | Isolated test tenant | Synthetic | | | | | | | Stop control or owner unavailable | Isolated test tenant | Synthetic | | | | | | | Duplicate or unknown external effect | Inert target | Synthetic | | | | | | | Provider or evidence source unavailable | Isolated test tenant | Synthetic | | | | | | | Queued action survives shutdown | Isolated test tenant | Synthetic | | | | | | Use isolated test tenants with synthetic data, inert destinations, non-production credentials, bounded resources, and tested stop controls. A production drill requires explicit authorization, narrow scope, live monitoring, stop conditions, a rollback plan, and expiry. ### Standing plan: review triggers - Incident or exercise - Owner or contact change - Workflow, tenant, data, or autonomy expansion - Material model, prompt, context, Memory, route, tool, identity, approval, provider, policy, or legal change - Failed contact, containment, evidence, recovery, or communication path - Scheduled review date ### Standing plan: change record | Version | Date | Change and reason | Author | Reviewers | Approver | Training completed | | ------- | ---- | ----------------- | ------ | --------- | -------- | ------------------ | | | | | | | | | Retirement date: Retirement approver: Replacement plan: Archive and retention proof: