AI Incident Response Plan for LLM Deployments: You Cannot Investigate What You Did Not Log

Google Mandiant's M-Trends 2026 report, built on more than 500,000 hours of frontline incident response, found that the median time between initial access and handoff to a secondary threat group collapsed from over eight hours in 2022 to 22 seconds in 2025. An incident response plan written for human-speed attackers assumes hours of dwell time that no longer exist. For LLM deployments the problem compounds, because the attack often flows through the AI request path itself, and most response plans have no visibility into that path.

I want to walk through an incident response plan built for LLM deployments, mapping each phase of the response lifecycle to the incidents that actually happen at the AI request layer.

The incidents an LLM plan has to cover

Four incident classes flow through AI request traffic and belong in the plan.

• Prompt injection driving data egress. A crafted input causes a model or agent to return or transmit data it should not. The attack path runs through the prompt and the response, which is traffic a request-layer control can see.
• Sensitive data leaving through a model. A user or agent sends regulated data to an external LLM. IBM found that one in five breached organizations had a breach linked to shadow AI, and this is the mechanism behind many of them.
• Agent policy bypass. An autonomous agent chains actions that individually pass policy and together exceed its authority, calling a model or tool it should not.
• Excessive-scope AI access. A compromised or over-permissioned identity uses legitimate AI access to reach data outside its need.

Each of these is an incident whose evidence lives in the AI request stream. An IR plan that only watches endpoints and network flows sees the aftermath, not the decision.

Mapping the response lifecycle

The standard lifecycle, prepare, detect, contain, eradicate, recover, and review, holds for LLM incidents. What changes is what each phase needs from the AI request layer.

Prepare. The plan names the AI routes in scope, the identities allowed on each, and the data classes that may cross the boundary. This is where the AI model inventory becomes an IR asset, because you cannot respond to an incident on a route you never knew existed.

Detect. Detection for LLM incidents comes from the request layer: a policy violation, an unusual data class in a prompt, an identity calling a model outside its pattern. IBM measured shadow-AI breaches at 247 days to detect, six days longer than average, and the gap traces directly to missing request-layer visibility.

Contain. Containment at 22-second attack speed has to be inline. A control that blocks the offending request before the model receives it stops the egress in the same motion that detects it. A control that only alerts leaves the 22-second window open. This is the argument for inline enforcement applied to incident response.

Eradicate and recover. Revoke or re-scope the identity, tighten the policy that was bypassed, and confirm no other route carries the same gap. The per-decision records tell you every request the affected identity made, which bounds the blast radius precisely.

Review. The post-incident review reconstructs the timeline from the audit records. This phase is where the plan either produces a defensible account or admits it cannot say what happened.

The forensic record the plan depends on

Every phase after detect depends on one artifact: a record of what each AI request did. Endpoint and network logs describe packets and processes. They do not carry the identity, the policy in effect, or the data classification at the moment an AI decision was made. A per-decision record at the request layer carries exactly that:

A record like this answers the questions an investigation asks: who, which model, what data, under which policy, and what the control did. Store it so it is tamper-evident, following the audit log immutability pattern, and the review phase produces evidence rather than conjecture. The same records feed the governance oversight package, so the board sees the incident in the same telemetry the responders used.

DeepInspect

DeepInspect is the control this plan runs on for the AI-request dimension of an incident. It sits at the AI request boundary as a stateless proxy between authenticated users or agents and any LLM, evaluating each request against identity-bound policy before the model receives it.

For containment, a request that violates policy is blocked inline, which closes the egress inside the attack window instead of alerting after it. For investigation, every request produces a signed record with identity, role, policy version, data classification, outcome, and timestamp, committed before the application sees the response, so the attacker cannot suppress the log by controlling the application. The plan gains a containment point that operates at machine speed and a forensic trail that reconstructs the decision.

If your incident response plan has no visibility into what your AI systems did with a specific request, the LLM incidents in your environment are unrecoverable after the fact. Book a technical deep dive at deepinspect.ai.