AI incident response is the practice of detecting, containing, investigating and reporting incidents involving AI systems — a successful prompt injection, an agent that acted outside its authority, sensitive data reaching a model, a compromised tool or model artifact. It borrows the shape of conventional incident response and breaks in specific places.
Where the conventional playbook breaks
Detection has no signature. Most AI incidents are not malware. They are legitimate-looking requests producing an outcome nobody intended, so there is nothing for a signature-based tool to match. The signal is behavioral, and it is visible at the request path or not at all.
Containment has a wider blast radius than expected. An agent acting on a borrowed credential can be stopped only by disabling that credential, which disables the person it belongs to. An agent with its own scoped identity can be revoked on its own — one of the practical reasons agent authority scope matters operationally rather than theoretically.
Reconstruction is usually impossible after the fact. Establishing what happened requires the prompt, the response, the tool calls, the identity and the policy version in force at the time. If those were not recorded when the call was made, they cannot be recovered — there is no equivalent of pulling the disk.
The four questions an investigation has to answer
What was asked, and what came back. Who or what was acting, and under whose authority. Which policy was in force and what did it decide. And what else did that principal do in the same session and adjacent ones.
The fourth is the one that decides scope. A single bad action is an event; the same agent doing it forty times over a week is an incident with a disclosure obligation attached. Answering it requires records that can be queried by principal across time, which is a property of tamper-evident logging rather than of an alerting tool.
The clocks
Reporting obligations attach to AI incidents through existing regimes rather than AI-specific ones, and the timelines are short.
NYDFS Part 500 requires notification to the Superintendent within 72 hours of determining a cybersecurity incident occurred, with an extortion payment triggering notice within 24 hours and a written explanation within 30 days. Under GLBA, the FTC Safeguards Rule requires notification within 30 days of discovering an event affecting 500 or more consumers. HIPAA requires security incident procedures as a named administrative safeguard.
None of these have an AI carve-out, and none wait while an institution works out whether a model was involved. That is why the determination clock — not the investigation clock — is the one to design against, and why an inventory that answers "what of ours uses this" in minutes is worth more than a better forensic tool. See examination readiness and runtime governance.
Related terms
Tamper-evident audit log · AI bill of materials · NYDFS Part 500 · AI red teaming · Full glossary
Put this in the path of your own agents.
Policy enforced inline between your agents and every model and tool they reach, with a record bound to the human who owns it.
Request a Demo Read the docs