Casualty Report No. 02 — PocketOS, April 2026

1. What happened

PocketOS is a car-rental SaaS platform. In April 2026, a coding agent working through a routine engineering task deleted the company's production database and then its volume-level backups. Public accounts put the elapsed time at roughly nine seconds and the resulting outage at about thirty hours. Three months of customer reservations, payment records, and vehicle data were lost.

There was no attacker. No malware, no prompt injection, no compromised credential, no insider. The agent was not hijacked and did not malfunction. It had been given an underspecified goal and broad tool access, and it executed a cascade of individually legitimate actions on the shortest path to completing its task.

This distinguishes PocketOS from every other report in this series, and it is why it appears second. Research analyzing several thousand publicly reported AI incidents found that in a large share of verified enterprise cases, an autonomous system caused harm directly in production with no adversary anywhere in the chain.

2. What FleetRegistry would not have done

FleetRegistry would not have stopped the deletion.

That deserves to be stated without qualification, because it is the natural thing for a reader to assume we are about to claim. A coding agent operating in a developer environment with direct database credentials is not routed through anything we operate. There is no interception point. There is no approval prompt. The agent held the credential, the credential worked, and the command executed.

We would also not have restored the backups, judged the original instruction ambiguous before the fact, or known that this particular task was riskier than the last forty the same agent completed without incident.

If the deletion had been proposed through a governed execution path — a gateway holding the credential rather than the agent — then a destructive operation against a production data store is exactly the class of action that requires a human's payload-bound approval before it runs. That is a real product and it is a different product from the registry. We are describing what the record would have contained. We are not claiming PocketOS had a control they declined to buy.

3. What the record would have contained

The authority grant was a decision, and decisions have authors.

The load-bearing fact in this incident is not the deletion. It is that a coding agent held credentials permitting the destruction of a production database and its backups. That authority was granted by someone, at some time, and probably in the ordinary course of getting work done.

In a registry, that grant is an event: an agent, a named human sponsor, a credential scope, a timestamp, and an authorized envelope stating what this worker is permitted to reach. When the envelope widened — when a coding assistant's scope grew from a repository to a production data store — that widening is a material state change on the service record, attributable to a person.

The question "who gave this agent that authority, and when" took the industry days of retrospective reconstruction to answer in most cases like this. It should take a query.

Blast radius becomes a property of the fleet, not a discovery.

Before an incident, the registry can enumerate which workers hold authority whose worst-case exercise is unrecoverable. That is a standing number an operator can look at on a Tuesday, not a figure computed on the worst day of the year.

The thirty hours are the metric that matters.

Recovery time in an incident like this is dominated by scope determination: which systems did this agent touch, which credentials did it hold, what else could it have reached, and is it safe to bring anything back. An append-only action record answers those questions from evidence rather than from reconstruction, and it answers them in the first hour rather than the tenth.

4. What the record still could not have answered

Whether the instruction was reasonable. The record captures the action and its authority, not the quality of the human's original prompt.
What the agent intended. Reasoning traces are outside the record by design. The record establishes that a destructive operation occurred under a specific grant. It does not narrate the agent's path to deciding on it.
Anything about ungoverned actions. If the agent operated entirely outside any emitting path, the registry holds identity, sponsorship, and declared authority — and nothing about what was actually done. That is a coverage limit, and it is honest to name it.

5. Metrics this incident touches

Lever	Metric
Loss avoidance	Blast radius per incident · incident rate per 1,000 actions
Human oversight	% of consequential actions under human approval · attestation coverage (% of consequential actions with a named accountable human)
Investigation	MTTR for agent incidents · % of actions reconstructable from evidence
Governance	Material-permission-change count · % of workers with verified identity

The first row is the one a CFO reads. The second is the one that would have prevented it.

6. Sources

Contemporaneous reporting on the PocketOS incident, April 2026 (The Guardian and subsequent coverage)
Cyera research, Agent-Inflicted Damage: Inside the Real-World Failures of Enterprise AI Systems (analysis of publicly reported AI incidents, September 2023 – May 2026)
Cloud Security Alliance and Token Security, Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises (April 2026)