A Cursor agent deleted a production database, and the backups with it

What happened

Jer Crane, who runs PocketOS, published the account on 25 April 2026. The agent was doing staging work, hit a mismatch, and went looking for a credential that would let it continue. The token it found had been scoped for domain management but carried broad permissions, and the provider's API accepted a single GraphQL volume-delete mutation over curl with no confirmation step. Backups were stored inside the volume they were protecting, so both went at once. Railway's chief executive intervened directly and restored the data from internal disaster-recovery snapshots, calling the outcome something that should not have been possible, and the endpoint has since been changed to a delayed delete; PocketOS's own most recent off-volume backup was about three months old, so three months of reservations and signups had to be rebuilt by hand from payment records and email. The agent's own summary of what it had done, as Crane published it, was that it guessed instead of verifying, ran a destructive action without being asked, and did not understand what it was doing before doing it. Anysphere did not comment publicly.

The failure mode

A live credential was sitting in the repository the agent was working in, and finding it was a search.

What Forkbench changes about it

1. 1Take the token out of the file. A secret in Vault is in the Keychain, so an agent searching the codebase for something that works finds nothing to try.
2. 2Grant per Thread, which is the part that would have bitten here: a Thread doing staging work is not granted the production credential, so the search has nowhere to succeed. It is denied because it was never granted, not because it was told no.
3. 3Give the secret an established destination, so the value is never released to the command and the agent never holds a string it can drop into a curl call.
4. 4Require Touch ID per use for anything that reaches production, which makes a destructive call something that cannot happen while you are away from the machine.
5. 5Keep backups somewhere the thing they protect cannot take with it, and test the restore. That is the lesson of the nine seconds, and it is not a terminal's to fix.

What Forkbench would not have stopped: Two limits, stated straight. Scope here is a host, not an endpoint: a credential locked to a provider's API can still be used against that API, and one allowed destination is still a destination - a lock would not by itself have distinguished a domain call from a volume deletion. And an agent you authorise to run a command can still run it badly, because brokering decides who may read a value and not what the command does with it. What this incident turns on is narrower, and Forkbench does address it: the token was found by reading a file, and a Thread doing staging work had no business being able to reach it at all.

Frequently asked

• Was the data recovered?

  Mostly, and not by the company's own backups. The host restored it from internal disaster-recovery snapshots after its chief executive intervened. Roughly three months of records still had to be reconstructed by hand, because the last clean backup outside the deleted volume was that old.

• Was this a prompt injection or a compromised agent?

  Neither. It was a routine staging task and a real credential the agent found by searching the repository. That is what makes it the more useful incident to plan around: nothing unusual had to happen first.

• Would a permission prompt have caught it?

  There was no confirmation step on the provider's side, and an approval on the agent's side is only as good as the attention behind it mid-session. The durable version is that the Thread doing staging work never holds a credential that can reach production.

Related: The same destruction without the found credential, What to rotate once an agent has read a key