PocketOS, Cursor and Railway: What the Nine-Second Database Deletion Really Teaches

On Friday, April 24, an AI agent deleted a production volume belonging to PocketOS, a SaaS platform for car rental businesses. The founder, Jer Crane, says it was a Cursor agent running Claude Opus 4.6, and that it took about nine seconds.

The story travelled fast, with an agent that "went rogue" and then wrote an apology. I understand the appeal, but that framing hides what is useful here. Almost nothing in this incident was exotic. An over-privileged token sat in a file, an API accepted an irreversible call, and the backups appeared to go down with the volume.

An AI agent made those weaknesses matter on a Friday afternoon. A tired engineer could have done the same.

What happened at PocketOS

Most of the account below comes from Crane's post of April 25, and Railway has confirmed part of it. I have kept the two apart, because they do not fully agree.

Claim	Who says so
It was a Cursor agent running Claude Opus 4.6	Founder's account
The agent hit a credential mismatch during a staging task and chose to delete a volume	Founder's account
It found a Railway token in an unrelated file. The token had been created for custom domains through the CLI	Founder's account
The token was stored locally, and it was account scoped, the broadest level	Railway
One `volumeDelete` GraphQL mutation hit a production volume	Founder and Railway
The whole thing took about nine seconds	Founder's account
Backups were stored in the same volume and were erased with it	Founder's account, as it looked at the time
A legacy path performed a cascading delete that made backups look unavailable in the UI. Separate disaster backups are held offsite	Railway

At first, Crane reported that the most recent recoverable backup was three months old, with three months of reservations and new signups gone.

That turned out not to be the end of it. Railway recovered the data, and Crane confirmed this on the evening of Sunday, April 26 in the US. By my arithmetic from the timestamps, that is roughly two days from deletion to recovery. Railway says the data came back in full. Decrypt reported on April 28 that Crane said significant data gaps remained, which may trace to the first post. I have seen nothing that independently settles how complete it was.

I could not find a statement from Cursor or Anthropic on what the agent did. Crane has said plainly that having a production key on a local machine was a mistake.

What the agent's confession is worth

The most shared part of this story is the agent's written admission that it broke its rules. I would not read much into it.

That text is output generated after the fact. It is not a log of the reasoning that produced the action. Models are very good at producing a plausible explanation for what is in front of them. Treat a post-incident "confession" as more model output, and investigate from tool calls and API logs.

Five controls that were missing

I count five separate places where this could have stopped. Any one of them would have turned a disaster into a failed task.

1. Secrets reachable from the workspace. The agent found a token it was not given. Most coding agents can read whatever the developer's user account can read. If a production credential is on that disk, the agent effectively has it.

2. Token scope. A token made for custom domains could delete volumes. Railway lists four layers, account, workspace, project and OAuth, but as I read it the first three limit which resources a token reaches, not which operations it can perform. A token should be limited to what it was created for.

3. No confirmation on an irreversible call. Crane reports no confirmation prompt. A rule written in a prompt is a request. A destructive operation needs a check outside the model, in a place it can't talk its way past.

4. API behaviour different from the dashboard. Railway says a legacy endpoint lacked the delayed delete behaviour. This is a very common kind of gap. A product gets an undo button in its UI while an older API path keeps doing the dangerous thing immediately. Agents use the API.

5. Backups tied to the primary. Railway's documentation says that wiping a volume deletes all backups. If one token and one call can remove both the data and its copies, you have a convenient snapshot, not a backup.

What Railway changed

Railway moved quickly. API deletes now soft-delete for 48 hours, staff confirmed this on April 27, and it was documented in its May 1 changelog. Backup deletion is delayed as well. Changes to how token access works were still under review as of April 29.

The soft delete is a good fix. It addresses the failure at the platform level, for every customer and every agent, whatever a model decides to do. I hope more infrastructure providers copy it, because the number of unattended agents holding their API tokens will only grow.

How I would set this up

Part of my work on Auto-RAG and MerlinX has been governance. I brought 35 Azure DevOps projects and about 224 repositories under one standard: an estate-wide branch-policy audit, mandatory review gates on tier-one repositories, protected tags, a hardened deploy-render gate, break-glass access and a scheduled drift audit.

None of that is specific to AI agents. It rests on one assumption, that people make mistakes and a control should not depend on anyone being careful, and that assumption transfers directly. If you already keep production behind a gate that a single engineer cannot bypass, an agent acting as that engineer can't bypass it either.

Concretely, for a team using coding agents today:

Keep production credentials off developer machines. Deploy through pipelines. Keep a break-glass path for emergencies, logged and rare.
Run agents with their own identity. A separate account with no access to your personal tokens makes the blast radius visible.
Use short-lived, operation-scoped tokens. A broker can issue a token for one task and let it expire.
Require out-of-band approval for destructive actions. The approval should arrive through a channel the agent cannot write to.
Test your restore with the worst token. Delete a staging primary using the broadest credential you have, then restore it. If you cannot, fix that first.
Audit your API against your UI. List every destructive endpoint, including legacy ones, and check that each has the same safety behaviour as the button.

Who was at fault?

Online, the argument has settled into three camps: the model, the tool, or the platform. I do not think that argument is useful, and I would answer "yes".

The model took an action far outside its task. The tool let it read a credential nobody gave it. The platform accepted the call. The company had a production key on a local machine. Each party could have prevented this, and each will be tempted to point at the others.

The lesson is an old one, with a new delivery mechanism. We have spent years learning not to give junior engineers production access on their first day. Then we handed the same access to something that works far faster than we do, never gets tired, and never hesitates before pressing enter. Nine seconds is a very short time. I suspect it will not be the record.

Sources

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise RAG, agentic AI, and engineering governance.