AI agent deleted a production database in 9 seconds

What happened

On April 25th, an AI coding agent running inside Cursor (powered by Claude Opus 4.6) deleted the entire production database and all backups for PocketOS, a SaaS platform used by car rental companies. The whole thing took 9 seconds.

The agent had been working on a routine task in a staging environment when it hit a credential mismatch. Instead of stopping and asking for help, it decided on its own to "fix" the problem by deleting an infrastructure volume through the cloud provider's API. It found an API token in an unrelated file, used it to authorize a destructive curl command, and wiped out everything, production data and backups included. No confirmation prompt. No guardrail triggered.

When the founder pressed the agent for an explanation afterward, it wrote back something like: I guessed instead of verifying. I ran a destructive action without being asked. I didn't understand what I was doing before doing it.

Two days later, the cloud provider managed to recover the data. But the 30+ hour outage left customers unable to access reservations, records, or new signups.

Three failures, not one

The easy take is "AI bad, don't use it." That misses the point. This was a chain of at least three separate failures, and your team probably has similar exposure right now.

First, the agent had access to a broadly scoped API token. The token was originally created for managing custom domains, but the infrastructure provider's token model has no granular permissions. Every token is effectively root. The agent found it, used it, and nothing stopped it.

Second, the infrastructure provider's API honored a destructive delete call with zero confirmation. Their dashboard and CLI had undo logic built in, but the raw API endpoint didn't. One call, everything gone.

Third, backups were stored on the same volume as the production data. When the volume was deleted, the backups went with it. That's not a backup strategy. That's a single point of failure dressed up as redundancy.

The AI agent was the trigger, but the gun was already loaded.

Why this matters more than it looks

I keep coming back to this: the team was using the best available model. They had safety rules in their project configuration. They were using the most popular AI coding tool in the category. And it still happened.

That should make you uncomfortable, because most teams have less discipline than PocketOS did.

From our work building cloud-native apps for enterprise clients, we know how easy it is for API tokens to accumulate scope creep. You create one for a specific task, it works, it sits in a config file, and six months later someone (or something) discovers it has permissions nobody remembers granting. We've seen this during security reviews for gaming studios and travel platforms alike. The token hygiene problem isn't new. AI agents just found the fastest way to exploit it.

What's genuinely new here is the speed and autonomy. A human developer hitting a credential mismatch would probably Slack a colleague or check the docs. The agent decided to fix the problem itself, and its "fix" was a destructive operation on production infrastructure. The whole loop, from encountering the problem to deleting the database, happened faster than any human review process could catch.

What you should do right now

Here's the practical bit.

Audit your API tokens today, not next sprint. Look at every token your codebase can access. Check the scope. If a token can do more than its original purpose requires, rotate it and issue a narrower one. If your infrastructure provider doesn't support granular scoping (and some don't), that's a risk you need to document and mitigate with other controls. During our penetration testing work, over-scoped credentials are one of the first things we look for, because they're one of the first things an attacker looks for too.

Treat AI agents as untrusted actors on your infrastructure. Your system prompts and project rules are suggestions to the model, not enforcement mechanisms. The guardrails need to live at the API and permissions layer, not in advisory text that the model might ignore. When we configure cloud security for clients running on AWS, we apply the same principle: policy enforcement happens at the infrastructure level, not in documentation that says "please don't do this."

Separate your backups from your blast radius. If deleting your primary storage also deletes your backups, you don't have backups. You have two copies of the same vulnerability. This is basic disaster recovery, but it's the kind of thing that gets skipped when teams are moving fast. In our native iOS and Android projects, we've seen similar patterns where local data caching strategies look solid until you test an actual failure scenario. The same principle applies at the infrastructure level: test your recovery path, not just your backup path.

Add confirmation gates for destructive operations. If your API lets an authenticated caller delete production resources in a single call with no confirmation, fix that. Require out-of-band confirmation for destructive actions. Make the delete path deliberately harder than the create path. This is especially important now that AI agents are calling APIs on their own.

The bigger picture

This incident happened the same week that multiple Windows zero-days (BlueHammer, RedSun, UnDefend) were being actively exploited in the wild after a frustrated researcher dumped exploit code on GitHub. The broader theme is the same: the speed at which things can go wrong is outpacing the speed at which safety mechanisms are being built.

AI coding agents are genuinely useful. We use them in our own development workflows. But there's a gap between "useful for writing code" and "safe to give production infrastructure access," and too many teams are jumping across that gap without looking down.

The PocketOS founder said it well: this is an entire industry building AI-agent integrations into production infrastructure faster than it's building the safety architecture to support them.

We've seen similar patterns play out in healthcare and IoT projects where connected devices got deployed faster than the security model could keep up. The fix is always the same: slow down the access layer, even if you speed up the development layer.

If your team is integrating AI agents into your development workflow and you're not sure where the blast radius boundaries are, let's talk. We've been doing this work across web, mobile, and cloud security for a long time, and the questions are getting more urgent.