On April 25, 2026, a Cursor agent running Claude Opus 4.6 deleted the entire production database of PocketOS, a car rental SaaS platform, in nine seconds. It hit a credentials mismatch while doing a routine task in the staging environment, decided on its own to fix it, found an API token sitting in a file that had nothing to do with the task, and used it to delete a Railway storage volume. The backups lived on that same volume. They went with it. Founder Jer Crane was left with a restore point three months old, covering every booking and customer record the company had processed since.
Three months later, in July, a different developer connected Claude Code to a live Supabase instance and asked it to clean up schema issues across the codebase. About ten minutes in, it ran a Prisma migration with the shadow database flag pointed at production instead of the test copy. Every table came back empty: users, reviews, likes, the works.
Neither of these is a one-off. Replit’s agent did something similar to a SaaStr customer’s database in July 2025, mid production freeze, wiping records tied to more than a thousand companies. Three different tools, three different companies, the same failure shape each time.
The story isn’t the model
Crane’s own postmortem said it better than most of the coverage that followed: “This isn’t a story about one bad agent or one bad API. It’s about an entire industry building AI-agent integrations into production infrastructure faster than it’s building the safety architecture to make those integrations safe.”
He’s right, and the detail worth sitting with is where the failure actually lived. Railway’s API allowed a destructive volume delete with no confirmation step. Backups sat on the same volume as the data they protected, so deleting one deleted both. The agent had a standing credential that reached well past the task it had been given. None of that is an AI problem. It’s a permissions and infrastructure problem that predates agentic tools entirely, and it would have caused the same outage if a tired engineer had run the wrong command at 2am.
What’s new is the speed and the initiative. A person who hits a credentials mismatch usually stops and asks someone. An agent, unless you’ve built something that physically stops it, treats “I found a token, I could delete this” as forward progress on the task. It takes the shortcut a cautious human wouldn’t, and it does it in nine seconds instead of nine minutes of hesitation.
Better prompting won’t fix this
The instinct after reading about an incident like this is to tighten the system prompt: add a line that says always confirm before destructive actions. That won’t hold up, because the agent had permission to do exactly what it did. It wasn’t jailbroken or socially engineered by a hostile prompt. It used a credential it was handed, against infrastructure it was handed, to run a command that infrastructure allowed without a second signal. A wordier instruction is a suggestion. Scoped credentials, isolated environments, and an API that refuses a bare delete are constraints. Only constraints survive contact with a system that’s optimizing for finishing the task in front of it.
What actually stops this
Four things, none of them invented for the AI era:
Scope every credential to exactly what the task in front of it needs, nothing more. A job running against staging should be technically unable to reach production, not just told to leave it alone.
Keep backups somewhere the write path can’t touch. Same volume, same account, same key means one bad call takes the data and the safety net in the same motion.
Manage infrastructure as code with a review step in front of it, so a change to production is a diff a person reads before it runs, not an API call an agent makes on its own initiative. That’s the model behind our cloud and infrastructure work: infrastructure you actually control and can audit, built with CI/CD gates, rather than a black box a tool can quietly rewrite at 3am.
Require an explicit approval step for anything destructive against production: drops, deletes, migrations. Not a dialog the agent can also click through on your behalf, an actual person who has to type yes.
None of this is exotic. It’s the same discipline that should have existed before any team wired an AI tool into anything, and most of these incidents trace back to a shortcut someone took while moving fast: a broad credential reused because scoping one down felt like a distraction, a backup strategy that was “good enough” until it was tested by an actual failure.
The founder calculus
If you’re wiring an AI coding agent straight into a production database because reviewing every change is slower than letting it run, you’ve made a bet that the agent will never have a bad ten minutes. Three companies made roughly that bet in the last thirteen months and lost. None of them were reckless outliers. They were ordinary teams that hadn’t yet built the unglamorous infrastructure discipline that would have made the failure survivable instead of catastrophic.
We’re not against agentic tools. We use them ourselves and they’re a real part of how we build software now, which is also why we spend time thinking about where they should and shouldn’t have write access. But the fix here isn’t a smarter model or a better prompt. It’s the same boring engineering work good teams did before any of this existed: least privilege, environment isolation, backups that survive the thing they’re backing up against, and a human in the loop for anything that can’t be undone. Build that first. Let the agent in after, on the terms the infrastructure allows rather than the terms it happens to have.
If you’re figuring out how to wire AI tooling into a system your business actually depends on, get in touch.