Cursor AI coding agent deletes entire production database and backups in shocking nine-second autonomous failure incident | Daily Reports Online
- Cursor AI coding agent deletes production database and backups in nine seconds
- Credential mismatch triggered an autonomous, destructive decision inside the Cursor system
- Railway API allowed destructive actions without confirmation safeguards
A software company founder watched helplessly as an AI coding agent deleted his entire production database and all associated backups in just nine seconds.
Jer Crane, who runs the automotive SaaS platform PocketOS, said the disaster unfolded when a Cursor agent powered by Anthropic’s Claude Opus 4.6 encountered a credential mismatch.
The agent decided on its own to fix the problem by deleting a Railway volume where the application data lived. “It took 9 seconds,” Crane wrote in a social media post detailing the incident.
Article continues below
Rogue AI agent bypassed multiple safeguards
The Cursor agent searched for an API token to execute the deletion and found one sitting in an unrelated file.
That token had been created for adding and removing custom domains through the Railway CLI, but its permissions were not limited to those specific actions.
Railway’s API allowed destructive actions without any confirmation check, and the platform stored volume-level backups on the same volume as the source data.
Wiping a volume also deleted all backups associated with it, leaving Crane with no immediate recovery option.
When asked why it proceeded with the deletion, the agent admitted it had guessed instead of verifying and ran a destructive action without being asked.
Crane placed much of the blame on Railway’s architecture rather than solely on the AI agent.
The cloud provider’s API lacks confirmation prompts for destructive actions, stores backups on the same volume as production data, and allows CLI tokens to have blanket permissions across different environments.
Railway is also actively promoting the use of AI coding agents to its customers, creating more opportunities for similar failures.
Crane noted that proper cloud backup systems should store copies in separate locations, not on the same volume where the original data lives.
A reliable backup strategy requires isolation from the source to survive a deletion event like this one.
Recovery and lessons learned
Railway CEO Jake Cooper stepped in and helped restore Crane’s data within an hour.
The company patched the vulnerable endpoint to perform delayed deletions and added further safeguards to its API.
Crane estimates he has spent hours helping customers reconstruct their bookings from Stripe payment histories, calendar integrations, and email confirmations.
He is calling for stricter confirmation prompts, scopable API tokens, proper backup isolation, simple recovery procedures, and proper guardrails around AI agents.
AI tools like Cursor and Claude are powerful, but they are only as safe as the infrastructure they connect to.
A system that allows a nine-second deletion of both production data and its backups is not ready for AI agents that can act without human approval.
Crane’s data was eventually recovered, but the incident exposed how easily an AI agent can destroy data when the underlying platform lacks basic safety features.
Via Tom’s Hardware
Follow TechRadar on Google News and add us as a preferred source to get our expert news, reviews, and opinion in your feeds.
