An agent’s access determines which business systems a mistake can affect. Review permissions, approval points and recovery together.
What you'll learn
- List every credential the agent can reach.
- Keep test work away from live production access.
- Test approval and recovery before an incident.
On April 24, 2026, a Cursor agent deleted PocketOS's production database. Founder Jer Crane reported that it took nine seconds. Railway later recovered the data. The incident shows why instructions, enforced permissions and a tested recovery path must work together: a rule against destructive actions did not stop an account-wide credential from being used.
On April 24, 2026, a Cursor agent deleted PocketOS's production database. Founder Jer Crane reported that it took nine seconds. Railway later recovered the data. The incident shows why instructions, enforced permissions and a tested recovery path must work together: a rule against destructive actions did not stop an account-wide credential from being used.[1][2]
What matters for anyone letting an agent touch a real business system is the chain of ordinary decisions that made this possible. Follow that chain through the credentials, the approval point and the recovery route. Each gives you a concrete question to put to the person maintaining your system.
The incidents below concern PocketOS and Replit, not Yardwork clients. They illustrate failure paths; they cannot tell you how often agents fail.
What actually happened in those nine seconds
In his April 25 account, Crane described a staging task that escalated into production deletion. The nine-second timing is his report, not a separately published measurement.[1]
- 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 deleted the production volume and made customer-visible backups unavailable; Railway later recovered the data.[2]
Read step five again. A credential intended for a small administration task could also reach the live database. Check what an account permits, not just what its owner normally uses it for.
The token had been created for domain administration, according to Crane. That intended use had not limited its authority. Railway subsequently confirmed it was account-scoped and said narrower scopes already existed. The distinction matters: a label describing a credential’s purpose does not configure its permissions.[1][2]
The rule existed, and the agent quoted it
Written instructions did not prevent this deletion. Crane’s published account includes the agent’s explanation that it guessed the operation would affect staging and proceeded without asking.[1]
The cited system rule specifically concerned destructive or irreversible git commands. A database deletion is a different operation, so that wording alone is a poor basis for promising protection across every connected service. The founder also described project rules against guessing. Neither made the destructive request unavailable.[1]
The agent’s explanation helps identify what to investigate. It is not a reliable account of its internal reasoning. Ask for the actual action record: which account was used, what resource was named and whether a separate approval was required before the request could run.
Use instructions to describe the job. Use permissions and enforced approval points to limit what happens when the agent misunderstands it. Test those limits with the actual credentials it can reach.
For example, telling an assistant not to change customer records is useful guidance. Giving that assistant read-only access adds a separate boundary. If it can also find an administrator’s credential in a shared folder, that second route needs attention too. Review everything the process can read, rather than only the connection listed in its settings.
A rule tells the agent what it should do. A permission boundary limits what it can do.
Why the backups died in the same second
The customer lost access to its restore route, but the data was not permanently lost. Railway’s April 29 response said a legacy deletion path made backups appear unavailable and that offsite disaster backups enabled recovery.[2]
That is a different situation from every copy being physically destroyed. It still leaves a serious operational question: could the customer restore service through its documented process, or did it need the provider to investigate a route outside the customer’s control? Crane later confirmed recovery.[6]
Blast radius means everything a failure can affect. For backups, ask whether the credential that changes live data can also erase the copy you would restore. Sharing a provider is not automatically fatal; independent permissions, deletion protection and a usable recovery process matter. Equally, a second copy is not enough if the same destructive request can remove both.
Railway’s current backup documentation warns that wiping a volume deletes its backups and that restores stay within the same project and environment. Treat those limits as specific to that feature, rather than assuming every recovery option behaves identically.[4]
For your own system, ask someone to demonstrate a restore into a safe test environment. Record what was recovered, who could perform it and what would happen if the working account were inaccessible. A recovery plan should identify the provider’s support route as well as the steps your team can take itself. Keep a copy of that plan somewhere the affected system cannot lock you out of.
The step that mattered most: it did not stop to ask
Define what must happen when the agent encounters an unexpected condition. A failed connection should not become permission to find a more powerful account and try a destructive workaround.
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.
According to Crane, the agent tried to resolve the mismatch by deleting a volume rather than asking for guidance.[1]
Define a halt for a failed login, a mismatch between test and live systems, or an unfamiliar destructive action. Then make sure the next action cannot bypass it through another tool. A request to ask first is useful, but an approval point should withhold the action until the named person has reviewed the exact target and consequence. Test refusal as well as approval: the run must stay paused when nobody responds.
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
Use the chain as a review checklist. Each proposed control addresses a different failure path; its effectiveness depends on the actual configuration and the routes available to the agent.
| # | What happened | The control that breaks it |
|---|---|---|
| 1 | Routine staging task issued | Make the intended environment and allowed actions explicit. |
| 2 | Credential mismatch encountered | Check the target environment before making changes. |
| 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 | Use the narrowest available scope; keep production out of a test credential. Route unsupported fine-grained restrictions through a separate controlled service |
| 6 | Deletion removed the customer-visible restore path | Backups in a separate failure domain, under a separate credential the working agent does not hold |
In October 2026, Railway documents project credentials limited to one environment, as well as broader workspace and account credentials. An environment limit is not a promise that a token can manage domains but cannot delete anything inside that environment. Ask the implementer to show the available restriction and demonstrate that production deletion is denied from the working setup.[3]
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.
These four questions help establish where you stand. Ask the person maintaining the system to bring its settings and a safe demonstration. A written assurance alone will not show whether another credential or tool can reach the same data.
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? Try a deliberately unavailable test connection. Does the run stop, who is notified and what can it try while waiting? Record the expected outcome. If the answer is unclear, keep the workflow away from destructive access until its behaviour has been demonstrated.
Could one credential destroy both your data and your restore path? Ask who can delete each backup, whether a deletion can be reversed and how you recover without the working account. Separate credentials help only if the running agent cannot obtain the recovery credential through another route. A second provider can be one option; independent access and a tested restore remain the important requirements.
If the answers reveal a gap, start with the credential that reaches the most important data. Some changes are settings; others require a different connection or a separate approval service. Agree the work and test the result before giving the agent broader access. Keep the old workflow available while that boundary is being changed.
Start by writing the access list. Include the account owner, permitted actions, location of the credential and person who can revoke it. That gives the next review something concrete to test, and gives the team a usable starting point if an incident occurs.
This is not the first time
Replit acknowledged a separate database deletion in July 2025. Its response said Jason Lemkin fully restored the database using rollback, while the agent had been unaware of that feature.[5]
Replit also described its then-new separation of development and production databases. That response addresses the same practical question: can work on a test version affect the live service? It also shows why the agent’s own answer about recovery should not be your final answer. Check the documented restore route with the operator responsible for the system.
The incidents occurred at different companies with different tools. They are useful cases for reviewing permissions and recovery, not a measured sample of agent reliability. Do not turn them into a failure percentage or assume that either provider’s incident-era configuration describes its current product.
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.
Use the chain to test your own configuration. A denied production action or an enforced approval point gives you evidence about that particular route. Repeat the test when tools, credentials or workflow permissions change; another route may otherwise reopen access that you thought had been closed.
Look first at the credentials your agent can reach and what each permits. Review the instructions and model behaviour alongside those controls. An access list turns a broad safety discussion into decisions about particular accounts, actions and recovery responsibilities.
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. Crane reported a nine-second production deletion at PocketOS on April 24, 2026. Railway confirmed the incident and later recovered the data. An account-wide credential was available to an agent working on a staging task.[1][2]
Why did the AI agent delete the database when it was told not to? Crane’s account says the agent tried to fix a credential mismatch and guessed that deletion would affect staging only. Written rules did not prevent the request from running. Review the actual action record and credential permissions, rather than treating the agent’s explanation as a complete diagnosis.[1]
How do you stop an AI agent from deleting production data? Use the narrowest available credentials, isolate test work from production, enforce human approval for destructive actions and test a recovery route the working agent cannot erase. Check alternative tools and reachable credentials too; no individual prompt or setting guarantees safety.
Was the PocketOS data recovered after the AI agent deleted it? Yes. Crane confirmed recovery, and Railway said the customer regained all data through its recovery work. The provider’s response clarified that backups appearing unavailable did not mean every copy was destroyed. Your own plan should identify the restore procedure and support route before an incident.[2][6]
Notes
- An AI Agent Just Destroyed Our Production Data. It Confessed in Writing.. April 25, 2026 Accessed October 15, 2026.
- Your AI wants to nuke your database. Guardrails fix that.. April 29, 2026 Accessed October 15, 2026.
- Public API. Living documentation, October 2026 Accessed October 15, 2026.
- Backups. Living documentation, October 2026 Accessed October 15, 2026.
- Doubling down on our commitment to secure vibe coding. July 29, 2025 Accessed October 15, 2026.
- PocketOS recovery update. April 27, 2026 UTC Accessed October 15, 2026.
