When an AI Agent Deleted the Production Database: What PocketOS and Replit Teach

In April 2026 a coding agent running on Claude found an all-powerful API token in an unrelated file and deleted a company's production database and backups in nine seconds. In 2025 a Replit agent did the same despite a code freeze. The model was not the root cause. Access was.

Hugo Matthaey

Hugo Matthaey

Oct 17, 2026

A robot arm reaching for a database through a cable, with a loose key lying on a file nearby, stopped by a glowing locked barrier, while a separate vault behind the database holds a backup

In April 2026, an AI coding agent deleted PocketOS's production database, and its backups, in nine seconds. The founder, Jer Crane, described it publicly: the agent, powered by Claude Opus 4.6, was doing a routine task in staging, hit a credential mismatch, and decided by itself to fix it by deleting a storage volume. It found an API token in a file unrelated to its task, a token with what Crane called "blanket authority across the entire Railway GraphQL API", and ran the delete. There was no environment scoping and no confirmation step. Some customers, he said, "literally cannot operate their businesses" without them. A Replit agent did much the same in July 2025, during a code freeze. The headlines blame the AI. The root cause was access: a credential that could destroy production, sitting where an agent could read it, against an API that didn't ask twice. Below: what happened, why rules in a prompt don't help, and the controls that do.

What happened

From Security Magazine's account, based on the founder's post:

  1. The agent was working on a routine task in staging.
  2. It hit a credential mismatch and decided, unprompted, that deleting a Railway volume would fix it.
  3. It searched for an API token and found one in a file unrelated to its task. That token had authority over the whole Railway API.
  4. It ran volumeDelete. No environment scoping, no confirmation.
  5. In nine seconds the production database and its volume-level backups were gone.
  6. Afterwards the agent said it had guessed instead of verifying, acted without being asked, and broken its rule against destructive commands without user approval.

The platform has since added delayed deletes. Experts quoted in the coverage converged on one point: treat agents as identities with scoped, time-bound, least-privilege credentials, and put destructive actions behind authorization the agent can't grant itself.

The 2025 precedent. In July 2025 a Replit agent deleted a production database holding records for more than 1,200 executives and 1,100 companies, despite a code freeze instruction (Fortune). Replit's CEO committed to separating development and production databases.

Why prompt rules don't save you

The PocketOS agent had a rule against destructive commands without approval. It broke it. That is not a scandal, it is how these systems work: an instruction in a prompt is guidance the model weighs, not a lock. Whatever an agent's credentials allow, it can eventually do. So the controls that matter live outside the agent.

The controls that work

1. No production credentials in development. The agent working in staging should hold credentials that can only touch staging. Production access is separate, rare and deliberate.

2. Scope every token. One environment, the minimum actions. A token that can read logs should not be able to delete volumes.

3. Keep secrets out of files. Inject them at runtime from a secrets manager. A token sitting in a file is a token every tool and agent in that directory can find.

4. Make production refuse destructive actions. Turn on deletion protection for production databases, so deleting one requires a deliberate change first.

5. Keep backups out of reach of the same credential. If one token can delete the database and its backups, you have one copy, not two.

6. Put destructive operations behind a human, through a separate channel. Not "the agent asks in the chat", but a change that needs a review the agent can't approve.

7. Make changes reviewable. Infrastructure changes as code, through pull requests, so a destructive change is visible before it runs. An AI reviewer such as Claude Code Review can read every one of those pull requests, but it comments, it never approves.

What we do

We use AI coding agents every day to build client software, so this is our problem too. What protects our production:

  • Production databases have deletion protection on, set in our infrastructure code.
  • Infrastructure changes go through pull requests in Terraform, reviewed, with history of who changed what.
  • Production deploys come from releases, not from someone's machine, after the same image has run in staging.
  • Secrets live in HashiCorp Vault and Google Secret Manager, injected at runtime, not in files in the repository.
  • Database and admin access is only reachable from our private network, never from the internet. Details on our security page.

For the agents we build for clients, the same principle applies to the agent's tools: each tool declares whether it reads or writes, writes need a stronger permission, and changes are visible with one-step undo. Why we prefer undo to an approve button.

Related: AI agent security, vibe coding security, and we deleted the approve button.