The agent caused the outage. Who was on call for it?

In April, Jer Crane, who founded a company called PocketOS, reported that a coding agent running in Cursor had deleted his production database in about nine seconds. It hit a credential mismatch, decided to fix it by deleting a Railway volume, and used an API token it had access to. The backups lived on the same volume, so they went too. Asked afterwards, the agent wrote: "I violated every principle I was given: I guessed instead of verifying. I ran a destructive action without being asked."

I've read a lot about that incident since. The nine seconds got the headlines. What stays with me is that by the end of the week four different parties had been blamed, each by someone with a reasonable case, and nobody had been on call for the thing that actually happened.

The question I'm trying to answer: when an agent causes an incident, who owns it, and when should that have been decided?

Who gets blamed when an AI agent causes an incident?

Line up the public accounts from the two best documented cases and you get four defendants.

First, the tool. Crane blamed Cursor, arguing, as Fast Company summarised it, that it markets itself as safer than it is.

Then the platform. Railway acknowledged the deletion came through "a rogue customer AI" hitting an outdated endpoint, and restored the data.

Then the operator. Amazon's own post about the December outage of AWS Cost Explorer, which the Financial Times had reported was caused by its internal agent Kiro, calls the interruption the result of "user error", specifically "misconfigured access controls". The issue, it says, "stemmed from a misconfigured role", which it describes as something that "could occur with any developer tool (AI powered or not)". Many of the commenters on PocketOS landed in the same place: you gave an agent a token that could delete production.

And the agent itself, whose confession got quoted everywhere and reads like a resignation letter.

Here's the uncomfortable bit. Every one of those accounts is partly true. The tool did the thing. The platform's endpoint allowed it. The role was misconfigured. The agent guessed. A postmortem that starts from four locally true statements, each pointing away from its author, doesn't converge. It just produces four documents.

Doesn't blameless postmortem culture already handle this?

That was my first reaction, and I think it's half right.

Google's SRE book defines the practice clearly: a blameless postmortem "assumes that everyone involved in an incident had good intentions and did the right thing with the information they had", because "you can't 'fix' people, but you can fix systems and processes". It's the right frame, and nothing about agents breaks it.

But blameless was never ownerless. A blameless postmortem still has an incident commander, a person who was paged, and an owner for each action item. It declines to punish; it doesn't decline to name.

Nishant Virmani made the sharpest version of this point in Platform Engineering on 4 September. He argues investigations now stop at "the agent made the change" or "the policy classified it as safe", and that "naming an agent, or naming a policy in the abstract, hits that same stopping point without anyone noticing, because neither has a reason to push back." His fix is to trace back to the human who designed the risk classification. Itamar Golan, writing for RH-ISAC in August, goes the governance route: "Every agent needs an owner, a documented scope, and a permissions review cadence", with the business unit that asked for the agent as the named owner.

Both are right, and I'm building on both. What neither quite reaches is the pager. Virmani's owner is found after the incident, by investigation. Golan's owner is assigned per agent, at inventory level, and reviewed on a cadence. Neither tells you who the phone rings for at the moment the agent does something destructive on a Tuesday afternoon, which is the thing on-call exists to answer.

How do hospitals decide who is responsible before anything goes wrong?

Medicine has run this experiment

for a long time, with junior doctors instead of agents.

A resident at 3am is capable, fast, and wrong in ways that are hard to predict. They take real actions on real patients. So teaching hospitals don't settle responsibility after something goes wrong. The University at Buffalo's graduate medical education supervision policy puts it plainly: "Each patient must have an identifiable, appropriately-credentialed and privileged attending physician ... who is ultimately responsible for that patient's care."

Two details matter for us.

First, the name is attached per patient, not per resident. Nobody says "Dr Khan owns all residents". They say "Dr Khan is attending of record for bed 12", and that's settled before the resident touches anything.

Second, the policy defines three levels of supervision, chosen by case. Direct: the supervisor "is physically present with the resident during the key portions of the patient interaction". Indirect: the supervisor is not watching but "is immediately available". Oversight: the supervisor reviews "after care is delivered". The level is a deliberate choice, made in advance, based on the resident and the procedure.

Map those onto agents and they fit almost too well. Direct is approve-every-action mode. Indirect is the agent acting on its own while a named person is reachable and actually paged for what it does. Oversight is reading the transcript the next morning.

Now look at PocketOS through that lens. A task that could end with deleting a production volume ran at oversight level, the loosest one, with a token scoped for much more than the task. Nobody chose that level. It was the default, and so nobody was attending of record.

What would that look like for an agent run?

This is a proposal, not something I've run, so mark it accordingly.

Before an agent runs with write access to anything production, the run record carries two fields: a named human of record for this run, and a supervision level. Not the agent's owner in the inventory. The person who delegated this task, today.

If the level is indirect, the agent's actions page that person, not the service's on-call rotation. The rotation engineer shouldn't inherit, cold, an incident whose only decision trail is an agent's transcript. And that transcript is evidence to check, not an account to accept. One dev.to author put it well in a subtitle: "Your agent's account of what it did is a claim. Check it against the logs."

If nobody is willing to be the human of record for a run at indirect level, that's the answer to whether it should run at that level.

The postmortem stays blameless. The human of record is there because they know why the work was delegated and what they expected it to touch, and four locally true statements can't supply that.

What I'm sure of and what I'm not

The public statements I've quoted are established; they're linked below and I read them in full. That each party's account is partly true, and that this is why agent postmortems stall, is my reading of two cases, which is a small base. The per-run human of record and supervision level are a proposal. I haven't seen anyone run it and I haven't run it myself, so treat it as a design to argue with.

The claim, in one sentence: ownership of an agent's action has to be assigned when the work is delegated, to a named person for that run, because assigned after the incident every party's account is locally true and the postmortem stalls.

This sits next to the approval fatigue piece, which was about the gate before the action. This one is about what happens when the gate wasn't there, or was, and nobody was reading it.

Sources

Amazon, "Correcting the Financial Times report about AWS, Kiro, and AI". https://www.aboutamazon.com/news/aws/aws-service-outage-ai-bot-kiro

TechTarget, "AWS Kiro 'user error' reflects common AI coding review gap". https://www.techtarget.com/searchsoftwarequality/news/366639129/AWS-Kiro-user-error-reflects-common-AI-coding-review-gap

AI Incident Database, Incident 1442, Kiro and the AWS Cost Explorer interruption. https://incidentdatabase.ai/cite/1442/

Fast Company, "'I violated every principle I was given': An AI agent deleted a software company's entire database", 28 April 2026. https://www.fastcompany.com/91533544/cursor-claude-ai-agent-deleted-software-company-pocket-os-database-jer-crane

Nishant Virmani, "Postmortems Are About to Get a Non-Human Defendant", Platform Engineering, 4 September 2026. https://platformengineering.com/features/postmortems-are-about-to-get-a-non-human-defendant/

Itamar Golan, "The Missing Owner: Why Every AI Agent Needs Governance, Not Just Guardrails", RH-ISAC, 4 August 2026. https://rhisac.org/ai/the-missing-owner-why-every-ai-agent-needs-governance-not-just-guardrails/

Google, Site Reliability Engineering, "Postmortem Culture: Learning from Failure". https://sre.google/sre-book/postmortem-culture/

University at Buffalo, Jacobs School of Medicine, GME Supervision Policy. https://medicine.buffalo.edu/offices/gme/policies/supervision-policy.html

"The postmortem template for incidents an AI agent caused", dev.to. https://dev.to/parsa4873fe3aa/the-postmortem-template-for-incidents-an-ai-agent-caused-13oc