An AI agent incident report records what the agent did wrong, who was affected, how it was detected and contained, which bound should have stopped it and why it did not, how the harm was put right, and what changed afterwards. Write it from the agent's filed verdicts, not from memory.
What makes an agent incident report different?
A normal incident report explains a system failure or a person's error. An agent incident usually sits between the two: the system worked, the agent did what its brief and bounds allowed, and the outcome was still wrong. The useful question is therefore not "what broke?" but "which bound let this through?". Was the role scope too wide, the certificate stale, a source wrong, a customer limit missing, or a guardrail absent?
That question has an answer only if every action and verdict is recorded. How to work through it is covered in how to investigate an AI agent incident.
When should you use it?
For any event where an agent's action, or failure to act, caused or could have caused harm: a wrong payment, a disclosure, an unapproved promise, a missed escalation, a pattern of poor answers. Near misses count, especially those caught by a person reviewing held work.
Open the report as soon as the incident is declared, and complete it after the post-incident review. The response steps themselves are set out in how to handle an AI agent incident, and the general discipline in what AI incident response is.
How do you fill in each field?
- Timeline is built from the verdict record: each action, its verdict, the bound that decided it, and the time.
- Bound analysis takes each of the five bounds in turn and asks whether it was set correctly and applied. Record a finding for each, even if it is "worked as intended".
- Source analysis checks the facts the agent relied on and where they came from. An action based on an external document has a different root cause from one based on a wrong record in your own system.
- Customer impact counts people affected and describes the harm in plain words.
- Redress says what was done for each affected customer.
- Regulatory reporting records whether the incident was reportable and to whom. Decide with compliance; do not guess.
- Changes link to change log entries, with re-test evidence.
The template
| Field | Guidance |
|---|---|
| Incident ID | Reference |
| Agent and capability | From the inventory, with depth at the time |
| Severity | Your incident scale |
| Detected by and how | Person, monitoring, customer, audit |
| Summary | Three sentences: what happened, impact, status |
| Timeline | Time, action, verdict, deciding bound |
| Containment | Suspension, limits, manual workaround; times |
| Bound analysis | Role scope, certificate, sources, customer limits, guardrails |
| Source analysis | Facts relied on and their provenance |
| Root cause | One primary cause, contributing causes |
| Customer impact | Number affected, harm |
| Redress | Action per customer |
| Regulatory reporting | Reportable? To whom? When? |
| Changes made | Change IDs and re-test results |
| Return to service | Date, approver, depth on return |
| Lessons | What other agents should change |
A filled example
A hypothetical lender's servicing agent.
| Field | Entry |
|---|---|
| Agent and capability | Servicing agent; change direct debit date; depth 3 |
| Detected by | Collections team noticed missed payments clustered after date changes |
| Summary | The agent moved payment dates for 60 customers to a date after their next due date had already passed, so one payment was skipped and recorded as missed. All 60 have been corrected. The capability is back at depth 3 after re-certification |
| Bound analysis | Role scope: correct. Certificate: valid, but test cases did not include changes made within five days of a due date. Sources: correct. Customer limits: no rule on changes close to the due date. Guardrails: not relevant |
| Source analysis | Due dates read from core banking (sealed); no source fault |
| Root cause | Missing customer limit for date changes within five days of the due date; certification cases did not cover this situation |
| Redress | Missed-payment markers removed; arrears fees refunded; letter of apology |
| Regulatory reporting | Compliance assessed as not reportable; recorded in conduct incident log |
| Changes made | CHG-260: changes within five days of due date held for a person. 300 near-due-date cases added to the certification set |
| Return to service | Depth 3 after re-certification, approved by head of servicing and operational risk |
The bound analysis is what makes this report useful. It shows that nothing malfunctioned; a limit was missing and the tests did not look for the gap. Both are fixable, and both are now fixed.
Shadow runs can produce near-miss reports in the same format; the shadow run report template links to it for that reason.
Where Pryme fits
Pryme files every verdict with the bound that decided it, so the timeline and bound analysis come from the record. A certification run that clears no depth drops the agent to depth 1 the same day, which often contains an incident before anyone files a report. See train, shadow, certify, widen.
Questions people ask
Who should write the incident report?
The agent owner's team drafts it, with operational risk reviewing the root cause. For serious incidents, someone not involved in configuring the agent should lead the investigation.
Should near misses get a full report?
Use a short version: summary, bound analysis, root cause, change. Near misses caught by reviewers show where bounds are thin before customers are affected.
How soon should the report be completed?
Open it immediately, issue an initial summary within one working day, and complete it after the review, typically within two to four weeks depending on severity.