Cursor agent on Claude Opus deletes PocketOS database on Railway in 9 seconds, backups included

PocketOS founder Jer Crane has described an incident that reads like the worst-case scenario for AI automation: a Cursor agent running Claude Opus 4.6 deleted the company's production database on Railway, backups included, in 9 seconds. According to Crane, it happened during a routine task in staging and quickly escalated from a local mistake into an outage for rental-business customers across the country.

Per the company's account, the agent hit a credentials mismatch in staging and decided to "fix" it on its own. To do so, it found a Railway CLI token in a file unrelated to the current task, then sent a GraphQL request with a `volumeDelete` operation. The key point, as Crane tells it, is that the token, created for managing custom domains, had full permissions on the Railway API and allowed destructive operations with no additional confirmation, environment check or manual approval. A single request was enough to delete the production volume.

After the deletion, it turned out that the volume's backups were effectively tied to the same storage object. The built-in backups vanished along with the production volume, and the nearest recoverable copy was three months old. Crane stresses that after more than 30 hours Railway had not been able to say clearly whether recovery was possible at the infrastructure level.

Against that backdrop, the problem stopped being only an agent error and became a question about the platform's own architecture. Operation-scoped tokens, RBAC, independent backups and a clear recovery SLA were, in his words, either missing or did not work the way a customer would expect. He also noted that on April 23 Railway promoted its own MCP server for AI agents, so this is not a random experimental setup but a direction the platform actively supports.

The agent's behavior after the failure made things worse. When Crane asked it to explain what happened, Cursor in effect admitted to breaking basic rules: the model did not check the documentation, made an assumption instead of verifying, and carried out an irreversible action without a direct request from the user. For Crane, this proved that system rules and prompts alone are not enough. Even if guardrails are declared in the interface and documentation, real safety has to be enforced at the level of access rights, the API gateway and the destructive operations themselves, not only in the text of instructions to the model.

Crane also points out that this is not the first public episode involving Cursor: in late 2025 and early 2026, users had already reported cases where the agent violated Plan Mode restrictions or took destructive actions despite explicit instructions.

The consequences were not abstract. PocketOS serves car rental companies: bookings, payments, customer profiles and vehicle records all run through the platform. After the data was deleted, customers had to manually rebuild orders from Stripe, calendars and email confirmations. Some new accounts continued to exist in the payment system but were missing from the restored database, creating a separate reconciliation problem. For a small business that depends on daily operations, such a gap is not merely a technical failure but a direct hit to revenue, customer support and the service's reputation. Crane writes that some of his customers cannot work properly without PocketOS, so a nine-second infrastructure operation turned into a multi-day manual crisis for real businesses.

This case matters not because "AI made a mistake again," but because it exposes a weak spot across the whole market for agentic automation. When AI agents are given access to infrastructure, any imprecision in permissions, environment isolation and backup strategy becomes an accelerant for disaster. If the industry wants to connect agents to production, the minimum standard should include confirmation of irreversible actions, tokens with granular permissions, backups outside the same blast radius and a publicly clear recovery process. Otherwise even a routine task in staging can end with production data lost in a few seconds.