This past year,OpenClaw、Hermes Agent、Claude、Cursor Wait AI agentAI tools have become increasingly popular. Just give them a command and they can handle tasks, modify code, execute commands, and more, saving a lot of labor costs. While incredibly convenient, you really need to be careful when using them—once AI makes even a small error in judgment, the consequences could be far more serious than expected.
Recently, a foreign company shared the pitfall they encountered: using Cursor paired with Anthropic’s Claude Opus 4.6 model, an AI agent deleted the entire company’s production database along with backups in just 9 seconds, nearly shutting the company down.
Cursor AI Agent Wipes Out Entire Company Database in 9 Seconds! Backups Also Deleted Along With It, Claude Opus 4.6 Becomes the Culprit
According to Tom’s Hardware, Jer Crane, founder of US SaaS startup PocketOS, recently on his own X CommunityShared details of this incident. PocketOS is a company that primarily provides software for car rental operators, with the entire system running on cloud infrastructure provider Railway.
Jer Crane said that last Friday, PocketOS engineers were using Cursor’s AI agent to handle a minor issue with the Claude Opus 4.6 model. When the AI was running workflows in staging, it encountered a credential mismatch. Normally in this situation, the AI should stop, report back, or ask for human intervention—but Opus 4.6 decided on its own to fix it by directly deleting and recreating a disk volume on Railway.
Even more outrageous, the AI, in order to find an API Token capable of performing deletion actions, actually dug up an old Token from a completely unrelated file. This Token was originally only meant for the Railway CLI to add or remove custom domains, but its permission scope allowed “full access to all operations,” including the most dangerous delete commands. So after the AI grabbed the Token, it directly called Railway’s API to delete the volume, taking less than 9 seconds.
Additionally, Railway stores volume backup files directly within the same volume, meaning when AI deletes this volume, the backup disappears along with it, all without any confirmation mechanism whatsoever.
Afterwards, Jer Crane asked Opus 4.6 why it did this. The AI directly admitted its mistake, citing in its message the system rules it had received: “Never guess!” It acknowledged that it hadn’t read the documentation, hadn’t verified whether the volume ID covered both staging and production, and had executed an irreversible destructive operation without asking for the user’s consent.
Fortunately it wasn’t that bad in the end. After Jer Crane made the incident public, Railway’s CEO decided to handle it personally and helped restore PocketOS’s data. They also added a “delayed deletion” logic to that API endpoint afterward to prevent future incidents where an AI wipes out the entire database in one go.
This incident serves as a good reminder for those using AI agent tools to always ensure proper security precautions are in place.
- Permission scope matters a lot. For any API tokens or database credentials, restrict permissions as much as possible and limit IP ranges wherever you can. Never leave tokens with unrestricted access sitting on your computer.
- Production and testing environments must be completely separate.
- Backups must be kept in a separate location so they can still be recovered if accidentally deleted by AI.
- Most AI agents offer settings that require human confirmation before execution, to prevent AI from running destructive commands or to enforce double confirmation. These settings are highly recommended to enable, especially for irreversible actions like deletion, git push –force, and table DROP operations.
Source: KOCPC Chinese