What is AI incident response?

AI incident response is the process an organisation follows when an AI system causes, or nearly causes, harm: detecting the problem, containing it, finding out what happened, putting things right for anyone affected, and preventing a repeat. With AI agents, containment comes first, because an agent keeps acting until someone stops it.

Why does AI incident response matter once agents act?

A faulty report is read by a few people. A faulty agent may send hundreds of wrong letters, apply the wrong fee to a batch of accounts or approve requests it should have held, all before the first complaint arrives. The cost of an incident grows with every minute between the first wrong action and the stop.

Agents also make incidents harder to read. The same input can produce different outputs, and the fault may lie in a source, a bound, a change to the model or a planted instruction rather than in code. A response plan written for system outages will miss most of this.

How does it work in practice?

The stages are familiar, but each has an agent-specific twist.

1. Detect. Signals include a jump in refusals or holds, reviewers editing more drafts, complaints, and alerts from connected systems.
2. Contain. Suspend the affected capability or drop the agent to depth 1. Leave held actions held. Do not wait for a diagnosis.
3. Assess. Use the verdict record to list every action the agent took in the window, which bound decided each one, and which customers were affected.
4. Remediate. Reverse what can be reversed through the proper human route, and contact affected customers. A final response letter template helps where complaints follow.
5. Fix and recertify. Correct the cause, then recertify before restoring depth.
6. Review. Run a post-incident review and record what changed.

Handling an AI agent incident sets out the steps in detail, and how to investigate an AI agent incident covers the assessment stage.

What does an example look like?

A motor insurer's agent sends claim acknowledgements at depth 3. A change to the policy library mislabels a cover type, and the agent starts telling some customers their windscreen damage is not covered. A handler notices the third such letter in an hour. The claims lead suspends the "send acknowledgement" capability within minutes. The verdict record shows 40 letters sent in the window, all citing the same policy source. The insurer writes to each customer, corrects the library, recertifies the capability and restores it two days later. The incident is logged using the AI agent incident report template.

How is it different from a post-incident review?

Incident response is the live process, from detection to remediation. A post-incident review comes after it: a structured look back at why the incident happened, why it was not caught sooner, and what will change. Response limits the damage; review stops it recurring. Both rely on the same records.

Incident response for AI also overlaps with regulatory reporting. Some incidents must be reported to a supervisor under rules such as DORA for EU financial entities; your plan should say who decides whether a report is needed.

Which terms sit close to it?

Kill switch: the containment tool. Rollback: returning an agent to a previous version. Runbook: where the response steps are written down. See our guide to deploying AI agents for how incident readiness fits into going live.

Where Pryme fits

In Pryme, every verdict in the append-only record names the bound that decided it. That makes the assessment stage a query rather than a reconstruction: which actions happened, on which facts, under which certificate. And a short Attest run keeps only the highest depth it cleared; one that clears no depth drops the agent to depth 1 the same day.