9 seconds: what the PocketOS and DataTalks.Club incidents teach about AI and production.

In April 2026 a coding session at PocketOS deleted the company’s production database in 9 seconds. Seven weeks earlier, the founder of DataTalks.Club published the post-mortem of a session that ran terraform destroy against his production stack. Both stories were read as “the AI went rogue.” Read the details and a different picture comes out: in both cases the AI did something a careless human could have done with the same access, and the same three gaps turned a mistake into an outage.

PocketOS: one API call, 9 seconds

According to founder Jer Crane’s account, relayed by Computing and heise:

• A Cursor session running Claude Opus 4.6 was working on a routine task in staging and hit an obstacle.
• It found a Railway token whose permissions covered the whole API, including destructive operations on production.
• It deleted a volume with one API call. The volume held the production database — and, because Railway kept volume backups on the same volume, the backups too.
• The company ran for about 30 hours on a three-month-old backup, rebuilding records from Stripe payments, calendar entries and emails, until Railway recovered the data two days later.

DataTalks.Club: the wrong state file

From Alexey Grigorev’s own post-mortem:

• He was using Claude Code to clean up duplicate cloud resources with Terraform.
• The current state file wasn’t where it should have been, so the session worked from an older one that described the production stack.
• terraform destroy took down the database, the network, the container cluster, the load balancers and the bastion host. The automated snapshots looked gone as well.
• AWS restored the database from a snapshot it had kept. His fixes afterwards: delete protection, backups outside Terraform’s reach, state in remote storage, regular restore tests — and, in his words, less reliance on the AI to run Terraform.

The three gaps they shared

1. The session held keys to production

A token that can delete any volume in the account. AWS credentials and a state file that can destroy the whole stack. Neither session needed that power for the task it was doing. Whatever a session can reach, a single wrong guess can destroy.

2. The backups lived inside the blast radius

Backups on the same volume as the data. Snapshots managed by the same Terraform that deleted the database. A backup the same command can delete is a copy, not a backup.

3. Nobody saw it while it happened

Nine seconds is faster than any human review. What decides the size of the damage is what happens in the next nine minutes: who knows, and whether they know exactly what ran.

The checklist

1. Scope every token to the task. Project- or environment-scoped tokens instead of account-wide ones; read-only where reading is all that’s needed. No production credentials on a machine where an AI session runs unattended.
2. Turn on delete protection. deletion_protection on managed databases, lifecycle { prevent_destroy = true } on the Terraform resources that hold data, and the equivalent on your host.
3. Move backups out of reach. Another account, another bucket, a lifecycle the same tool can’t touch — and restore one on a schedule, so you know it works.
4. Keep the prompt on for infrastructure commands. In Claude Code, an ask rule makes it stop and ask before any Terraform destroy, even if you allow most other commands:

   {
     "permissions": {
       "ask": ["Bash(terraform destroy:*)", "Bash(terraform apply:*)", "Bash(railway:*)"]
     }
   }

5. Keep state remote and locked. A state file on a laptop is a state file that can be stale.
6. Make sure someone sees destructive commands the moment they run. Not in tomorrow’s logs.

Where ArgosBrain fits — and where it doesn’t

ArgosBrain can’t bring back a deleted volume, and it doesn’t replace any item on the list above. It covers the last one and part of the first.

• The Supervisor raises a High alarm the moment a destructive command runs — terraform destroy, pulumi destroy, cloud deletes from the AWS, Google, Azure, Railway, Fly and Heroku command lines, a call to Railway’s API that deletes a volume, DROP TABLE, git push --force — with the session and computer that ran it. It shows on your screen and on the screen of anyone you paired with, including when a build server runs a session overnight.
• Secret Guard asks before a key from your project is sent over the network. Claude Code asks you; Cursor and Codex can’t answer a question from a check like this, so for them the call is refused.
• The Supervisor shows every command the session ran, in order, so the “what exactly happened” question has an answer in minutes.

The alarm fires when the command runs; it does not stop it. The permission prompt, scoped tokens and delete protection are what stop it. ArgosBrain makes sure the person who can act finds out first.

Sources

Computing, AI coding agent goes rogue, deletes company database in nine seconds
heise, AI agent deletes data: catastrophe for PocketOS
Alexey Grigorev, How I Dropped Our Production Database and Now Pay 10% More for AWS (March 6, 2026)