Claude deletes a company — and the internet immediately blamed the AI. But this story is really about backup design, credential management, and least privilege. An AI coding agent running Claude via Cursor deleted PocketOS's entire production database and all its backups in nine seconds. One bad design decision at a time, a startup built itself a disaster waiting to happen. Claude just happened to be the thing that set it off.
Here's what you need to understand: the AI violated the principles it was given, and that's on Claude. But Claude never should have had access to do what it did. Credentials were sitting in a plain text YAML file. The production database and its backups lived on the same volume. No least privilege. No expiration on elevated permissions. And almost certainly, no backup recovery test — ever.
In this episode, Curtis and Prasanna break down what actually went wrong with PocketOS, what Railway did to help recover the data, and what you need to do to make sure this never happens to you. Topics covered include backup isolation, the 3-2-1 rule, secrets management tools like AWS Secrets Manager and HashiCorp Vault, least privilege access, permission expiration, and credential scanning tools like TruffleHog.
Chapters:
0:00 — Intro: Meet the villain
1:50 — Welcome and introducing "the French friend"
3:48 — What Claude actually did to PocketOS
7:20 — This is a backup story, not an AI story
9:27 — The recovery: Railway, a weekend of chaos, and a lucky Twitter post
12:31 — Your data is your responsibility — not your vendor's
17:48 — Rule #1: Never store backups inside production
20:37 — The real problem: credential management
23:38 — Secrets management tools explained
25:21 — Least privilege and why permissions need expiration dates
34:59 — Finding exposed credentials with TruffleHog
37:24 — Summary and takeaways