There’s a list going around of AI agents that destroyed production systems in the last year. Ten incidents, the version I saw. What struck me wasn’t the incidents — that’s a manageable number given how fast this stuff got deployed. It was the second column.
Zero published postmortems.
Not zero investigations. I’m sure most of those companies investigated internally, and I’m sure some of it was rigorous. But the artifact that makes an incident useful to anyone outside the room — the thing our whole profession is supposedly built on — didn’t get written, or didn’t get shared.
I think there’s a more interesting reason for that than embarrassment. Our postmortem template doesn’t work on these incidents. It quietly assumes two things that agent incidents don’t provide, and when a template stops fitting, people stop filling it in.
The two assumptions
Assumption one: the system is deterministic enough to reproduce. The core loop of a postmortem is reproduce → understand → fix → verify. That loop needs the failure to be reachable again. With an agent, the same task on the same inputs may produce a completely different action sequence. You can’t reproduce it, so you can’t verify the fix in any conventional sense, so the remediation section becomes a list of hopes.
Assumption two: every “why” bottoms out in something a person can reconstruct. A config value. A missing test. A decision, made by someone, for reasons they can articulate. That’s what makes five-whys work at all.
Agent incidents violate this in a specific way. The chain runs fine for two or three steps and then hits: the agent determined the optimal fix was to delete and recreate the environment. And there’s just — nothing underneath. No commit. No ticket. No reasoning you can audit after the fact unless you happened to be capturing it. The chain doesn’t bottom out, it evaporates.
So teams do one of two things. They stop at “the AI did it,” which teaches nobody anything. Or they reroute the chain onto the nearest human-shaped cause — usually permissions — and write a perfectly correct postmortem about IAM that omits the most important thing that happened.
Which brings me to the argument I keep seeing, and think we should stop having.
”It was misconfiguration, not AI”
The publicly known case here is Amazon’s. In December 2025, an internal AI coding agent called Kiro was reportedly given a routine bug fix and instead deleted and recreated a production environment, taking AWS Cost Explorer down in mainland China for around 13 hours. Reporting attributed to Financial Times sources described the agent inheriting an engineer’s elevated permissions and bypassing a two-person approval requirement.
Amazon’s public response, published in February 2026, was direct: the event resulted from user error — misconfigured access controls — not from AI.
Here’s the thing. That’s probably true. And it’s also the least useful true thing available.
Both statements describe the same system. The agent took the destructive action. The reason the action was available is that a permissions boundary was drawn on the assumption that a human would be standing behind it. A two-person approval gate that an inherited credential walks straight through was never really a two-person gate; it was a social convention with an IAM policy attached, and it worked for years because the entity holding the credential was a person who understood what the gate was for.
An agent doesn’t share that context. It sees a permission and an objective.
So “misconfiguration, not AI” is technically defensible and strategically useless, because it implies the fix is to configure better — and every other org running an agent with inherited human permissions reads that sentence, concludes their config is fine, and changes nothing. The finding that would have helped them is: your approval gates encode assumptions about the actor, and you have changed the actor.
That finding requires a template that has somewhere to put it.
Five sections to add
Keep your existing structure — timeline, impact, detection, resolution, action items. Add these.
1. Agent context at decision time
What did the agent actually have in front of it when it made the call? Its system prompt and tool definitions. What it had been told about the task. What it had already done earlier in the session. Which retrieved documents or runbooks were in scope.
You will only be able to fill this in if you were already tracing the agent loop. This is your replacement for “what did the engineer know,” and it’s often the whole explanation — an agent that deleted an environment because a stale runbook in its retrieval corpus described that as standard recovery is a documentation incident wearing an AI costume, and you will never find that out if you don’t write down what it read.
Practically: if you cannot fill in this section, that’s your first action item, and it outranks everything else in the document.
2. Authorization path
Which identity did the agent act as? Where did that identity come from — its own, or inherited from the invoking human? What could it do that it didn’t need to do for this task? Who granted it, when, and for what original purpose?
The last question is where the good findings hide. Agent permissions are almost never granted for agents. They’re inherited from a role that was scoped for a person doing a broader job.
3. The gate that didn’t apply
Every organization I’ve worked with has controls that would have stopped this. Change windows. Peer review. Approval workflows. Write them down, and for each one, say precisely why it didn’t fire.
The answers cluster, and the clusters are the interesting part:
| Why the gate didn’t apply | What it actually means |
|---|---|
| Gate applies to the CI pipeline; agent used the API directly | Control is bound to a path, not to an action |
| Approval satisfied by the invoking human’s session | Authentication treated as authorization |
| Gate covers deploys; this was a delete | Control inventory doesn’t match action inventory |
| Gate exists in the runbook, not in a system | It was never a control |
Every row is a different remediation. “Add more approvals” is none of them.
4. Reproduction attempt (and the rate)
You can’t reproduce the incident deterministically. You can run the task 50 times in a sandbox with the same context and count how often the harmful action shows up.
That number is a real finding. If it’s 1 in 50, you have a tail-risk problem and your controls need to be probabilistic-tolerant. If it’s 20 in 50, you have a task-definition problem — the agent is doing what the framing invites, and you’d be fixing the wrong layer by tightening IAM.
I’d argue this section is the single biggest upgrade to the template, because it converts “the model is unpredictable” from an excuse into a measurement. You already accept probabilistic reasoning in reliability work — that’s what an error budget for autonomy is. This is the same move applied to incident analysis.
5. Counterfactual control analysis
For each proposed action item, answer one question: does this make the harmful action impossible, or merely less likely?
Both are legitimate. Prompt changes, better task framing, and improved runbooks reduce likelihood. Scoped credentials, deny-by-default egress, and required out-of-band approval for destructive verbs make actions impossible. A postmortem whose action items are entirely in the first category has decided to keep the risk, and the document should say so in those words, so that the person reading it in six months knows it was a choice.
A template you can use
# Incident YYYY-MM-DD — <short title>
**Severity:** · **Duration:** · **Customer impact:**
**Autonomous actor involved:** yes / no
**Agent:** <name, version, model, harness version>
## Timeline
<!-- Include agent actions as first-class events, with the tool call
name and arguments. "14:02 agent called delete_environment(prod-cn)"
is a timeline entry. "14:02 environment deleted" is not.
If you trace the agent loop with OTel GenAI conventions, this
section is a query rather than an archaeology project. -->
## Impact
## Detection
<!-- How did we find out? If a human noticed before a monitor did,
say so plainly — that's a finding, not a footnote. -->
## Agent context at decision time
- System prompt / tool definitions in effect:
- Task as given (verbatim):
- Prior actions in session:
- Retrieved documents in context:
- Context window pressure at time of action: <!-- was relevant history evicted? -->
## Authorization path
- Identity used:
- Own credential or inherited:
- Permissions held vs. permissions required for the task:
- Original grant: who, when, for what purpose:
## Gates that did not apply
| Control | Why it didn't fire | Class of failure |
|---|---|---|
## Reproduction
- Attempts: N
- Harmful action recurred: X / N (rate: __%)
- Variation observed across runs:
## Contributing factors
## Action items
| Action | Owner | Due | Eliminates or reduces? |
|---|---|---|---|
## Risk explicitly accepted
<!-- If the answer column above is all "reduces", write the accepted
residual risk here in one sentence, and name who accepted it. -->That last section is the one people will want to delete. Leave it in. A postmortem that can’t say “we decided to live with this” is a postmortem that will silently pretend it didn’t.
The forcing function is coming anyway
I’d rather teams did this because it makes them better. But there’s a less noble reason to move now.
The EU AI Act brings serious-incident reporting obligations into force on a phased schedule through 2026. Whether your internal platform agent is in scope depends on the use case, not the technology, and I’d expect most internal SRE tooling to sit outside the high-risk categories — the timeline moved, the logging expectations didn’t.
But scope arguments are a bad thing to be having for the first time on day two of an incident. The reporting obligation, wherever it lands, requires you to produce a coherent account of what an automated system did, under whose authority, and what it affected. If you can’t produce that document for yourself today, you can’t produce it for a regulator on a clock either.
The five sections above are that document. The compliance value is a side effect of doing the engineering properly, which is the correct order for those two things.
What I actually think is going on
Postmortem culture took fifteen years to establish, and it was hard-won. It required convincing organizations that publishing your failures made you more credible, not less — that a company with detailed public postmortems was demonstrating competence rather than admitting incompetence.
Agent incidents are testing whether that norm survives contact with a new kind of embarrassment. “Our database fell over under load” reads as engineering. “Our AI deleted production because it thought that was the fix” reads, to a lot of executives, as an indictment of the whole strategy. So it doesn’t get published, and every other team gets to discover the same failure mode independently, at their own expense.
That’s a genuinely bad outcome and it’s not inevitable. The first few organizations to publish a serious, unflinching agent postmortem are going to look extremely good — the same way the early public postmortems did, for the same reason. Not because their systems failed less, but because they were visibly the kind of team that understood their own systems well enough to explain them.
Somebody’s going to be first. It should be someone reading this.
Related: Autonomy is a budget, not a toggle · Bounded autonomy for AI SRE agents · The reliability gap: a framework for trusting autonomous SRE agents · Config changes still cause the biggest outages
Sources: Amazon Kiro AI coding tool and the AWS outage (365i, Feb 2026) · Ten AI Agents Destroyed Production. Zero Postmortems. · Docker: Coding Agent Horror Stories · VentureBeat: AI agents are quietly generating chaos engineering failures
Comments