Blog Posts
Most enterprises have no playbook for a compromised LLM. Polygraf's AI incident response guide walks through detection, containment, forensics, and recovery for LLM incidents.
Your incident response runbook wasn't written for this. An LLM breach has no exploit signature – the data went out the back door through a legitimate channel. There is no malicious file, no CVE, no compromised credential. And from August 2026, the EU AI Act gives you as little as two days to report it. Here is the playbook that fills the void.
The majority of security teams have a mature incident response capability. They have runbooks, on-call rotations, forensic tooling and notification procedures that have been refined over years of dealing with malware, phishing and network intrusions. They then put an LLM in production and find that almost nothing of it maps cleanly to what happens when that LLM is compromised. A prompt injection is not a CVE. A poisoned RAG index is not a malicious file. An agent that exfiltrates data through an authorized API call leaves no intrusion signature whatsoever. The instinct to grab the existing runbook is right – but the runbook has gaps at every stage.
The good news: you don't need a separate incident response discipline. AI incident response is an extension of the capability you already have, and the frameworks to extend it now exist. NIST SP 800-61r3 provides the lifecycle, MITRE ATLAS provides the adversarial-AI threat taxonomy, and the OWASP LLM Top 10 provides the vulnerability categories. What is missing for most teams is the operational translation. This playbook is the translation: the incident archetypes, the six-phase response, the first 60 minutes and the regulatory clocks that start ticking the moment you become aware.
The core problem is that AI incidents violate the assumptions of traditional IR. A normal breach has a point of entry and an exploit signature. An AI breach often has neither – the bad action goes through a good, authorized channel, so your current detection and containment logic will miss it.
The gap that appears in almost every first AI incident: the forensic evidence of an LLM breach is the prompt and response history – and most organizations aren't logging it, or logging it without the integrity controls that make it admissible. When the incident hits, the single most important artifact for reconstructing what happened is the conversation log, and if it wasn't being captured before the incident, it can't be recovered after. Prompt/response logging with tamper-evident integrity is not a nice-to-have; it is the precondition for being able to respond at all.
Formalize the clusters of AI incident response LLM incidents not by vulnerability but by the similarity of their response workflow – because a security team needs different runbooks for materially different incidents. The six archetypes mapped to OWASP LLM and MITRE ATLAS cover the space.
The NIST SP 800-61 lifecycle is still valid – but each phase needs AI-specific procedures bolted on. What changes at every phase.
Prepare for the future: AI asset inventory, logging of prompts and responses with integrity controls, pre-approved containment actions (no one has to wait for the CEO to sign off at 3 AM) and a trained response team that knows the threats of AI.
AI-specific: log retention for prompts + responses; pre-authorized AI-gateway isolationAI incidents are not the same as security incidents. Watch for AI-related anomalies: model drift, strange prompts, strange retrieval in RAG, and output-level signals (jailbreak spikes) not just network and endpoint data.
AI-specific: prompt-pattern monitoring, output anomaly detection, RAG retrieval analysisStop the harm without destroying the evidence. For the vast majority of AI incidents this is to isolate the AI gateway, revoke an agent's tool access and credentials, or take a poisoned index offline, while keeping the prompt/response logs that are your forensic record. Containment is often a pause of a business critical service, which is why pre-authorization is important.
AI-specific: isolate AI gateway, revoke agent credentials, freeze the model versionEliminate the source. Depending on the archetype: revert to a good model version, re-index a clean RAG corpus, patch the injection vector, pin and rebuild broken dependencies, or remove poisoned records from the training data. Most importantly: do not change the AI system in ways that eliminate evidence when authorities are not yet notified if a reportable incident is in progress.
AI-specific: model rollback, clean re-indexing, dependency pinning, provenance re-verificationBring the AI system back into trusted operation with increased monitoring. Verify the model is working correctly on a test battery before putting it back in production, that the injection or poisoning vector is closed and monitor for recurrence – attackers will often retry a vector that worked once.
AI-specific: behavioral validation battery, staged re-enablement, recurrence monitoringLearn and report. Run the retrospective, feed the results back into detection and preparation – and – most importantly – fulfil your regulatory reporting obligations. This is where the EU AI Act Article 73 and GDPR clocks are met or missed. Document everything: the timeline, the decisions and the evidence.
AI-specific: regulatory reporting (Art. 73 / GDPR), red-team the vector, update runbooks"AI incident response is not a new discipline that you build from scratch – it is your existing IR capability, extended. The frameworks are already there. What teams are missing is the operational translation: the procedures, the logs and the trained reflexes for the AI parts of every phase."
— Polygraf AI, on closing the AI incident-response gapWhen an AI incident is confirmed, the first hour is everything. Here is a concrete sequence. Adapt the details to your context, but the order – contain, preserve, assess, notify – is the same.
This is the part that most AI teams miss until it's too late: the moment you become aware of a qualifying incident, legal deadlines start – and AI incidents can trigger multiple ones at once. As of August 2026 the EU AI Act adds its own tier of timeline on top of existing breach laws.
One AI breach of personal data can trigger both the GDPR 72-hour clock and the EU AI Act Article 73 clock at the same time – they are not alternatives to each other. The draft guidance of the Commission also reads the duty of the deployer to inform the provider "immediately" as within 24 hours. And the investigation limitation: under Article 73 you generally should not change the AI system in a way which would affect the cause analysis before informing the authorities. The breach of the EU AI Act reporting obligations is punishable with fines up to 15 million or 3% of the global turnover. Make the reporting decision part of the runbook – do not improvise it during the incident.
The best incident response is incident prevention. Polygraf's AI Risk Calculator models your organization's exposure and shows you which regulatory obligations (GDPR, EU AI Act, HIPAA and more) would apply if your AI systems were breached, based on your tools, data types and existing controls.
The time to build this capability is before the incident. If you can't check most of these, your AI incident response readiness has holes to fill now.
Polygraf AI inspects every AI interaction in-line – detecting injection and data disclosure in real-time, generates the tamper-proof logs your IR team needs, and blocks sensitive data at the gateway before it leaves. On-premise, sub-100ms, zero data egress.
At Polygraf, we envision a future where AI augments human capabilities without compromising safety, privacy, or ethical standards. Trust in our commitment to building this future with you.
© 2026 Polygraf AI. All rights reserved.
Our Solutions 
Regulations Your download will start now.
Please provide information below and we will send you a link to download the white paper.
Data Privacy 
Data Provenance 
Content Generation