AI smazala produkční databázi. Devět sekund.

Co toto video pokrývá

• 24. dubna 2026: jedno volání API smaže produkční svazek PocketOS a jeho zálohy; nejnovější externí kopie je stará 3 měsíce
• Token byl vytvořen pro správu vlastních domén; tok Railway jej přidělil s rozsahem pro účet (vše)
• 27. dubna: Railway obnoví data ze záloh pro případ katastrofy; 29. dubna postmortem; 1. května: smazání přes API nyní funguje jako soft-delete po dobu 48 h

Přeložený přepis

Přeloženo z původního anglického vyprávění. Dostupné audio a titulky jsou řízeny YouTube.

0:00 AI kódovací agent narazí na špatné heslo v stagingu a opraví to smazáním produkční databáze a všech záloh jedním voláním API. Devět sekund, což je stále rychlejší než reset hesla. Společnost je PocketOS, software pro půjčování aut. Agent je Cursor běžící na Claude Opus 4.6, nejdražším modelu na trhu, a platforma je Railway. Zakladatel to sepíše na X, sedm milionů lidí to přečte, a o čtyři dny později Railway zveřejní vlastní postmortem.

0:27 Všichni se shodnou na tom, co se stalo; nikdo se neshodne na tom, čí je to chyba. Jak se to stane, proč je to možné a kdo skutečně nese vinu. Toto je The Daily Diff, postmortem. Páteční odpoledne, 24. dubna. Agent plní rutinní úkol v stagingu, narazí na neshodu přihlašovacích údajů, a rozhodne se, že řešením je smazání svazku Railway. Potřebuje token, hledá a najde ho v nesouvisejícím souboru: CLI token vytvořený měsíce dříve pro správu vlastních domén.

0:55 Poté spustí toto. Jeden curl: POST na GraphQL endpoint Railway, bearer token, mutace zvaná volumeDelete. Žádné potvrzení, žádné zadání názvu svazku, žádná kontrola prostředí. Svazek, který předpokládá, že je staging, je produkční, a zálohy jsou na něm. Během deseti minut zakladatel označí CEO Railway na X, který odpoví, že toto by na tisíc procent nemělo být možné. O třicet hodin později stále žádná odpověď na obnovu, takže zakladatel zveřejní

1:19 všechno, včetně přiznání. Tři fakta to umožňují, žádné z nich není model. Jedna: Railway ukládá zálohy svazků na svazek. Dokumentace to říká pěti slovy: smazání svazku smaže všechny zálohy. To je kopie ve stejném poloměru výbuchu; nejnovější kopie kdekoli jinde je stará tři měsíce. Dva: token je s rozsahem pro účet, nejširší rozsah, který Railway prodává. Existují užší rozsahy, ale proces vytváření je skrývá,

1:40 takže token pro DNS záznamy může smazat databáze, a nikdo to nezjistí, dokud se něco nestane. Tři: dashboard má po léta 48hodinovou možnost vrácení smazání zpět; API endpoint, který agent volá, je starší cesta, a maže okamžitě. Každá zábrana, kterou Railway postavilo, žije tam, kde kliká člověk, a agent používá jediné dveře, na které zapomněli. Na otázku proč, Opus píše: Hádal jsem, že smazání stagingového svazku bude v rozsahu pouze pro staging; neověřoval jsem to.

2:04 Velmi dobré přiznání od modelu, který si nic nepamatuje a generuje tu nejpřesvědčivější omluvu. git blame: neshoda přihlašovacích údajů je považována za něco k opravě spíše než za něco, u čeho se zastavit, a tlačítko zpět žije v uživatelském rozhraní, zatímco API odpovídá na každé ověřené smazání ano. Není to zakladatel, není to model. Výchozí stav. Poloměr výbuchu: devět sekund ke smazání, tři měsíce rezervací pryč, sobotní ráno u pultů půjčoven bez záznamu o tom, kdo tam stojí,

2:31 a zhruba dva a půl dne, než CEO Railway v DM napíše, že data jsou zpět, z externí zálohy pro případ katastrofy, kterou smazání jen vypadalo, že zmizelo. Nejlíbivější odpověď: agent, kterého jsi spustil, něco smazal, a ty viníš všechny kromě sebe. Férové. Railway také spustilo svůj MCP server pro agenty týden předtím, se stejnými tokeny. Také férové. Verdikt, postmortem: ship it, na opravu. Railway zveřejní upřímný postmortem za čtyři dny, a do prvního května smazání přes API

3:00 funguje jako soft-delete po dobu čtyřiceti osmi hodin jako dashboard. Pondělní akce: seznam všech tokenů, ke kterým má váš agent přístup, a zacházejte s každým jako s rootem, dokud se neprokáže opak. Pošlete mi incident, o kterém stále nemůžete mluvit, v komentářích, nebo na the daily diff dot dev. A to je dnešní diff. Jsem Niko z Axrisi. Spojujte zodpovědně.

Zdroje

1. Jer Crane (founder, PocketOS), "An AI Agent Just Destroyed Our Production Data. It Confessed in Writing."x.com
2. Railway, "Your AI wants to nuke your database. Guardrails fix that." (Apr 29, 2026)blog.railway.com
3. Railway changelog #0288, "Undoable volume deletes" (May 1, 2026)railway.com
4. Railway docs, Backups ("Wiping a volume deletes all backups.")docs.railway.com
5. Jake Cooper (Railway CEO), "The AI Engineer: A New Breed"x.com
6. Recovery confirmedx.com
7. Hacker News (860 points, 1,032 comments)news.ycombinator.com
8. The Registerwww.theregister.com
9. The New Stackthenewstack.io