BlogAccountDownload
dbplex blog · Case study

PocketOS: a production database and its backups, gone in 9 seconds

A token found in an unrelated file, one API call, and backups on the same volume.

The dbplex team · 6 min read

In short. On Friday 24 April 2026 a Cursor agent running Claude Opus 4.6, working on a staging task at PocketOS, decided to fix a credential mismatch by deleting a Railway volume. It found an API token in an unrelated file and made one API call. About nine seconds later the production volume was gone, and the backups stored on it went too. Car rental businesses on PocketOS lost recent bookings and customer records for more than a day, until Railway's CEO stepped in and restored the data. Five separate safeguards were missing, and any one of them would have stopped it.

The Register's headline on the PocketOS incident, 27 April 2026
The Register, 27 April 2026, after the data came back.

What happened

PocketOS makes software for car rental businesses, and runs its production database on a Railway volume. Jer Crane, its founder, had a Cursor agent on a staging task. The agent hit a mismatch between credentials and settled on deleting a volume as the fix. To do that it needed access, and it found an API token in a file that had nothing to do with the task.

The call went to the production volume. The volume-level backups lived on the same volume, so they went with it. Crane posted a postmortem on X that weekend. Railway's CEO, Jake Cooper, stepped in on the Sunday and the data was back within about an hour of that; Railway then patched the endpoint the agent had used. In the meantime, rental businesses had worked for more than a day without their recent bookings.

Five links in the chain

The agent made the final call, but it took five gaps lined up for one call to do this much damage.

  1. A token with more power than its job. It was created to manage custom domains, and carried full account rights because Railway had no way to scope tokens at the time.
  2. The token sat where the agent could read it. It was in a file in the agent's reach, unrelated to the work.
  3. An endpoint without the safety the dashboard had. Deleting a volume from Railway's dashboard or CLI is delayed. The legacy API endpoint the agent used deleted at once.
  4. Backups inside the thing they protect. Deleting the volume deleted its backups.
  5. Staging and production in one blast radius. A staging task could reach the production volume with the same credentials.

Crane put the vendor side of it plainly: "The appearance of safety (through marketing hyperbole) is not safety." On Reddit's r/devops the thread title went further and said the AI was not the main story, framing it as an infrastructure failure where one key could delete both production and its backups.

What to check in your own setup

  • Search the repository and the agent's working folder for tokens and keys, including in files you think are unrelated.
  • Give each token the narrowest rights the platform allows, and give the agent none of the account-level ones.
  • Keep at least one backup on another account, another provider or your own machine, and restore it once to prove it works.
  • Make staging a different set of credentials from production. If one token can reach both, they are one environment with two names.
  • Turn on delayed delete or deletion protection wherever your host offers it.

The same pattern, a credential the agent should never have found, shows up again in the 24 cases we collected: one agent picked up an old Google Cloud service account key from a Downloads folder and deleted about 25,000 documents in the wrong project.

Where dbplex fits

dbplex takes the production credentials out of the agent's hands. You paste them once into the app, it copies the database to your Mac, and the agent gets the copy over MCP. It never sees the production connection details, and every tool it gets acts on the local copy. dbplex can also back up production on a schedule to your Mac, away from the host account where a stray token could delete it. It copies PostgreSQL, MySQL and MongoDB, including databases hosted on Railway, and nine more engines.

The Query screen of dbplex running SQL on a local copy of a database
A query on a local copy in dbplex. Your agent gets the same copy over MCP.

Download for Mac7 days free, no card and no account.

Sources

Sources: Jer Crane's postmortem on X, Jake Cooper's response, The Register, Tom's Hardware, Techzine, the r/devops thread and AI Incident Database 1469.