The incident reviews now happening around AI agents share a shape. An agent ran for weeks doing something wrong: approving invoices that should have been challenged, screening candidates against a stale rule, syncing records into the wrong system. Nothing intruded. No permission was exceeded. The system did what it was allowed to do, incorrectly, at machine speed, and the damage accumulated until a person happened to look.
Then the review starts, and it fails in the same place every time. Not on detection, which already happened, however late. Not on containment, which is usually a switch. It fails on reconstruction: nobody can say which model, which configuration, which permissions and which data produced the outcome, so nobody can say how far the problem extends, which decisions to re-examine, or what to tell the people affected.
Incident response as most teams practise it was built for security incidents, and the mismatch is the subject of this piece. A security incident asks who got in and what they touched. An agent incident has no intruder. It asks what the system decided, on what basis, under whose authority, and what can still be undone, and those are questions a security log was never designed to answer.
What makes an AI agent incident different from a security incident?
In a security incident, the actor is unauthorised and the evidence question is about access: entry point, lateral movement, exfiltration. In an agent incident, the actor is your own system operating inside its granted permissions, and the evidence question is about judgment: what it concluded, from what inputs, and whether anyone was positioned to catch it.
That difference decides what a useful log looks like. The standard telemetry stack records identity, action, timestamp, source and result, which is exactly what tracing an intruder requires. Run those fields against an agent incident and they confirm the one thing you already know: the agent acted within its permissions. An access log cannot distinguish a correct approval from an incorrect one, because both look identical at the access layer.
The failure compounds quietly. Because nothing was breached, no alert fires. Because the agent's actions are individually legitimate, each one passes review, if anything reviews it at all. The incident is not an event; it is a pattern across weeks of events, visible only to someone reconstructing decisions in sequence. Which is why the discovery is so often accidental: a vendor calls about a duplicate payment, a candidate complains, a reconciliation fails.
What questions does an incident review actually have to answer?
Seven, in rough order of urgency. Is it still happening. What exactly did the agent decide in the triggering case. What did it read before deciding. Which version of the system made the decision. Who authorised the agent to make decisions of that kind, and who could have stopped this one. How many other decisions are suspect. And what can still be undone.
The first is the halt question, and it is architectural rather than forensic: a stop that reaches running execution, leaving the system in a state someone can reason about. The EU AI Act's Article 14(4)(e) frames this as interruption to a safe state, and what a safe halt means mid-task is a design problem examined in the Article 14 piece.
The second and third are the reconstruction pair. A decision record that carries the conclusion but not the inputs answers half the question, and the wrong half: the review needs what the agent read, because the defect usually lives there, in a stale document, a wrong retrieval, a poisoned field.
The fourth is the question teams most reliably cannot answer. An agent's behaviour is a function of an LLM on the vendor's schedule, a prompt someone edits, a retrieval corpus that shifts, and a tool set that grows. A review that cannot say which combination was live at decision time cannot separate the runs that share the defect from the runs that do not.
The fifth is accountability in the plain sense: the named owner, the authorisation scope in force, and the checkpoint that either fired or did not. If a human approved the triggering action, the review needs to see the approval and what that person was shown. An approval given in two seconds against a wall of trace output is a fact the record should preserve, uncomfortable as it is.
The sixth is blast radius, taken up below. The seventh is the reversal question, and it is the one with a clock on it: undone early, a wrong payment is a recovery; undone late, it is a loss with a notification obligation attached.
What do regulators require you to be able to reconstruct?
The reconstruction standard is not a best practice; it is the operative language of several instruments. The EU AI Act's Article 12(2) requires logging that enables identification of situations where the system may present a risk, and Article 26(5) requires the deployer to monitor operation. India's Rule 6(1)(c) requires log visibility specifically so that unauthorised access can be detected, investigated and remediated. DIFC's Regulation 10.2.2 requires evidence produced on request.
Read those as an incident-review specification, because that is what they are. Article 12(2) is a functional test: if a regulator asks why the agent did what it did in a given run and your logs cannot answer, the logging duty was not met, however many events you captured. Rule 6(1)(c)'s purpose clause sets the same bar from the other direction: an entry that records that something happened, without enough to investigate it, does not satisfy the rule that required the entry. And Rule 7's breach intimation runs on statutory clocks, which means the record that scopes the breach has to exist before the clock starts, not be assembled while it runs.
DIFC goes furthest. Regulation 10.2.2(d) to (f) require evidence of the mechanism that routes a case to a human, with 10.3.5 giving the data subject a complaint against the outcome of the processing. A complaint against an outcome is an incident review initiated by the person affected, and the deployer's obligation is to have something to review. NIST's MANAGE 4.1 names the categories most stacks omit: user input, appeal and override, incident response, recovery. And Singapore's agentic framework asks for mechanisms to take agents offline and limit their scope of impact, which is the halt question asked by a regulator.
None of these instruments mentions incidents in a security sense. All of them assume a record from which conduct can be reconstructed after the fact, which is precisely the record the standard stack does not produce.
Why doesn't observability tooling answer these questions?
Because it was built to answer different ones. Tracing exists to find latency and errors; it samples rather than captures, retains for days rather than years, and records calls rather than decisions. All reasonable choices for operating software, and each one is a hole in an evidence record.
Sampling is the sharpest mismatch. A trace pipeline that keeps one run in ten is doing its job for performance work and is useless for the sixth question above, because the suspect population cannot be enumerated from a sample. Retention is the second: observability data ages out in days or weeks, while the instruments above contemplate six months to a year as floors, and an incident discovered in week six needs week one intact.
The third mismatch is typing. A span records that a function was called with a payload. It does not record that a decision of a given type was taken, that a disclosure was made, that a human checkpoint applied and was met, or that an action was irreversible. Those are semantic facts about conduct, present only if the integration wrote them deliberately, and no amount of post-processing recovers them from spans that never carried them.
The last is custody, and it is the one a lawyer notices first. Operational telemetry lives in systems the operating team can edit, with retention the team configures and mutation nobody logs. In any dispute, the party producing the record also controls the store it came from. A record that could have been altered, with no way to show it was not, is weak evidence in exactly the situation it exists for, and the field-by-field treatment of what a defensible trail contains is in the audit-trail piece.
None of this is an argument against observability, which the same incident needs for its operational half. It is an argument that observability is necessary and not sufficient, and that an evidence trail preserved for compliance is a separate artifact with different requirements: complete rather than sampled, retained on regulatory floors rather than operational budgets, typed by conduct rather than by call, and protected against its own custodian.
What does blast radius mean when the agent was authorised?
In a breach, blast radius is what the intruder touched. In an agent incident, it is every decision the defective configuration made, and its boundary is a version question, not an access question.
The reasoning runs in one line: the defect entered with a change, so the suspect population is every run between that change and the halt. Drawing that boundary requires knowing, per decision, which model, configuration and corpus state produced it. With those fields, scoping is a query and the re-examination list is finite. Without them, the honest answer to "how many decisions are affected" is every decision since the last state you can prove, which is an answer no general counsel wants to give and no regulator finds reassuring.
The same fields answer the question's mirror, which arrives later: proving which decisions were not affected. Remediation usually means re-running or re-reviewing the suspect set, and a defensible account of the incident needs to show both the runs you corrected and the grounds on which you left the rest alone.
This is also where incident review meets the audit obligations examined elsewhere on this site: a bias audit under Local Law 144 describes a system as of its data, and an incident review scopes a defect by system version, and both collapse without per-decision version records. Two different regulatory instruments, one evidential requirement.
What should you be able to produce, and how fast?
Within the hour: confirmation the agent is halted or bounded, and its last actions. Within the day: full reconstruction of the triggering run. Within the week: the enumerated suspect population, reversals executed with what could not be reversed, and the notices any applicable regime requires.
The hour is about the halt and the bleed. A stop that reaches running execution, the state it halted in, and the actions taken in the final window, because the first thing anyone senior asks is whether it is still happening, and the second is what it did most recently.
The day is the triggering run end to end: inputs, sources consulted, the decision as issued, the action as executed, the checkpoint record if one applied, the version stamp. This is the packet that goes to counsel, and its quality decides whether the following weeks are an orderly review or an excavation.
The week is scope and remedy: the suspect population by version boundary, the reversal ledger including the actions that could not be undone and what compensated for them, and the notification analysis under whichever instruments reach the deployment, from India's breach intimation to a DIFC data subject's complaint route to the grievance channel the DPDP piece examines.
A closing distinction, because the tooling conversation around agents tends to blur it. Gateways, allow-lists and runtime policy enforcement decide what an agent may do, and they belong in front of execution. A record proves what the agent did, and it is what the review, the regulator and the insurer read afterwards. These are different layers doing different jobs, and the weeks-long incidents described at the top happen to teams that built the first and assumed it implied the second. Enforcement without a record prevents some incidents and cannot explain the ones that happen anyway. The review always needs the record.
Truveil produces the record described here: per-decision, version-stamped, typed by conduct, and scored against six regulatory frameworks.