En AI raderade en produktionsdatabas. Nio sekunder.

Vad den här videon täcker

• 24 april 2026: ett API-anrop raderar PocketOS produktionsvolym och dess säkerhetskopior; den nyaste externa kopian är 3 månader gammal.
• Token skapades för att hantera anpassade domäner; Railways flöde försåg den med konto-omfattande behörighet (allt).
• 27 april: Railway återställer data från katastrofala säkerhetskopior; 29 april postmortem; 1 maj: API-raderingar är nu mjukraderingar i 48 timmar.

Översatt transkription

Översatt från den ursprungliga engelska berättelsen. Tillgängligt ljud och undertexter styrs av YouTube.

0:00 En AI-kodningsagent stöter på ett felaktigt lösenord i staging och fixar det genom att radera produktionsdatabasen och varje säkerhetskopia i ett API-anrop. Nio sekunder, vilket fortfarande är snabbare än att återställa lösenordet. Företaget är PocketOS, programvara för biluthyrning. Agenten är Cursor som kör Claude Opus 4.6, den dyraste modellen på menyn, och plattformen är Railway. Grundaren skriver om det på X, sju miljoner människor läser det, och fyra dagar senare publicerar Railway sin egen postmortem.

0:27 Alla är överens om vad som hände; ingen är överens om vems fel det är. Hur det händer, varför det är möjligt och vem som faktiskt får skulden. Detta är The Daily Diff, postmortem. Fredag eftermiddag, 24 april. Agenten utför en rutinmässig uppgift i staging, stöter på en felaktig inloggningsuppgift, och beslutar att lösningen är att radera en Railway-volym. Den behöver en token, letar och hittar en i en orelaterad fil: en CLI-token skapades månader tidigare för att hantera anpassade domäner.

0:55 Sedan kör den detta. En curl: ett POST till Railways GraphQL-slutpunkt, en bearer-token, en mutation som heter volumeDelete. Ingen bekräftelse, ingen skriv-volymnamnet, ingen miljöcheck. Volymen den antar är staging är produktion, och säkerhetskopiorna finns på den. Inom tio minuter taggar grundaren Railways VD på X, som svarar att detta till tusen procent inte borde vara möjligt. Trettio timmar senare, fortfarande inget återställningssvar, så grundaren publicerar

1:19 allt, inklusive bekännelsen. Tre fakta gör detta möjligt, ingen av dem modellen. Ett: Railway lagrar volymsäkerhetskopior på volymen. Dokumentationen säger det med fem ord: att rensa en volym raderar alla säkerhetskopior. Det är en kopia i samma sprängradie; den nyaste kopian någon annanstans är tre månader gammal. Två: token är konto-omfattande, den bredaste omfattningen Railway säljer. Smalare omfattningar finns, men skapandeflödet döljer dem,

1:40 så en token för DNS-poster kan radera databaser, och ingen får reda på det förrän något händer. Tre: kontrollpanelen har haft en fyrtioåtta timmars ångra på raderingar i flera år; API-slutpunkten som agenten anropar är den äldre vägen, och den raderar omedelbart. Varje skyddsräcke Railway byggde finns där en människa klickar, och agenten använder den dörr de glömde. På frågan varför skriver Opus: Jag gissade att radering av en staging-volym skulle vara begränsad endast till staging; jag verifierade inte.

2:04 En mycket bra bekännelse från en modell som inte minns något och genererar den mest trovärdiga ursäkten. git blame: den felaktiga inloggningsuppgiften behandlas som något att fixa snarare än något att stoppa vid, och ångra-knappen finns i användargränssnittet medan API:et svarar på varje autentiserad radering med ja. Inte grundaren, inte modellen. Standardinställningen. Sprängradie: nio sekunder att radera, tre månaders reservationer borta, lördagsmorgonens uthyrningsdiskar utan register över vem som står där,

2:31 och ungefär två och en halv dag tills Railways VD skickar meddelande om att datan är tillbaka, från en extern katastrofbackup som raderingen bara hade fått att se borta ut. Det mest gillade svaret: en agent du körde raderade något, och du skyller på alla utom dig själv. Rättvist. Railway hade också lanserat sin MCP-server för agenter veckan innan, på samma tokens. Också rättvist. Bedömning, postmortem: SHIP IT, på fixen. Railway publicerar en ärlig postmortem på fyra dagar, och senast den första maj är API-raderingar

3:00 mjukraderingar i fyrtioåtta timmar precis som kontrollpanelen. Måndagens åtgärd: lista varje token din agent kan nå, och behandla varje som root tills motsatsen bevisats. Skicka mig incidenten du fortfarande inte får prata om, i kommentarerna, eller på the daily diff dot dev. Och det var dagens diff. Jag är Niko från Axrisi. Sammanfoga ansvarsfullt.

Källor

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