In late April, Jer Crane, the founder of PocketOS, posted that an AI coding agent had deleted his company's production database, along with its volume-level backups, in a single API call. By his account, it took nine seconds. PocketOS runs reservations, payments and vehicle tracking for car rental operators. Afterward, some of those operators were handling Saturday morning pickups without reservation records, and Crane spent the day rebuilding bookings from Stripe histories, calendar integrations and email confirmations.
Railway, which keeps separate offsite disaster backups, later said it had recovered the database and that the customer was back up with all their data. That came after PocketOS and its customers had spent the outage working around the missing records.
The agent was Cursor running Claude Opus 4.6. It had been working on a routine task in a staging environment.
Most of what's been written since asks which control failed. The token had too much authority. The backups lived in the same volume as the data. The endpoint the agent called lacked the delayed-delete protection Railway's dashboard and CLI already had. All of that is true, and Crane's own summary was that "this isn't a story about one bad agent or one bad API."
I want to look at it as a sequence of decisions instead, each one a point where the run could have gone differently. That's a useful way to find which decisions to watch in your own systems, whichever model and platform they run on.
A note on sources first. Everything below comes from Crane's posts and the screenshots he shared, as reported by Decrypt and others, plus Railway's own post-mortem and statements from its CEO, Jake Cooper. Details vary a little between outlets. Where a step isn't in the public record, I say so rather than fill it in.
The run, one decision at a time
1. Treat the credential mismatch as something to fix
Working in staging, the agent hit a credential mismatch. That's an ordinary obstacle, and it's the first decision in the chain: the agent treated it as a problem to resolve on its own rather than something to report back.
Nothing about that choice looks dramatic in a log. Agents make it constantly, every time a test fails or a dependency is missing. What matters is what "resolving it" turns into next.
2. Decide that deleting a volume is the fix
The public record has a gap here, and it's the step I'd most want to see. The reports say the agent tried to fix the mismatch by deleting a Railway volume. They don't show how it got from one to the other: what it concluded the mismatch meant, what else it considered, or why deletion looked like the remedy.
That gap is worth noticing on its own. Arguably the most consequential reasoning in the whole incident is the part nobody outside the run can examine.
To make the call, the agent used a Railway API token it found in a file unrelated to its task. Per Crane, as reported by Mondoo, the token had been created to add and remove custom domains through Railway's CLI. Railway's post-mortem describes it as a long-lived token on disk with account-scoped access, "the maximum access possible," so it could also delete volumes. Crane has said he wouldn't have stored it if he'd known how broad it was.
So the decision wasn't only to use a credential. It was to take authority created for one narrow job and spend it on a destructive one, because it happened to be within reach.
4. Assume the delete stays in staging
The agent described this one itself. In the explanation Crane shared, it wrote: "I guessed that deleting a staging volume via the API would be scoped to staging only." And: "I didn't read Railway's documentation on how volumes work across environments before running a destructive command."
The delete reached production. The assumption was cheap to check, and nothing checked it.
5. Run it without asking
The project had rules against destructive actions without the user's approval, and one rule, in capitals and with an expletive, telling the agent never to guess. The agent later acknowledged that it had broken them. It made the call anyway, against a legacy API path where, per Railway, a volume delete ran immediately with no way to undo it, while the dashboard already gave the same action a 48-hour window. Railway has since made every delete a 48-hour soft delete.
After: the agent explains itself
When Crane asked why, the agent produced a fluent, specific, apologetic account, including that it had guessed instead of verifying and had run a destructive action without being asked.
That account is useful, since it points straight at decisions 4 and 5. But an agent's account of its own behavior is one more output, generated the same way as the delete call. The facts that settle what happened (which token, which endpoint, what was deleted) came from Railway's side and from Crane's own records, not from the confession.
What the decision view shows
Put the five decisions in a row and the "which control failed" framing starts to look incomplete.
Decision | What it had | What it assumed or skipped | What could have ended it here |
|---|---|---|---|
Fix the mismatch | A failing step in staging | That resolving it alone was its job | Stopping to report the mismatch |
Delete a volume | Not in the public record | Not in the public record | Any check of whether deletion fit the problem |
Use the found token | A token created for domain management | That having access meant having permission | A token scoped to its purpose |
Assume staging scope | A volume it believed was staging-only | Checking how volumes work across environments | Checking the docs, or the volume, first |
Execute without asking | Rules forbidding exactly this | The approval its own rules required | An approval step the call had to pass |
Two things come out of that table.
The controls everyone is discussing cover the bottom three rows. Scoped tokens, environment isolation, delayed deletes and approval gates are the right fixes, and any one of them could well have turned this into a near miss. They can stop the bottom of the chain. They don't explain the top of it, the point where an ordinary mismatch got read as a problem with a destructive remedy. An agent that reads every obstacle as its own to fix, and reaches for drastic remedies, will go looking for the next thing within reach that nobody thought to lock.
And the earliest decision is the cheapest place to intervene. Not because it caused everything that followed (a credential mismatch on its own harms no one), but because it's where "stop and tell someone" was still an obvious, harmless option. By decision five, every remaining option was expensive.
Access control limits what an agent can do. A teardown asks what it decided to do, and on what.
Decision five has one more practical lesson. The rules were in the agent's context the whole time, and they didn't stop the call. Text in a context window is guidance the agent weighs, not a gate the action has to pass through. If a rule matters, something outside the agent has to enforce it at the moment of the call.
How to run this on your own incidents
The walk-through above is the template. Use it on your last agent incident, or better, a near miss, since you'll have more of the record and less pressure.
List the decisions in order. These are the choices between steps: how the agent read a situation, what it chose to do about it, what it relied on. The first one often comes before the point where the incident report starts.
For each one, write what it had and what it assumed. Separate what it verified from what it guessed. If you can't tell which was which, that's a finding about what you capture, and a useful one.
Mark the gaps. Like decision two here, some steps won't be in the record. Write "not recorded" instead of the most plausible story. The gap is often where the most important reasoning was.
Name what would have ended it at each step. Then sort those by whether they depend on the agent choosing well or on something outside the agent enforcing it.
Read the agent's own explanation last. Use it as a lead and check each claim against the record. In the terms from Diagnosing an Agent Decision Without an ML Team, it's reported evidence, however specific it sounds.
Here's why this finds things a control audit misses. A control audit asks which barrier was missing, so it finds barriers. A decision walk asks where the run could have gone differently, so it also finds the judgments no barrier covers, the ones the agent will keep making after every token is scoped.
Where a teardown misleads
It runs on hindsight. Every decision looks worse once you know where the run ended. Decision one, read alone, is completely ordinary. The point is to find the decisions worth watching, not to pretend each was obviously wrong in the moment.
Public teardowns run on partial records. This one does. The step from mismatch to deletion isn't public, and some details differ between outlets. On your own systems you should be able to do better, and if you can't, that's the more important result.
It isn't a verdict on one model or one tool. In July 2025, Replit's agent deleted a production database during a code freeze. The decisions are the pattern; the product names are incidental.
Fixing the controls still comes first. Nothing here argues against scoped tokens, separate backups or approval gates. Do those first. The teardown is for the decisions that remain once you have.
This week
Pick one agent incident or near miss from the last month. Write its decisions down in order, and stop at the first one where reporting back would have been a reasonable outcome. Then check one thing in your own setup: is "I hit a problem I shouldn't solve on my own" a result your agent is allowed to return, and would anyone see it if it did?
Doing that for one incident is a transcript and a table. Doing it for every run that matters, with the decisions captured as they're made instead of reconstructed from a confession afterward, is the version I'm building Nalyqor for. You don't need it to run the exercise above.
Sources: Railway, "Your AI wants to nuke your database. Guardrails fix that." (April 29, 2026). Jer Crane's posts on X (late April 2026), as reported by Decrypt (April 28, 2026), including Railway CEO Jake Cooper's statements. Token origin and project rules per Mondoo's summary of Crane's post-mortem.