AI Security Incident Response: The Playbook Shape That Holds Up Under a Live AI Breach

An AI security incident response playbook follows the five-phase shape of any incident response process: detection, containment, eradication, recovery, postmortem. The failure modes that drive an AI incident are specific. A prompt-injected agent leaks data the user was not authorised to retrieve. The model produces an output containing customer PII that triggers a regulatory notification. A connected tool is invoked with parameters the model emitted in response to a malicious prompt. An employee pastes confidential data into ChatGPT and the data sits in a third-party logging tier the deployer has no contract with.

I want to walk through each phase as it actually runs during a live AI incident, what the SOC needs from the runtime architecture, and the postmortem template that ties the evidence back to the risk register.

Phase one: detection

Detection is the gating step. The faster the SOC sees the incident, the smaller the blast radius.

Real-time signals from the AI request boundary

The audit record stream from the AI request boundary is the SOC's primary detection source. Three signals trigger an incident.

A block rate spike on a specific route or role. A spike against baseline indicates either a campaign or an account compromise. The SOC pulls the audit records for the spike, identifies the common signature, and decides whether to investigate or to suppress.

An output-layer anomaly. The output inspection layer flagged a response containing data the user was not authorised to receive. The SOC pulls the request and response, confirms the unauthorised access, and identifies the exposure window.

A tool-invocation rejection at user level. A specific user's tool invocations are being rejected at higher than baseline. The account is either compromised, the session is hijacked, or the user is testing the boundary.

Signals from the rest of the stack

The SIEM correlates AI events with non-AI events. A user whose AI tool invocations spike at the same time their endpoint shows unusual process activity is a higher-confidence incident than either signal alone.

Time to detection

The deployer's target is under 15 minutes from incident start to SOC awareness for high-severity events. The audit record stream has to feed the SIEM at that latency. The SIEM has to fire alerts at that latency. The runbook has to put the alert in front of an on-call engineer at that latency.

Phase two: containment

Containment stops the damage from spreading without disrupting unaffected traffic.

Policy-level block on the affected vector

The fastest containment is a policy update at the AI request boundary that blocks the offending pattern. If the incident is a prompt injection campaign against a specific route, the policy update blocks the campaign's signature. The block is global within seconds.

User-level scope

If the incident is a single compromised user, the containment is a session revocation and a policy override that blocks the user's identity at the AI boundary until the SOC clears the account.

Tool-level scope

If the incident is a connected tool being misused, the containment is to disable the tool's invocation from the agent. The application's other paths to the tool remain functional. The model's path is closed.

Documentation during containment

Every containment action is logged with the audit record stream. The deployer's compliance function needs the timeline. Containment that happens without a paper trail creates its own audit problem.

Phase three: eradication

Eradication removes the root cause.

Identify the root cause

For prompt injection, the root cause is a missing or insufficient inspection rule. For an account compromise, the root cause is the credential or session that was abused. For a tool-misuse incident, the root cause is the policy rule that allowed the tool to be invoked under the conditions of the attack.

Update the controls

The detection rule, the policy rule, the tool authorization rule. The update is made in the configuration store. The deployer's change management process runs at incident speed during eradication: shorter review cycle, higher authorisation level, full documentation.

Validate against the campaign

Before reopening the route, the deployer validates the update against the campaign's known signature. If the campaign sends the same pattern, the new policy blocks. If the campaign mutates, the policy has to be expressed at a level that catches the mutation.

Phase four: recovery

Recovery reopens traffic and confirms the system is operating as expected.

Gradual rollback of containment

Policy overrides put in place during containment are reverted in stages. The block rate is monitored against baseline. A return to baseline indicates the eradication held.

User communication

If the incident affected users (account lockouts, blocked features, exposed data), the deployer's communication runs at incident speed. The communication is co-ordinated with the legal and PR functions because the wrong wording during recovery creates new exposure.

Regulatory notification

If the incident triggered a notification obligation under GDPR Article 33 (72 hours), HIPAA breach notification, NIS2 incident reporting, or a sector-specific regime, the notification clock started at detection. Recovery has to align with the notification timeline.

Phase five: postmortem

Postmortem closes the loop and feeds the evidence back into the risk register and the controls.

Postmortem template

The template has the following sections.

Evidence attachment

Every postmortem section references the audit record stream. The detected_at timestamp links to the audit record showing the first malicious request. The contained_at timestamp links to the audit record showing the policy override took effect. The controls_that_fired and controls_that_failed sections link to the audit records for each.

Feedback into the risk register

The risk register row corresponding to the materialised risk is updated. The residual rating reflects the incident. The controls list reflects the remediation. The related_incidents column links to the postmortem.

Feedback into the impact assessment

The impact assessment for the affected system is reviewed. The mitigation effectiveness is reassessed. The residual risk is updated. The next review date is pulled forward.

What the runtime architecture has to provide

The playbook depends on the runtime architecture in four ways.

Per-decision audit record at real-time latency

The audit record stream is the SOC's primary evidence source. The records have to be available at the SIEM within seconds of the decision. Batch-loaded application logs miss the detection window.

Policy updates at incident speed

Policy updates have to roll out across all gateway instances within seconds. A 30-minute deployment cycle is too slow for containment of an active campaign.

Identity-bound records

Every audit record carries the identity context attached at the request layer. Without identity context, the SOC cannot scope the incident to specific users.

Tamper-evident records

The records cannot be modified after the fact. A compromised application or a compromised insider cannot rewrite the audit trail to hide the incident.

DeepInspect

This is the problem DeepInspect was built to solve. DeepInspect sits at the AI request boundary as a stateless proxy. Every request and response produces a signed audit record committed before the response returns. The record carries identity, role, policy version, data classification, decision, and timestamp.

For incident response, the proxy is the SOC's primary evidence source. The record stream feeds the SIEM. The policy decision point updates at incident speed. The default fail-closed posture means a containment block holds even under load. The signed records support the postmortem and the regulatory notification.

The proxy operates in front of OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, and any HTTP-based model endpoint. The same evidence stream supports incident response across every model the deployer uses.

If you are deploying AI in a regulated environment and your AI incident response depends on the application's own logs, you do not have an evidence layer the SOC can rely on. Book a demo today.