Two incidents get mentioned in almost every conversation about AI agents and production data: the Replit agent that deleted a SaaStr app’s database despite an instruction to freeze code, and the coding agent that deleted PocketOS’s production volume and backups. Both were covered widely, mostly from social posts.
This post reads both from the accounts of the platforms involved, Replit’s and Railway’s, with the press reports for context. It sticks to what those sources say. Both stories ended with the data restored, and both platforms shipped changes afterwards. The people involved did what most of us do with a new tool that works well in a demo. The point is the mechanism, because the same mechanism is sitting in a lot of setups today.
Short versions of both are in our incident catalogue, with every sentence tied to a source.
Why primary sources
Incident coverage is written fast, from social posts, and later corrections rarely travel as far as the first headline. The platform’s own write-up is slower and more careful, and it describes the system: which endpoint, which token, which default. Those are the details you can act on.
Replit and SaaStr, July 2025
The reported version: in July 2025, press reports said Replit’s agent deleted a production database despite an instruction to freeze code, and that it told its user a rollback was impossible; the rollback worked.1
Replit’s own account, published at the end of that month, fills in the system. It says the agent deleted data from the app’s database; the data was fully restored with Replit’s Rollback feature; the agent didn’t know Rollback existed; and, before Replit’s new system, changes made during development could affect the production app.2 It also describes what changed: development and production databases are now separated by default, and the agent can’t change the production database during development.2
Read that list again as an engineer and three separate failures fall out:
- No separation. Development work could reach production data. The agent didn’t need to “escape” anything; production was simply in reach.
- The freeze was words. A code freeze that exists only as an instruction to the agent is a request the agent may or may not follow, and in this account it did not.
- The agent’s account of recovery was wrong. It said rollback was impossible. The platform had a working rollback.
PocketOS and Railway, April 2026
The reported version: in April 2026, an over-scoped API token let a coding agent delete PocketOS’s production volume and its backups in about 9 seconds; Railway later recovered the data.3
Railway’s own account names the parts. The agent found a Railway API token stored on the user’s machine and used it to call volumeDelete on a production volume. The token was account scoped, which Railway calls the maximum access possible. The API ran deletes at once, while the dashboard had a 48-hour window for the same action. The legacy API path the agent called performed a cascading delete that made the backups look unavailable in the UI, and Railway has since also delayed the delete on the backups themselves. Railway recovered the database, and all deletes now soft delete for 48 hours.4
Again, three failures, none of them exotic:
- A broad token in reach. The token was stored on the machine, and the agent found it. Railway says it was account scoped, the maximum access possible, and more than the work required.
- The guardrail lived in another surface. The dashboard had a delay. The API, which is what agents use, didn’t.
- Backups shared the blast radius. The Register reports one API call took the production database and its volume-level backups.3
What they have in common
Put the two side by side and the shape is the same:
- The agent could reach production with destructive rights. In one case through the development environment, in the other through a token on disk.
- The safety measure was somewhere the agent didn’t go. A freeze in the chat. A delay in the dashboard. Agents work through APIs, CLIs and SQL, so a guardrail that only exists in a human interface or in the prompt doesn’t apply to them.
- Recovery depended on the platform. Both ended well because the platform kept something the user’s own credentials couldn’t remove. That’s luck, unless you check in advance that it’s true for your setup.
The fixes (none of them need a vendor)
These come straight out of the two accounts:
- Scope every token to its job, and keep long-lived tokens out of places the agent can read: the repository, the home directory, shell history. If a platform offers project or environment scopes, use the narrowest one.
- Separate production by credentials, not by naming. If the agent’s environment holds no production credential, it can’t touch production, whatever it decides.
- Make a freeze a permission change. Revoke the write grant or the deploy right for the week. Restore it afterwards.
- Prefer APIs that delay destructive calls, and ask your providers whether their API behaves like their dashboard. Railway’s change is the model: the 48-hour window the dashboard had now applies to API deletes too.4
- Keep backups out of the same blast radius. The credential the agent holds shouldn’t be able to delete the backups. Test a restore before you need it.
- Don’t take the agent’s word on recoverability. When something goes wrong, the agent’s explanation is a guess. Check the platform’s docs and your own backups.
Our checklist before an agent touches production turns these into yes-or-no checks.
Where a tool like ours fits, and where it doesn’t
Be precise here, because it’s easy to overclaim. The PocketOS deletion was an infrastructure API call, not a database write; nothing that reads Postgres’s change log would have seen it coming, and we don’t suggest otherwise. What applies is the token’s scope and the platform’s delay.
The Replit case is closer to what Deedglass does, which is to put rules in front of an agent’s tools: refuse destructive SQL outright, wait for a person on writes outside the agent’s job, and seal each action into a chain of records anyone can check offline, with what Postgres committed.5 Even there, the first fixes are the ones above, separation and real permissions, and they need nothing from us.
If you want to see rules refuse a DROP and a person countersign an undo on a real Postgres, try the playground in your browser. To check what your own agent’s role can change today, run the free scan, npx deedglass scan; the grade is explained here, and nothing leaves your machine.