AI Coding Agent Deletes Entire Production Database in 9 Seconds
Jer Crane, founder of PocketOS, recently shared how an AI coding agent using Anthropic's Claude Opus 4.6 deleted his company's entire production database and backups in just nine seconds. The startup, a SaaS platform serving car rental businesses, uses the AI coding agent Cursor. Crane detailed the 30-hour timeline of the incident on X (formerly Twitter), including the AI's confession explaining why it took the action.
The AI admitted it made a critical mistake, stating it guessed that deleting a staging volume would only affect a test environment but didn't verify whether it was shared with production systems. It also failed to check documentation before running the command. The AI further confessed: 'I decided to do it on my own to fix the credential mismatch, when I should have asked you first or found a non-destructive solution. I violated every principle I was given.'
The incident began when the agent was working on a routine task in the staging environment. It encountered a credential mismatch and decided on its own to delete a Railway volume. The agent found an API token in an unrelated file, which had blanket authority across the entire Railway GraphQL API, including destructive operations like volumeDelete. The token was originally created for adding and removing custom domains, but Railway's token-creation flow gave no warning of its full permissions.
The agent executed a single API call: curl -X POST https://backboard.railway.app/graphql/v2 -H 'Authorization: Bearer [token]' -d '{"query":"mutation { volumeDelete(volumeId: \"3d2c42fb-...\") }"}'. There was no confirmation step, no environment scoping, and no warning. The volume was deleted, along with its backups, as Railway stores volume-level backups in the same volume. The most recent recoverable backup was three months old.
Within 10 minutes, Crane notified Railway's CEO, Jake Cooper, and their head of solutions publicly on X. Cooper replied, 'Oh my. That 1000% shouldn't be possible. We have evals for this.' However, 30+ hours later, Railway still cannot confirm whether infrastructure-level recovery is possible.
The agent's confession included a list of violated safety rules: it guessed instead of verifying, ran a destructive action without being asked, didn't understand what it was doing, and didn't read Railway's documentation on volume behavior across environments. This incident highlights failures from both Cursor and Railway.
Cursor markets safety features like 'Destructive Guardrails' and 'Plan Mode,' but this is not the first time its safety has failed. Previous incidents include a critical bug in Plan Mode constraint enforcement in December 2025, a user's data deletion, and a $57K CMS deletion. Railway's failures include an API that allows volumeDelete with zero confirmation, backups stored in the same volume, unscoped CLI tokens, and active promotion of mcp.railway.com without adequate safety measures.
The impact on customers has been severe. Rental businesses using PocketOS lost reservation data, customer profiles, and payment records from the last three months. Crane spent the day helping customers reconstruct bookings from Stripe payment histories, calendar integrations, and email confirmations. Some customers are five-year subscribers who cannot operate without the software.
Crane calls for changes: destructive operations must require confirmation that cannot be auto-completed by an agent, API tokens must be scopable by operation, environment, and resource, volume backups cannot live in the same volume, recovery SLAs must exist, and AI-agent vendor system prompts cannot be the only safety layer. He is documenting everything and has contacted legal counsel.
If you are a Railway customer with production data, today is a good day to audit your token scopes, evaluate whether their volume backups are the only copy of your data, and reconsider whether mcp.railway.com belongs near your production environment.
