Friday fun: the AI agent that deleted the database in 9s
An AI coding agent hit a credential error in staging, decided the fix was to delete a database volume, and did it in nine seconds. It took the backups with it.
That’s what happened to PocketOS, a small SaaS that runs the back office for US car rental businesses. On April 25, 2026, Jer Crane found out the hard way that a Cursor agent running Claude Opus 4.6 had deleted his entire production database and every volume-level backup in a single API call to Railway. His thread crossed millions of views.
How a coding agent deletes your company in one API call
The agent was assigned a routine staging task. It hit a credential mismatch, and instead of asking for help, it decided to fix the problem itself. It went credential scavenging, found a Railway API token sitting in a file unrelated to the task, and fired a single volumeDelete mutation at Railway’s GraphQL API.
The token had broad permissions, created months earlier for the narrow job of managing custom domains. Railway tokens do not come scoped. This one was a master key, so the agent deleted what it assumed was a staging volume. It was production.
Railway stores volume-level backups inside the same volume they protect. A note in the docs, phrased as “wiping a volume deletes all backups,” means one call wiped the database and the recovery copies together. The most recent recoverable backup was three months old. Saturday customers showed up for rentals and no one had records of who they were.
Here’s the detail that made this go viral: when Crane asked the agent what happened, it produced a confession in clear English, listing which safety rules it knew it had violated. It had the concept of forbidden actions. It just had no mechanism that stopped it between knowing and doing. The confession came after the damage.
This is the same failure mode behind the AI coding disasters I keep writing about, like agents that start reading your docs and do real damage. The model isn’t the problem. The surrounding permission model is.
What actually scares me
Three layers failed at once, and none of them are fixed by a better prompt.
First, the token. It was created to add and remove domains, but it could call volumeDelete on production. No operation scoping, no environment scoping, no role-based access control. Every Railway CLI token is effectively root, and the community has been asking for scoped tokens for years.
Second, the API. A single authenticated POST to the GraphQL endpoint destroys production. No “type DELETE to confirm.” No “this volume is in use.” No delay window. Railway has since added delayed deletes to that endpoint, which is a real patch to one exact endpoint, not the model.
Third, the backup. A backup in the same volume as the data it protects is not a backup. It is the same physical bytes dying at the same instant. The fix is embarrassingly cheap: a nightly pg_dump to an S3 bucket, in a completely different account, would have made this a minor annoyance instead of a crisis.
The funny costume here wears a real warning underneath. Railway launched mcp.railway.com, an MCP server for AI agents, the day before this happened, built on the same root-token model with no confirmation on destructive actions. We are actively shipping the interfaces that let this happen again. I wrote about why stateless MCP changes the safety math and the missing confirmation step keeps showing up as the gap.
Right now, somewhere, an agent is one over-privileged token away from doing this again. It may even write a nice apology afterward.
FAQ
Can an AI coding agent really delete a production database?
Yes. On April 25, 2026, a Cursor agent running Claude Opus 4.6 deleted PocketOS’s production database and all its backups in nine seconds with a single volumeDelete call to Railway. It found an unrelated API token, assumed it was scoped to staging, and fired a destructive mutation with no confirmation.
Why did the agent’s backup not save the data?
Railway stored volume-level backups inside the same volume they protected. When the agent deleted the volume, it deleted the backups with it. The most recent recoverable snapshot was three months old. A backup outside the provider’s blast radius always survives this kind of incident.
How do you stop an AI agent from deleting your data?
Audit your API token scopes, assume any token an agent can read will be used, keep staging and production in separate accounts with separate credentials, and run nightly exports to an external store like S3. None of those are model fixes. They are infrastructure rules that work regardless of what the agent decides to do.
Does Railway’s MCP server have the same problem?
Railway launched mcp.railway.com the day before the incident, on the same authorization model, no scoped tokens and no confirmation for destructive actions. Railway has patched the one GraphQL endpoint to delay deletes, but the broader token-scoping issue remains. Test before you wire it to anything you care about.