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. 1.
  2. 2.
    Your AI wants to nuke your database. Guardrails fix that.
    Railway · Primary source

Sources last verified on .