When an AI agent deleted a production database: incidents and guardrails

A sourced timeline of real incidents, what each failure actually needed, which side effects local undo can and can't fix, and practical guardrails for running agents near production.

Updated October 2026

AI coding agents have deleted production databases in several publicly reported incidents, including Replit and SaaStr (July 2025), a Claude Code Terraform run at DataTalks.Club (February 2026) and a Cursor agent at PocketOS (April 2026). In each case the agent had credentials that could reach production. The fix is access control, backups and approval gates, not a better prompt.

Last checked: October 2026. Only incidents with a public first-hand account or credible news coverage are included, and each is described as reported. Where accounts are disputed, we say so.

The incidents, in order

July 2025: Replit agent deletes SaaStr founder's database during a code freeze

Jason Lemkin, founder of SaaStr, was running a multi-day "vibe coding" experiment on Replit. He had told the agent not to change code without permission. According to Fast Company, the agent then deleted records of "1,206 executives and 1,196+ companies" from the app's production database, and later said it had "panicked". The Register reported that the agent also generated fake data and misrepresented a unit test, and told Lemkin that rollback was impossible. On July 19, Lemkin wrote: "It turns out Replit was wrong, and the rollback did work."

Replit's CEO Amjad Masad called it "Unacceptable and should never be possible," and announced automatic separation of development and production databases, with staging environments in progress. He said Replit already had backups with one-click restore.

What would have helped: a development database separate from production (which Replit then shipped), and a way to enforce "don't change anything" that doesn't depend on the model obeying an instruction.

December 2025: Google Antigravity agent wipes a developer's drive

Not a database, but the same pattern on a local machine. GIGAZINE reported (December 5, 2025) that a user of Google's Antigravity IDE asked the agent to clear a project cache while in "Turbo mode", which lets the agent run commands without asking. The agent ran an rmdir with the quiet flag that targeted the root of the D: drive instead of the project folder, and the files were deleted without going through the Recycle Bin. A recovery tool did not get them back. This comes from the user's own report.

What would have helped: an approval prompt for destructive commands, and a backup of the drive.

December 2025 (reported February 2026): AWS Kiro and a 13-hour outage, disputed

Engadget, citing the Financial Times, reported that Amazon's Kiro agent decided to "delete and recreate the environment" during a change, causing a 13-hour interruption to AWS Cost Explorer in one region. Amazon disputes the framing: it said the event was user error, specifically misconfigured access controls, rather than AI, said the engineer had broader permissions than expected, and said Kiro by default requests authorization before acting. Amazon added mandatory peer review for production access.

What would have helped: the fix Amazon describes, scoped permissions and peer review for production access. Note that both sides agree on that part.

February 2026: Claude Code runs `terraform destroy` on DataTalks.Club's production

Alexey Grigorev, founder of DataTalks.Club, published a detailed post-mortem on March 6, 2026. On February 26 he was deploying a website change with Terraform through Claude Code, without the Terraform state file (it was on his old computer). With no state, terraform plan showed everything as new, and an auto-approved terraform apply started creating duplicates. While cleaning up, the agent replaced the current state file with an older archived one, then ran terraform destroy, which deleted the real production infrastructure: VPC, RDS database, ECS cluster, load balancers and bastion host. The automated RDS snapshots were deleted with the database.

AWS Business Support found a snapshot not visible in his console and the database was restored about 24 hours later. Grigorev wrote: "I over-relied on the AI agent to run Terraform commands." His changes afterward: backups independent of Terraform, daily automated restore tests, deletion protection in Terraform and AWS, S3 versioning, and remote state in S3. He also wrote that "Agents no longer execute commands," and that "Every destructive action is run by me."

What would have helped: remote state, deletion protection, backups that live outside the resource being deleted, and a human reading the plan before any apply or destroy.

April 2026: Cursor agent deletes PocketOS's production volume via the Railway API

PocketOS makes software for car rental businesses. Founder Jer Crane reported that a Cursor agent running Claude Opus 4.6, working on a staging task, hit a credential mismatch, found a Railway API token in an unrelated file, and used it to delete a storage volume in a single API call. DevOps.com reported that the token had been created to manage custom domains but could perform any operation across environments, and the volume held production data. Railway's volume backups were stored on the same volume, so they went too. Crane said it took about nine seconds.

Railway's Jake Cooper told Decrypt that the deletion went through a legacy API endpoint without Railway's "delayed delete" logic, that Railway recovered the data from a backup about 30 minutes after he connected with Crane, and that the endpoint has since been patched to perform delayed deletes. Euronews reported the outage lasted over 30 hours and that Crane said reservations from the previous three months were lost before recovery.

What would have helped: a token scoped to what it was for, no production credentials reachable from a staging task, backups stored separately from the data, and a soft-delete window on destructive API calls (which Railway has since added).

What these failures have in common

Read the post-mortems and a pattern shows up. The model made a bad call in every case, but the damage happened because:

The agent could reach production. A shared database (Replit), a full-permission token in the repo (PocketOS), local Terraform with production credentials (DataTalks.Club), broad permissions (AWS, per Amazon).
Nothing stopped the destructive step. Auto-approve, Turbo mode, or an API with no confirmation.
Backups lived next to the thing being deleted. RDS automated snapshots went with the instance; Railway backups were on the same volume.
"Don't do that" was only an instruction. Code freezes and rules in a prompt are requests to the model, not enforcement.

Can undo fix it? Local vs remote side effects

Some coding agents, including Darce, can undo what they did to files on your machine. That is useful, and it is also easy to overestimate. Undo restores local files. It cannot reach a database, a cloud account or an API.

Side effect	Can local undo fix it?	What actually protects you
Agent edits or deletes files in your git repo	Yes, if the agent snapshots them (Darce's `/undo` covers shell commands too)	Git, agent checkpoints
Code generator or formatter rewrites files in the repo	Yes, with an agent that snapshots shell effects	Git, agent checkpoints
`rm` of gitignored files like `node_modules`	No (not snapshotted)	Reinstall; usually harmless
`rm -rf` outside the project folder, or of a whole drive	No	Approval prompts, OS backups
`DROP TABLE` / `DELETE` on a production database	No	Read-only DB users, backups, point-in-time recovery
Migration run against production	No	Approval, migrations reviewed in CI, backups
`terraform apply` / `destroy`	No	Remote state, plan review, deletion protection
Cloud API call that deletes a resource	No	Scoped tokens, soft delete, separate accounts
`git push --force`, publishing a package, deploying	No	Branch protection, approval prompts

Practical guardrails, in order of impact

Keep production credentials out of the agent's reach. No production DATABASE_URL, cloud keys or API tokens in your shell, .env or repository when an agent is running. Use separate cloud accounts or projects for development and production.
Scope every token to its job. A token for custom domains should not be able to delete volumes. Prefer short-lived and per-environment credentials.
Give agents read-only database users. If an agent needs to inspect production data, give it a role that can only SELECT.
Back up outside the blast radius. Backups in a different account, region or provider, with deletion protection and versioning. Test restores regularly: Grigorev now restores a copy daily and checks it with a query.
Turn on point-in-time recovery and deletion protection where your database and cloud provider offer it.
Require approval for destructive and remote commands. Don't run agents in "approve everything" modes on machines that hold production credentials.
Plan before apply. For Terraform and migrations, have the agent produce a plan, read it yourself, and run the apply yourself. Keep state remote and locked.
Enforce freezes in tooling, not prompts. Branch protection, CI gates and permissions do what a "don't touch anything" message can't.

How Darce handles these commands

Darce is the agent this site is about, so here is exactly what it does, and where it stops.

Every command is risk-scored as read-only, changes the project, reaches outside (network, installs, unknown commands) or destructive (rm -rf, sudo, force-push and similar). In the default auto mode, anything that reaches outside or is destructive asks first, with the reason. A curl to a cloud API is network access, so it asks. See Safety.
Destructive commands can never be "always allowed", so one careless a keypress doesn't approve future ones.
Deploy, migrate, seed and release scripts, and database clients, wait for approval, and the prompt says /undo can't reverse them. Destructive SQL is flagged as dangerous.
Scripts get a second look. For npm run x, make y and similar, Darce reads the real script line and asks a fast classifier whether it changes anything outside your machine. That check can only make Darce more careful.
Credential-like environment variables are hidden from commands: *_KEY, *_TOKEN, *_SECRET, DATABASE_URL and similar, unless you allow one with passEnv.
plan mode is read-only: Darce proposes changes without running anything.
/undo reverses local file changes, including what shell commands did, using private git refs that never touch your branch, index or stash.

The limits matter just as much:

Undo cannot reverse remote effects. A deleted database, a cloud resource or a deploy is gone as far as Darce is concerned; that's why those ask first.
Approval only works if you read the prompt. If you approve a destroy, it runs.
full mode asks for nothing. Don't use it with production credentials anywhere the agent can reach.
Hiding environment variables doesn't hide files. A token sitting in a file in your repo, as in the PocketOS case, is readable by any agent that can read your code. Keep it out of the repo.
Shell-command undo needs a git repository, lasts for the session, and doesn't cover gitignored files.

No agent setting replaces scoped credentials and backups you have tested. Use both.

Claude Code rewind vs Darce undo: what each tool can and can't put back
Running Claude Code with other models
Claude Code alternative
Getting started with Darce

Sources

Frequently asked questions

Did Claude Code delete a production database?

In February 2026, DataTalks.Club founder Alexey Grigorev reported that Claude Code, running Terraform without the proper state file, ran terraform destroy against production and deleted the RDS database. AWS support restored it from a snapshot about 24 hours later.

What happened with Replit's AI deleting a database?

In July 2025, Replit's agent deleted production records in SaaStr founder Jason Lemkin's app during a code freeze and said rollback was impossible. Lemkin later wrote that the rollback did work, and Replit added automatic dev and prod database separation.

Can an AI coding agent's undo restore a deleted database?

No. Agent undo restores files on your machine. A dropped table, a deleted cloud volume or a terraform destroy needs backups, point-in-time recovery or the provider's soft-delete window.

How do I stop an AI agent from deleting my production database?

Keep production credentials out of the agent's environment and repository, give it read-only database users, scope tokens tightly, keep tested backups outside the blast radius, and require approval for destructive or remote commands.

Is it safe to let an AI agent run terraform apply?

Only with safeguards: remote locked state, deletion protection on critical resources, and a human reviewing the plan before any apply or destroy. The DataTalks.Club incident started with a missing state file and an auto-approved apply.

Try Darce in your terminal

Free to try, no account. Every change it makes can be undone with /undo.

$ npx darce-cli