Most incident response playbooks were written before AI existed. Prompt injection leaves no malware. Agent compromise leaves no credential theft. RAG leakage leaves no network anomaly. This playbook was built specifically for AI — 6 phases, 5 incident categories, detection indicators, evidence preservation, containment procedures, and board reporting templates.
Traditional IR playbooks were designed around a predictable threat model: an attacker exploits a software vulnerability, gains access to a system, and leaves detectable artifacts — unusual network connections, modified files, authentication anomalies, malware signatures. Standard tools (SIEM, EDR, firewall logs) surface these indicators. Containment isolates the affected system. Recovery restores from backup.
AI incidents break every assumption in this model. A successful prompt injection produces no malware, no unusual network traffic, no authentication event, and no file modification. The attack happens entirely in the reasoning layer. The AI system processes a carefully crafted input and includes confidential information in its response — while every infrastructure monitoring tool reports green.
The visibility gap: In a traditional breach, your SIEM alerts. In an AI breach, your SIEM is silent. The evidence is in prompt logs and AI output logs — which most organisations are not collecting, not retaining, and not monitoring. By the time a user notices something wrong in an AI response, the incident may have been ongoing for days.
Four specific gaps make traditional IR insufficient for AI incidents:
Different evidence sources — prompts, AI outputs, retrieval records, agent action logs. Not firewall logs, not endpoint events.
Different attack patterns — semantic manipulation, not code execution. No signatures to detect, no payloads to reverse-engineer.
Different scope assessment — "what data was accessed?" requires replaying retrieval history, not examining exfiltrated files.
Different containment options — you cannot patch a prompt injection vulnerability the way you patch CVE. Containment requires prompt hardening, access control changes, and workflow redesign.
The 5 AI Incident Categories
Category
Severity
How It Happens
Evidence Location
Primary Damage
Prompt Injection
Critical
Adversarial input overrides AI instructions — direct (user message) or indirect (retrieved document)
Prompt logs, output logs
Data exposure, unauthorised actions, safeguard bypass
AI Data Leakage
Critical
AI includes confidential information in outputs due to weak retrieval controls, over-permissioning, or extraction attack
Organisation-wide exposure, cascading system failures
The 6-Phase AI Incident Response Lifecycle
Phase 1
️
Preparation
→
Phase 2
Detection
→
Phase 3
Investigation
→
Phase 4
Containment
→
Phase 5
️
Recovery
→
Phase 6
Post-Incident Review
️
Phase 1
Preparation — Before the Incident
Preparation is the phase most organisations skip and the one that determines whether they can respond effectively. A team that has never simulated an AI incident, has no AI asset inventory, and has no defined owners for their AI systems will spend the first 24 hours of a real incident trying to establish basics that should have been in place before launch.
AI Asset Inventory
Maintain a current inventory of all AI models, agents, RAG systems, vector databases, AI APIs, and third-party AI vendors. Each entry should include owner, data access scope, compliance classification, and last security review date.
Define Ownership
Business owner — impact decisions
Technical owner — implementation
Security owner — risk management
Compliance owner — regulatory obligations
AI-Specific Playbooks
Document specific response actions for each incident category: prompt injection, data leakage, agent compromise, model poisoning, supply chain. Generic IR procedures are insufficient.
Tabletop Exercises
Run AI-specific incident simulations quarterly. Scenario examples: a customer support AI starts returning competitor pricing data; an agent sends unauthorised bulk emails; a RAG system surfaces executive compensation documents to all users.
Enable Logging Now
Ensure prompt logs, output logs, retrieval records, and agent action logs are being collected and retained for at least 90 days before an incident occurs. You cannot preserve evidence that was never captured.
Escalation Contacts
Pre-define who gets called, in what order, for which severity levels. Include: internal security team, AI engineering lead, legal counsel, CISO, and relevant AI vendor support contacts.
Phase 2
Detection — Identifying the Incident
Fast detection significantly reduces impact. The gap between when an AI incident begins and when it is detected is typically where most of the damage occurs. Traditional detection tools — SIEM, EDR, firewall alerts — will not surface AI-native incidents. Detection requires AI-specific monitoring across four signal categories.
Prompt Anomalies
Jailbreak pattern signatures in inputs
Instruction override phrases detected
Repeated boundary-testing from single user
Unusually long or structured prompts
Indirect injection patterns in retrieved docs
Output Anomalies
PII or credential patterns in responses
Internal document names in outputs
System prompt content revealed
Responses referencing restricted data categories
Outputs inconsistent with system purpose
Agent Behaviour
Unexpected tool calls or API invocations
Actions outside normal operating scope
Unusual API call volume or timing
Workflow steps executing in abnormal sequence
Permission escalation attempts
️ Retrieval Anomalies
Cross-department document access
High-volume retrieval from single session
Access to restricted document categories
Retrieval patterns inconsistent with user role
Cross-tenant retrieval in multi-tenant systems
Detection without monitoring is impossible: These indicators are only detectable if you are logging prompt content, AI outputs, retrieval activity, and agent actions. If you are not collecting this data, your effective detection capability is zero — you will find out about incidents when a user reports something strange, not from your security tools.
Phase 3
Investigation — Understanding What Happened
Investigation must answer five questions before containment can be properly scoped: What happened? What was affected? Who was impacted? What data was exposed? Is the threat ongoing? The order matters — preserve evidence before containment actions modify systems.
Critical sequence: Preserve evidence before containment. Containment actions — disabling systems, rotating credentials, modifying prompts — can destroy the logs and records needed to understand the incident scope. Take 15 minutes to snapshot logs before touching anything. You cannot un-destroy evidence.
Evidence Preservation — What to Collect
1
Prompt Logs
Complete history of all inputs sent to the AI system during the incident window — including system prompt, conversation history, and any injected context. Preserve raw logs before any normalisation or filtering.
2
Output Logs
Every AI-generated response during the incident window. Cross-reference with prompt logs to identify which inputs produced anomalous outputs. These are the primary evidence of what data was exposed.
3
Retrieval Records
Which documents were retrieved from which sources in response to which queries. For RAG incidents, this determines the scope of potential data exposure — what the model had access to when it generated each response.
4
Agent Action Logs
Every tool call, API request, workflow execution, and external service interaction the agent performed during the incident window. For agent compromise incidents, this is the definitive record of what actions were taken on behalf of the attacker.
5
API Access Logs
Authentication events, rate limit hits, external service calls, and credential usage during the incident window. Cross-reference with agent action logs to identify any lateral movement through connected systems.
Attack Path Identification
After evidence is preserved, determine which incident category applies by working through the following questions:
Did the incident originate from user input (direct prompt injection) or from retrieved content (indirect injection)?
Did the AI output include information that should not have been accessible, or perform an action it should not have taken?
Were any agent tool calls made that deviate from normal workflow patterns?
Did the incident affect a single user session or multiple sessions — suggesting a persistent knowledge base compromise?
Is there evidence of a third-party component behaving differently than in prior periods?
Phase 4
Containment — Stopping the Damage
Containment actions differ significantly by incident category. Applying the wrong containment to the wrong incident type can destroy evidence, create service disruptions without stopping the attack, or miss the actual attack surface entirely.
Prompt Injection
Disable or restrict the vulnerable input pathway
Activate stricter input validation and filtering
Add explicit injection-resistance to system prompt
Monitor closely for recurrence before full re-enablement
Data Leakage
Identify and isolate the data source being leaked
Restrict retrieval permissions for affected data category
Suspend AI access to the affected knowledge store
Notify affected users or customers if required
Agent Compromise
Immediately revoke all agent tool and API permissions
Disable agent workflows pending investigation
Identify and reverse any unauthorised actions taken
Audit all systems the agent had access to
️ Model Poisoning
Roll back to last known-good model version
Suspend all model updates and fine-tuning pipelines
Validate model behaviour against baseline test suite
Audit training data and fine-tuning inputs for tampering
Supply Chain
Disable affected vendor integration immediately
Activate backup or alternative service if available
Initiate vendor security escalation process
Assess downstream impact on all dependent systems
Emergency Actions (all types)
Freeze all configuration changes to AI systems
Activate executive escalation per IR plan
Document all containment actions taken with timestamps
Restrict broad API access as precautionary measure
️
Phase 5
Recovery — Restoring Operations Safely
Recovery is not simply re-enabling the affected system. It is the controlled restoration of service after the root cause has been identified, a specific remediation has been implemented, and that remediation has been independently validated. Rushing recovery without validation creates the conditions for a second incident.
Root Cause Remediation
Address the specific vulnerability: harden prompts against injection, tighten retrieval access controls, reduce agent permissions, fix the training pipeline, review the vendor supply chain. The remediation must address the root cause, not just the symptom.
Security Validation
Run adversarial testing against the specific vulnerability before re-enabling. For prompt injection: attempt the attack pattern that triggered the incident. For retrieval leakage: attempt cross-permission queries. Never assume fixes work — verify them.
Controlled Restoration
Re-enable service incrementally. Start with a limited user group under close monitoring. Expand gradually as confidence builds. Maintain heightened monitoring for 72 hours after full restoration — attackers often attempt re-exploitation after a known incident.
Stakeholder Notification
Notify affected parties as required — customers whose data was exposed, regulatory bodies per applicable breach notification timelines (GDPR: 72 hours, HIPAA: 60 days), business partners with contractual notification requirements.
Phase 6
Post-Incident Review — Preventing Recurrence
The post-incident review is the most neglected phase and the one that provides the greatest long-term security value. An organisation that recovers from an AI incident but does not improve its defences will face the same incident again — often within months, from a more sophisticated attacker who has learned from the first attempt.
Root Cause Analysis
Answer six questions: Why did the incident occur? Could detection have happened sooner? Were response procedures effective? Were responsibilities clear? What controls failed? What would have prevented it entirely?
Update Playbooks
Every incident reveals gaps in existing procedures. Update playbooks with specific lessons — new indicators to monitor, faster containment steps, missing escalation contacts, evidence that wasn't being captured.
Control Improvements
Translate root cause analysis into specific control additions: new monitoring rules, tightened permissions, additional validation layers, improved prompt hardening, or architecture changes that reduce attack surface.
Executive Briefing
Brief the board and executive team on business impact, total cost, root cause, and the specific controls added to prevent recurrence. Frame in business risk terms, not technical detail. See the board report template below.
️ Identify Vulnerabilities Before They Become Incidents
The HexTyx AI Security Assessment scores your prompt injection resilience, agent security, RAG controls, and governance readiness — giving you the remediation priorities before a real incident forces them. Free, 10 minutes.
Strategic decisions during incidents. Authorises emergency expenditures. Final decision on business continuity vs security posture trade-offs.
Security Leadership
CISO
Overall security oversight and incident coordination. Interfaces with board and regulators. Approves containment decisions above a defined severity threshold.
Technical
AI Engineering Lead
Technical remediation of AI systems — prompt hardening, access control changes, model rollbacks, workflow modifications. Primary hands-on responder.
Determines regulatory reporting requirements. Manages audit documentation. Coordinates with regulators if notification is required. Ensures evidence preservation for compliance purposes.
Communications
Communications Lead
Internal communications to affected teams. External communications to customers if required. Media response if the incident becomes public. Coordinates with Legal on approved messaging.
AI Incident Response Metrics
These metrics measure IR programme maturity over time. Track them quarterly and use them to justify investment in detection and monitoring improvements.
MTTD
Mean Time to Detect
Average time from incident start to detection. Target: under 4 hours for critical, 24 hours for high severity.
MTTC
Mean Time to Contain
Average time from detection to full containment. Target: under 2 hours for critical, 8 hours for high.
MTTR
Mean Time to Recover
Average time from containment to validated full service restoration.
INC/MO
Incidents per Month
Total AI security incidents by category. Trending upward means either growing deployment or weakening controls.
PIR
Prompt Injection Rate
Prompt injection attempts per 10,000 queries. Baseline this in first 30 days; alert on 3× spikes.
DLE
Data Leakage Events
Confirmed incidents where AI output contained data outside intended scope. Target: zero for regulated data.
Board-Level Incident Report Template
Every significant AI security incident should result in a board-level briefing within 5 business days of containment. Use plain language — focus on business impact and decisions required.
AI Security Incident Board Report — Template
Incident Type
[Prompt Injection / Data Leakage / Agent Compromise / Model Poisoning / Supply Chain] — one sentence plain-language description of what the AI system did that it should not have.
When
Date/time incident began · Date/time detected · Date/time contained. Gap between start and detection should be highlighted if significant.
Business Impact
Data: what data categories were potentially exposed and estimated record count. Customers: number of customers potentially affected. Operations: which systems were disrupted and for how long. Financial: estimated direct cost to date.
Risk Rating
[Critical / High / Medium / Low] with a one-sentence justification based on data sensitivity, customer impact, and regulatory exposure.
Root Cause
One paragraph, plain language: what control was missing or failed, and why the incident was possible. Avoid technical jargon.
Status
[Contained / Remediated / Monitoring / Ongoing] with expected timeline to full resolution if not yet complete.
Regulatory
Notification obligations triggered, timelines, and current status of any required disclosures.
Controls Added
Specific controls being added to prevent recurrence — not generic statements about "improving security" but named, testable controls with implementation dates.
Decisions Required
Explicit list of any decisions the board needs to make — budget approvals, policy changes, vendor relationship decisions, public disclosure timing.
Master AI Incident Response Checklist
️ Preparation
AI asset inventory current and complete
Business, technical, security, and compliance owners defined for each AI system
AI-specific IR playbooks documented for each incident category
Tabletop exercise completed in last 6 months
Prompt logs, output logs, and agent action logs being collected and retained 90+ days
Escalation contact list current — includes AI vendor support contacts
Regulatory notification timelines documented per applicable framework
Detection
Runtime monitoring active on all production AI systems
Prompt injection pattern detection configured
Output scanning for PII and confidential data active
Agent action anomaly detection configured with baseline
Retrieval anomaly monitoring active
Alert thresholds defined and tested
Investigation
Evidence preserved before containment actions taken
All containment actions documented with timestamps
️ Recovery
Root cause identified and addressed (not just symptoms)
Adversarial testing run against specific vulnerability before re-enabling
Controlled restoration — limited user group first
Heightened monitoring active for 72 hours post-restoration
Affected customers or regulators notified per applicable requirements
All remediation actions documented
Post-Incident Review
Post-incident review completed within 5 business days
Root cause analysis documented
IR playbooks updated with lessons learned
Specific control improvements identified with owners and dates
MTTD, MTTC, MTTR recorded for programme metrics
Board-level report delivered within 5 business days of containment
Next tabletop exercise scheduled incorporating lessons learned
Frequently Asked Questions
Why doesn't a traditional incident response playbook cover AI incidents?
Traditional IR was designed for attacks that exploit software vulnerabilities and leave infrastructure artifacts — malware, unusual network connections, modified files. AI incidents exploit model behaviour rather than code. A successful prompt injection leaves no malware, no authentication anomaly, and no network alert. The evidence is in prompt logs and AI output logs. Standard SIEM and EDR tools produce no alerts. Without AI-specific monitoring and playbooks, the first indication of an AI incident is typically a user noticing something wrong.
What is the most important step in AI incident response?
Evidence preservation before containment. This is the step most organisations get wrong — they disable systems or rotate credentials immediately, destroying the logs and records needed to understand what happened, what data was accessed, and who was affected. The correct sequence is: snapshot all logs first (15 minutes), then begin containment. You can re-enable containment later if it was overly aggressive; you cannot reconstruct destroyed evidence.
How do you investigate a prompt injection incident?
Four steps: (1) Identify the incident window — when did anomalous behaviour start relative to normal baseline? (2) Replay prompt logs from that window — look for injection pattern signatures, unusually structured inputs, or role-override language. (3) Cross-reference with output logs — identify which prompts produced anomalous outputs and what information those outputs contained. (4) Check retrieval records if RAG is involved — what documents were retrieved when the anomalous outputs were generated? This tells you the scope of potential data exposure.
When is regulatory notification required for an AI incident?
Notification is required when personal data has been exposed. Key timelines: GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a breach involving personal data. HIPAA requires notification to affected individuals within 60 days for healthcare data (PHI). US state privacy laws vary — CCPA, NYPA, and others have their own timelines. An AI incident that exposed PII through retrieval leakage or prompt injection output almost certainly triggers at least one of these. Legal counsel should be involved in the notification assessment from the moment a potential data exposure is identified.
How do you contain an autonomous agent compromise?
Immediate steps: (1) Revoke all agent tool and API permissions — cut off the action layer entirely. (2) Disable agent workflows — stop all automated execution. (3) Identify and document all actions the agent took during the incident window from agent action logs. (4) Attempt to reverse any unauthorised actions — unsend emails if possible, reverse record modifications, alert external parties if the agent communicated with them. (5) Audit every system the agent had access to for evidence of unauthorised activity. Agent compromise incidents often have the largest blast radius of all AI incident categories because the agent may have taken hundreds of actions across multiple connected systems.