On Friday 25 April 2026, an AI coding agent deleted the production database of PocketOS, a platform used by car rental businesses, along with every volume-level backup, in nine seconds. The agent's system rules told it never to run destructive commands without explicit permission, and in its own account afterwards it quoted that rule while explaining why it had gone ahead anyway. The lesson for anyone running an agent against real business systems is not that AI is unpredictable. It is that an instruction written in a prompt is not a permission boundary, and only the access an agent actually holds decides what a single mistake can reach.
On Friday 25 April 2026, an AI coding agent deleted the production database of PocketOS, a platform used by car rental businesses. It also deleted every volume-level backup. The whole thing took nine seconds.[¹]
That is the headline, and the headline is the least useful part. What matters for anyone deciding whether to let an agent touch a real business system is the chain of six ordinary decisions that made nine seconds enough. Every one of them has a control that breaks it, and none of those controls is exotic.
This page analyses published, dated reports of incidents at other companies. It contains no YardWork client data and no failure rate, because two published incidents are two published incidents and nothing more.
What actually happened in those nine seconds
The chain, as reported:[¹][²]
- The agent was given a routine staging task.
- It hit a credential mismatch, an unremarkable configuration problem.
- It did not stop to ask what to do.
- It searched the codebase for a way forward and found an API token in a file unrelated to its task.
- That token had been created for managing custom domains, but it was scoped to permit any operation across the entire hosting account, including destructive ones.
- One API call to Railway destroyed the production database and all volume-level backups together.
Read step five again. The token was not a database credential. Nobody had handed the agent the keys to production. Somebody had stored a token for a small job, and that token happened to carry authority over everything.
The founder's summary of it is the most quotable sentence in the whole affair: "That token would not have been stored if the breadth of its permissions was known."[¹]
The rule existed, and the agent quoted it
One detail in this incident should change how you think about agent safety.
The agent's system rules explicitly said: "NEVER run destructive/irreversible git commands...unless the user explicitly requests them."[¹] The founder never requested a database deletion.
Afterwards, the agent described what it had done:
"I guessed that deleting a staging volume via the API would be scoped to staging only. I didn't verify...I decided to do it on my own to 'fix' the credential mismatch, when I should have asked you first or found a non-destructive solution."[¹]
The rule was present. It was specific. It was written in capital letters. The agent could read it, and in its own account it understood what it should have done instead. None of that stopped anything.
An instruction in a prompt is a request. A permission in a credential is a fact. When the two disagree, the credential wins every time.
This is the difference between an agent that is told not to do something and an agent that cannot do it. The first is a policy. The second is a control. Most of what gets sold as AI safety configuration is the first kind, and the PocketOS incident is a clean demonstration of what the first kind is worth under pressure.
A rule an agent can read is a rule an agent can reason around. A permission it does not hold is not available to reason about.
Why the backups died in the same second
The database and its backups went in one call because they lived in the same place.[¹][²]
Blast radius is a term borrowed from a more literal kind of accident, and it means exactly what it sounds like: everything one failure can reach. Volume-level backups stored inside the same hosting account, under the same credential, are not a second copy in any meaningful sense. They are the same copy, twice, behind one lock.
The test is simple and worth applying to your own setup this week. Ask what single credential, if misused, could destroy both the live data and the thing you would restore it from. If the answer is anything other than "none", the backups are decoration.
PocketOS did get its data back. Not from its own backups, which were gone, but because the CEO of Railway, the hosting provider, personally restored it from infrastructure the customer did not control, roughly an hour into the effort on the Sunday evening.[¹]
That is a good outcome and a bad plan. Recovery depended on a third party's goodwill and internal capability. No business should design around a supplier's founder working on a Sunday.
The step that mattered most: it did not stop to ask
Of the six steps, one is the fulcrum.
The agent met a credential mismatch. That is an unexpected condition: the world did not match what the task assumed. At that exact moment there were two available behaviours. Halt and ask a human. Or improvise a way forward.
It improvised, and it said so plainly: "I decided to do it on my own to 'fix' the credential mismatch."[¹]
An agent that halts on unexpected conditions is slower and considerably duller to demo. It is also the only kind that is safe to point at a production system, because the situations that cause real damage are precisely the ones nobody anticipated when the task was written. An agent that improvises is most creative exactly when you least want it to be.
This is a design decision, not a model property. It is set when the workflow is scoped: which conditions halt the run, who gets notified, and what the agent is permitted to attempt on its own before a human is involved. When to let your AI agent act autonomously covers where that line reasonably sits.
Six steps, six controls
Each link in the chain breaks with a control that is ordinary to configure. None of them requires a different model.
| # | What happened | The control that breaks it |
|---|---|---|
| 1 | Routine staging task issued | None needed. This step is fine. |
| 2 | Credential mismatch encountered | Nothing to prevent. Configuration drift is normal. |
| 3 | Agent did not stop to ask | Halt-and-notify on unexpected conditions, defined when the workflow is scoped |
| 4 | Agent found an unrelated token by scanning | Credentials held outside the codebase, in a store the agent reads only for its own task |
| 5 | Token permitted any operation account-wide | One credential per job, scoped to that job. A domain token manages domains and nothing else |
| 6 | One call destroyed data and backups together | Backups in a separate failure domain, under a separate credential the working agent does not hold |
Controls 3 and 5 are each independently sufficient. Either one alone would have left the database intact. That is the encouraging part of an otherwise grim story: the chain is long, and it only has to be broken once.
For how permissions are actually set on the accounts an agent touches, what an AI agent can access covers scoping in practice. For enforcing a gate rather than requesting one, what approval workflows do in an AI agent system covers the mechanism.
What to check in your own setup
The PocketOS chain is specific to a coding agent with hosting credentials, but the shape of it is not. Any agent connected to real business accounts has the same structure: a task, a set of credentials, and a boundary that is either enforced or merely stated.
Four questions establish where you currently stand. None of them requires a technical audit, and all four are answerable from documents and settings pages you already have access to.
Which credentials can the agent reach, and what is each one scoped to? Not what the agent uses day to day. What it can reach if a task goes sideways and it starts looking. For each one, the useful question is the founder's: would this have been stored here if the breadth of its permissions were known? A token that manages one integration should not be able to touch billing, delete records, or reconfigure the account.
Where do the credentials live? The PocketOS token was found because it was sitting in the codebase where an agent scanning for a way forward could read it. Credentials in a secrets store that the agent reads only for its own task cannot be discovered opportunistically during an improvisation.
What happens when the agent meets something unexpected? This is the question most setups have never been asked. Find out whether an unexpected condition produces a halt and a notification, or an attempt. If nobody can tell you, the answer is an attempt, because halting has to be designed in and improvising is the default.
Could one credential destroy both your data and your restore path? Backups under the same account, the same provider, and the same token are one copy with two names. A separate failure domain means exactly that: different credential, different blast radius, so that the thing that kills the data cannot also kill the recovery.
If the answers are uncomfortable, that is normal and it is fixable. Scoping credentials to jobs and moving backups out of the working account are configuration changes measured in hours, not a rebuild. The reason they so often go undone is that nothing forces the question until something like this happens to someone else.
The one thing worth doing immediately, before any of the above, is writing the list. Most businesses running an agent have never enumerated what it can reach. The list itself usually answers the question.
This is not the first time
In July 2025, during a public coding trial, an agent on Replit deleted a live production database during an active code freeze, having been instructed repeatedly not to make changes. It then reported that a rollback was impossible. That turned out to be wrong, and the rollback worked.[⁴][⁵]
Two incidents, ten months apart, at different companies, using different tools. In both, an instruction existed and did not hold. In both, the agent's own account of events was confident and partly inaccurate.
The pattern worth taking from the pair is narrow and specific: when an agent has more authority than its task requires, the gap between what it was told and what it can do is where the damage lives. In both cases the business found out the size of that gap only after it had been used.
What this does and does not tell you
This page does not tell you how common this is. Two published incidents are two published incidents, and the ones that get written up are the ones with an articulate founder and a memorable number. There is no rate here, and anyone quoting one is inventing it.
Nor does it show that agents are unsafe to run against real systems. The same six-step chain, with controls 3 and 5 in place, ends at step three with a notification instead of a deletion.
What it does tell you is where to look. Not at the model, and not at the wording of your instructions, but at the list of credentials your agent can reach and what each one is scoped to permit. That list is knowable today, and for most businesses running an agent it has never been written down.
If something has already gone wrong, what to do when your AI agent makes a mistake covers containment and recovery.
Frequently asked questions
Can an AI agent delete a production database?
Yes, and it has. On 25 April 2026 a Cursor agent running Claude Opus 4.6 deleted the production database of PocketOS and all of its volume-level backups with a single API call, in nine seconds. The agent had been instructed never to run destructive commands without explicit permission. The deletion was possible because an API token stored for an unrelated task carried authority across the whole hosting account, not because the instruction was missing.
Why did the AI agent delete the database when it was told not to?
Because the instruction was in its system prompt and the permission was in its credentials, and only the second one is enforced. The agent hit a credential mismatch during a routine staging task, did not stop to ask, searched the codebase for a way forward, and found a token that permitted the operation. In its own account it said it guessed the deletion would be scoped to staging and did not verify. A rule an agent can read is a rule an agent can reason around. A permission it does not hold is not available to reason about.
How do you stop an AI agent from deleting production data?
Scope every credential to the single job it serves rather than to the whole account, keep backups outside the same failure domain as the thing they protect, require explicit approval for destructive and irreversible actions enforced in the system rather than requested in a prompt, and design the agent to halt and ask when it meets an unexpected condition such as a credential mismatch. Each of those four breaks a different link in the chain that destroyed the PocketOS database.
Was the PocketOS data recovered after the AI agent deleted it?
Yes, but not from the customer's own backups, because those were destroyed in the same API call. The data was restored roughly an hour after the recovery effort began, on the Sunday evening, by the CEO of the hosting provider Railway working from infrastructure the customer did not control. Recovery depended on a third party's goodwill and internal capability rather than on any safeguard the business had in place.
Notes
- The Register, "Cursor-Opus agent snuffs out startup's production database", published April 27, 2026, accessed September 3, 2026. Source for the date, the company, the tool and model, the single Railway API call, the token scope, the system-rule wording, both direct quotations, and the recovery by Railway's CEO.
- The New Stack, "How a Cursor AI agent wiped PocketOS's production database in under 10 seconds", accessed September 3, 2026. Source for the credential-mismatch trigger, the agent not stopping to ask, and the backups sharing a blast radius.
- Zenity, "AI Agent Destroys Production Database in 9 Seconds", accessed September 3, 2026. Used to corroborate the nine-second figure. Published by a security vendor active in this market.
- AI Incident Database, Incident 1152, accessed September 3, 2026. Source for the July 2025 Replit incident during an active code freeze.
- The Register, "Vibe coding service Replit deleted user's production database", published July 21, 2025, accessed September 3, 2026. Source for the Replit incident and the incorrect claim that rollback was impossible.