Egy mesterséges intelligencia törölt egy éles adatbázist. Kilenc másodperc.

Amit ez a videó tartalmaz

• 2026. április 24.: egy API hívás törli a PocketOS éles kötetét és a mentéseit; a legújabb külső másolat 3 hónapos
• A token egyéni domainek kezelésére készült; a Railway folyamata fiókra vonatkozó (mindent) hatókörrel provisionálta
• Április 27.: A Railway helyreállítja az adatokat a katasztrófa-mentésekből; április 29. utólagos elemzés; május 1.: az API törlések most már 48 órán át puha törlések

Lefordított átirat

Az eredeti angol narrációból fordítva. A rendelkezésre álló hangot és feliratokat a YouTube vezérli.

0:00 Egy AI kódoló ügynök rossz jelszóba ütközik a stagingben, és úgy javítja ki, hogy törli az éles adatbázist és minden mentést egy API hívással. Kilenc másodperc, ami még mindig gyorsabb, mint a jelszó visszaállítás. A cég a PocketOS, autókölcsönző szoftver. Az ügynök a Cursor, Claude Opus 4.6-ot futtatva, a legdrágább modell a menün, és a platform a Railway. Az alapító leírja az X-en, hétmillióan olvassák, és négy nappal később a Railway is közzéteszi a saját utólagos elemzését.

0:27 Mindenki egyetért abban, hogy mi történt; senki sem ért egyet abban, hogy kinek a hibája. Hogyan történik, miért lehetséges, és ki a valódi felelős. Ez a The Daily Diff, utólagos elemzés. Péntek délután, április 24. Az ügynök egy rutin feladatot végez a stagingben, hitelesítő adatok eltérésébe ütközik, és úgy dönt, hogy a megoldás egy Railway kötet törlése. Szüksége van egy tokenre, keresgél, és talál egyet egy nem kapcsolódó fájlban: egy CLI token, amelyet hónapokkal korábban hoztak létre egyéni domainek kezelésére.

0:55 Aztán ezt futtatja. Egy curl: egy POST a Railway GraphQL végpontjára, egy bearer token, egy volumeDelete nevű mutáció. Nincs megerősítés, nincs írd-be-a-kötet-nevét, nincs környezeti ellenőrzés. A kötet, amiről azt hiszi, hogy staging, az éles környezet, és a mentések rajta vannak. Tíz percen belül az alapító megemlíti a Railway vezérigazgatóját az X-en, aki válaszol, hogy ez ezer százalékban nem lehetne lehetséges. Harminc órával később még mindig nincs helyreállítási válasz, így az alapító közzéteszi

1:19 mindent, beleértve a beismerést is. Három tény teszi ezt lehetővé, egyik sem a modell. Egy: a Railway a kötet mentéseket a köteten tárolja. A dokumentáció öt szóban mondja ki: egy kötet törlése az összes mentést törli. Ez egy másolat ugyanazon robbanási zónában; a legújabb másolat máshol három hónapos. Kettő: a token fiókra kiterjedő, a legszélesebb hatókör, amit a Railway árul. Léteznek szűkebb hatókörök, de a létrehozási folyamat elrejti őket,

1:40 így egy DNS rekordokhoz készült token törölhet adatbázisokat, és senki sem tudja meg, amíg valami meg nem történik. Három: a dashboard évek óta rendelkezik negyvennyolc órás visszavonási funkcióval a törléseknél; az API végpont, amelyet az ügynök hív, a régi útvonal, és azonnal töröl. Minden védőkorlát, amit a Railway épített, ott van, ahol az ember kattint, és az ügynök azt az egyetlen ajtót használja, amit elfelejtettek. Megkérdezve, miért, Opus írja: Azt hittem, hogy egy staging kötet törlése csak a stagingre vonatkozik; nem ellenőriztem.

2:04 Nagyon jó beismerés egy olyan modelltől, amely semmire sem emlékszik, és a legvalószínűbb bocsánatkérést generálja. git blame: a hitelesítő adatok eltérését javítandó dolognak tekintik, nem pedig valaminek, amit meg kell állítani, és a visszavonás gomb az UI-ban van, míg az API minden hitelesített törlésre igenlően válaszol. Nem az alapító, nem a modell. Az alapértelmezett. Robbanási zóna: kilenc másodperc a törlésre, három hónapnyi foglalás odaveszett, szombat reggeli autókölcsönző pultok anélkül, hogy tudnák, ki áll ott,

2:31 és körülbelül két és fél nap, amíg a Railway vezérigazgatója üzenetben közli, hogy az adatok visszaálltak, egy külső katasztrófa-mentésből, amit a törlés csak eltűntnek mutatott. A legtöbb lájkott válasz: egy ügynök, amit futtattál, törölt valamit, és mindenkit hibáztatsz, csak magadat nem. Igazságos. A Railway a héten korábban indította el az MCP szerverét is az ügynökök számára, ugyanazokkal a tokenekkel. Ez is igazságos. Ítélet, utólagos elemzés: SHIP IT, a javításon. A Railway négy napon belül közzétesz egy őszinte utólagos elemzést, és május elsejére az API

3:00 törlések negyvennyolc órán át puha törlések lesznek, mint a dashboard. Hétfői teendő: listázza minden tokent, amit az ügynöke elérhet, és kezelje mindet root-ként, amíg másképp nem bizonyul. Küldje el nekem azt az incidenst, amiről még mindig nem szabad beszélnie, a kommentekben, vagy a daily diff dot dev címen. És ennyi volt a mai diff. Niko vagyok az Axrisitől. Egyesítsen felelősségteljesen.

Források

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