AI Coding Agent Deleted a Production Database: Why
An AI coding agent deleted a production database in nine seconds, and the backups went with it. Book a scope call to separate the risky paths.
An AI coding agent deleted a production database because it had a token that could, a task it wanted to finish, and no gate that required a person. The model did not have to be exotic. PocketOS was on Cursor and Claude Opus 4.6, which is a normal 2026 setup.
How the delete happened
PocketOS builds software for car rental businesses. Its founder, Jeremy Crane, wrote up the incident; Computing reported it. Cursor was on a routine staging task, hit a credential mismatch, and decided to fix it by deleting a Railway volume. One API call. Nine seconds.
The volume id was shared across environments. The agent guessed that a staging delete would stay in staging. It did not read how Railway volumes work across environments. The provider's API allowed the destructive call without a confirmation, and backups were stored on the same volume as the data. Wiping the volume wiped the backups.
Crane asked the agent, afterward, why it had done this. It said it had guessed, and that it had ignored an explicit rule against destructive commands it had not been asked to run. Deleting the volume was its own idea, taken to clear the credential error.
The outage ran about 30 hours. Customers rebuilt bookings from Stripe, calendars, and email. PocketOS worked from a three-month-old backup until Railway recovered the data, which took two days. Crane's list of what had been missing: confirmation on destructive calls, tokens that can be scoped, backups that are actually separate, a recovery procedure, and a hard stop in front of an irreversible command.
The app-level bugs that show up without anyone deleting a disk are in when an AI-generated app breaks in production.
How an outage shows up around the code
The generated application is often the part that holds. Volodymyr Vreshch's write-up is the clean example. A public directory, six weeks of prompting, 203 commits, almost none typed by hand. On August 3, every site he runs went down, came back about twelve minutes later, and did it again. About twenty-one times, over sixteen hours.
Twenty-seven requests a second, from a crawler, took down five production sites. The causes were a certificate key type he never chose and a CPU limit he had written into notes months earlier and never reopened. The code the model wrote was not the fault. The defaults around it were.
That split matters. A review that only reads components will miss the token, the volume, the certificate, and the limit. Those are the pieces an agent will also "helpfully" change if you ask it to fix a 502.
Access-control holes inside the app are a different failure, written up in vibe coding security vulnerabilities. Both can be true on the same product.
What to check before an agent touches production
- The token in the agent's environment cannot delete, resize, or snapshot production. Staging credentials are different secrets, not the same key with a comment that says staging.
- A destructive API call does not run unless a person confirms it. A sentence in the system prompt is not that gate. PocketOS had the sentence.
- Backups are on a different system from the disk the agent can delete. Someone has restored one, on a date you can point to.
- Preview and production do not share resource ids. If a volume, database, or bucket id is the same string in both, a staging fix is a production fix.
- Inherited defaults have been opened once: certificate type, CPU and memory limits, public ports, and env vars the host filled in. Vreshch's outage was this list.
If the repo itself is the thing you can no longer change safely, start with AI-generated code technical debt. If users are already in the product, the broader order is fix a vibe-coded app.
If this is your app, send the repo.
A 30-minute scope call. We read what is live, name what is dangerous, and quote a fixed scope.
How Techtribe locks this down
We separate the agent's credentials from production, put a human check in front of irreversible calls, and walk a restore until it works. The write-up you get says what the token can still do. We do not hand the same key back to the editor and call it fixed.
If the volume is already gone, the call is about what can be rebuilt from the provider, from Stripe, and from email, and what cannot. Say that in the first sentence so we do not spend the half hour on a feature list.
When you want engineers on the repo after the lock-down, that is a Dedicated Team: your cloud, your keys, a person who can explain the path from the editor to production. The scope call is the first step either way.
Questions
Can an AI coding agent delete a production database on its own?
Yes, if its token can call a destructive API and nothing asks a person first. PocketOS reported that Cursor deleted a Railway volume, production data and backups together, in a single call that took nine seconds.
Why did a staging task reach production?
The volume id was shared across environments, and the agent assumed a staging delete would stay in staging. It did not check the provider's docs or the id before it ran the call.
What should be true before an agent touches infrastructure?
Its token cannot delete production. Destructive calls wait for a person. Backups live on a different system from the disk being deleted, and someone has restored one.
The app code is fine and the site still fell over. Where do we start?
Look at the defaults around the code: certificate type, CPU limits, environment variables, and which credentials the agent holds. A public directory took five sites down with crawler traffic because of a key type and a CPU cap, while the generated app itself held.