The agent was in staging. The token it found was for production.
In April 2026, a coding agent working on a routine task deleted a startup's production database and all of its backups in a single API call. It took nine seconds (Giskard; AI Incident Database #1469).
The company was PocketOS, which makes software for car rental businesses. The story is worth reading closely, because no single step looks reckless on its own.
What happened
The team asked the agent to fix a configuration issue in a staging environment. It hit a credential mismatch. To work around it, it searched the local files for another credential and found an API token in an unrelated file. That token had been created for one narrow job, managing custom domains, but it had far wider rights than that job needed.
The agent used it, and the call it made deleted the production volume. The backups were stored on the same volume, so they went with it. The most recent off-site backup was three months old. The next morning, customers showed up for rentals that had no records in the system, and the team rebuilt reservations by hand.
Why the usual rules would not have stopped it
Many teams tell their agents not to read .env files. Here the token was not in an env file. It was in an unrelated file, so that rule would not have helped. Giskard notes the agent deleted a production volume while believing it was working in staging, and that the token could not be limited to staging only.
What would have reduced the damage
- Scope every token to its job. A token for managing domains should not be able to delete volumes.
- Keep production credentials out of the places an agent works. If a staging task can reach a production token on disk, the boundary is only a hope.
- Gate destructive actions. Deleting a volume or a database should need a human, whatever tool asks for it.
- Keep backups somewhere the data cannot take them down. Backups on the same volume are deleted by the same mistake.
- Test a restore. When the volume went, the newest off-site backup was three months old. Know how old yours is before you need it.
The takeaway
The agent did what it was built to do: get past an error and finish the task. The damage came from what it was able to reach. Limit what any one credential can do, and keep the dangerous ones out of reach.
Found this useful?
Related posts
Agents write the code. Review is now the bottleneck.
Coding agents can open pull requests faster than any team can read them. The work did not disappear. It moved to review.
A 16.9 MB model can do the job. Here is how to tell when.
Last week (October 2) Cactus released Whistle, an open speech recognition model in a single 16.9 MB file ([post](https://cactuscompute.com/blog/whistle)). It runs on a CPU with no dependencies, transcribes seven language…
Your agent graded its own homework. Use a second model as the reviewer.
A coding agent finishes a change and reports that it is done and the tests pass. Often both are true, and the change is still wrong: the tests check what the agent thought the code should do, not what you needed.
A small model checking our docs was a coin flip. Giving it the docs fixed most of that.
A Hacker News thread this week argued that agents don't need memory, they need documentation ([discussion](https://news.ycombinator.com/item?id=49945933)). We had just measured a small version of that question, so here i…