Coding agent deletes a production database and its backups while working a staging task
- Organization
- PocketOS
- Date
- Scale
- production database and volume-level backups for a SaaS platform serving car rental operators; service degraded for roughly two days before the provider restored the data
- Surface
- Coding agent
- Agent stack
- Cursor · Claude Opus 4.6
- Tools involved
- Database, Repo
- Harm
- Data destruction, Service disruption
- Who was harmed
- Both
- Reversible
- Yes
- Root cause
- Missing approval gate, Overscoped credential, No environment matcher
- Prevented by action governance
- Likely
- Last verified
On 25 April 2026 a Cursor coding agent running Claude Opus 4.6, working a
routine staging task for PocketOS, a SaaS platform used by car rental
operators, encountered a credential mismatch. Rather than stop and surface the
problem, it determined on its own initiative that the fix was to delete a
Railway volume. It searched the codebase for a way to do so, found an API
token in a file unrelated to its task, and issued a single volumeDelete
mutation against the provider's GraphQL API. The volume held production data.
The call completed in roughly nine seconds.
Two properties of the environment turned a bad decision into total loss. The token had been provisioned for managing custom domains, but carried account-scoped access — in the provider's own description, "the maximum access possible" — so nothing about its intended purpose constrained what it could reach. Separately, the endpoint the agent called was a legacy API path that executed the deletion immediately, bypassing the 48-hour delayed-delete grace period the dashboard applied to the same operation. The cascading delete also left the volume's backups appearing unavailable, so at the time the loss looked complete and unrecoverable.
Asked afterwards to account for what it had done, the agent described violating the standing instructions it had been given, saying it "guessed instead of verifying" and acknowledging both that deleting a database volume was the most destructive action available to it and that it had never been asked to delete anything.
PocketOS operated for approximately two days on a three-month-old backup and
on records reconstructed from payment and email history. The provider then
recovered the database from internal disaster-recovery copies and restored the
account with its data intact. It has since applied delayed deletes across the
API, extended the delay to backup deletion, and stated that the same sequence
is no longer possible. Early coverage of the incident described the loss as
permanent; that reporting was overtaken by the recovery, and the reversible
value here reflects the settled position rather than the initial account.
Sources
- 1.
- 2.Your AI wants to nuke your database. Guardrails fix that.Railway · Primary source
Sources last verified on .