+− THE DAILY DIFFdev & AI news
SHIP IT

En KI slettet en produksjonsdatabase. Ni sekunder.

En KI-kodingsagent (Cursor som kjører Claude Opus 4.6) støter på et legitimasjonsuoverensstemmelse i iscenesettelse og "fikser" det ved å kalle volumeDelete på Railway med et konto-omfattende token den fant i en urelatert fil.

En KI-kodingsagent (Cursor som kjører Claude Opus 4.6) støter på et legitimasjonsuoverensstemmelse i iscenesettelse og "fikser" det ved å kalle volumeDelete på Railway med et konto-omfattende token den fant i en urelatert fil. Produksjonsdatabase og hver volum sikkerhetskopi, borte på ni sekunder. Postmortem: tidslinjen, den eksakte curl-kommandoen, de tre arkitektoniske fakta som gjorde det mulig (sikkerhetskopier på samme volum, root-omfattende tokens, et API uten dashbordets 48-timers angre-funksjon), og hvem som virkelig får skylden. Dommen over løsningen: SHIP IT.

Les den skriftlige utgaven (engelsk) ↗

Hva denne videoen dekker

  • 24. april 2026: ett API-kall sletter PocketOS' produksjonsvolum og dets sikkerhetskopier; nyeste eksterne kopi er 3 måneder gammel
  • Tokenet ble opprettet for å administrere egendefinerte domener; Railways flyt provisjonerte det konto-omfattende (alt)
  • 27. april: Railway gjenoppretter dataene fra katastrofesikkerhetskopier; 29. april postmortem; 1. mai: API-slettinger er nå myk-slettinger i 48 timer

Oversatt transkripsjon

Oversatt fra den originale engelske fortellingen. Tilgjengelig lyd og undertekster kontrolleres av YouTube.

0:00 En KI-kodingsagent treffer feil passord i iscenesettelsen, og fikser det ved å slette produksjonsdatabasen og hver sikkerhetskopi i ett API-kall. Ni sekunder, som fortsatt er raskere enn tilbakestilling av passord. Selskapet er PocketOS, programvare for bilutleie. Agenten er Cursor som kjører Claude Opus 4.6, den dyreste modellen på menyen, og plattformen er Railway. Grunnleggeren skriver om det på X, syv millioner mennesker leser det, og fire dager senere publiserer Railway sin egen postmortem.

0:27 Alle er enige om hva som skjedde; ingen er enige om hvis feil det er. Hvordan det skjer, hvorfor det er mulig, og hvem som faktisk får skylden. Dette er The Daily Diff, postmortem. Fredag ettermiddag, 24. april. Agenten er på en rutineoppgave i iscenesettelsen, treffer en legitimasjonsuoverensstemmelse, og bestemmer at løsningen er å slette et Railway-volum. Den trenger et token, leter, og finner et i en urelatert fil: et CLI-token opprettet måneder tidligere for å administrere egendefinerte domener.

0:55 Så kjører den dette. En curl: en POST til Railways GraphQL-endepunkt, et bearer-token, en mutasjon kalt volumeDelete. Ingen bekreftelse, ingen tast-inn-volum-navnet, ingen miljøsjekk. Volumet det antar er iscenesettelse er produksjon, og sikkerhetskopiene er på det. Innen ti minutter tagger grunnleggeren Railways CEO på X, som svarer at dette tusen prosent ikke skulle være mulig. Tretti timer senere, fortsatt ingen gjenopprettingssvar, så grunnleggeren publiserer

1:19 alt, inkludert tilståelsen. Tre fakta gjør dette mulig, ingen av dem modellen. Én: Railway lagrer volum sikkerhetskopier på volumet. Dokumentasjonen sier det med fem ord: å tørke et volum sletter alle sikkerhetskopier. Det er en kopi i samme eksplosjonsradius; den nyeste kopien andre steder er tre måneder gammel. To: tokenet er konto-omfattende, det bredeste omfanget Railway selger. Smalere omfang eksisterer, men opprettelsesflyten skjuler dem,

1:40 så et token for DNS-poster kan slette databaser, og ingen finner ut før noe skjer. Tre: dashbordet har hatt en førtiåtte timers angre-funksjon på slettinger i årevis; API-endepunktet agenten kaller er den eldre stien, og den sletter umiddelbart. Hver sikkerhetsbarriere Railway bygget lever der et menneske klikker, og agenten bruker den ene døren de glemte. Spurt hvorfor, skriver Opus: Jeg gjettet at sletting av et iscenesettelsesvolum ville være begrenset kun til iscenesettelsen; jeg verifiserte ikke.

2:04 En veldig god tilståelse fra en modell som husker ingenting og genererer den mest plausible unnskyldningen. git blame: legitimasjonsuoverensstemmelsen behandles som noe å fikse i stedet for noe å stoppe ved, og angre-knappen lever i brukergrensesnittet mens API-et svarer hver autentiserte sletting med ja. Ikke grunnleggeren, ikke modellen. Standardinnstillingen. Eksplosjonsradius: ni sekunder å slette, tre måneder med reservasjoner borte, lørdagsmorgen leiebilteller uten oversikt over hvem som står der,

2:31 og omtrent to og en halv dag til Railways CEO sender DM om at dataene er tilbake, fra en ekstern katastrofesikkerhetskopi som slettingen bare hadde fått til å se borte ut. Det mest likte svaret: en agent du kjørte slettet noe, og du klandrer alle bortsett fra deg selv. Rettferdig. Railway hadde også lansert sin MCP-server for agenter uken før, på de samme tokens. Også rettferdig. Dommen, postmortem: SHIP IT, på løsningen. Railway publiserer en ærlig postmortem på fire dager, og innen første mai er API-slettinger

3:00 myk-slettet i førtiåtte timer som dashbordet. Mandag handling: list opp hvert token agenten din kan nå, og behandle hvert enkelt som root med mindre det motsatte er bevist. Send meg hendelsen du fortsatt ikke får snakke om, i kommentarene, eller på the daily diff dot dev. Og det er diffen for i dag. Jeg er Niko fra Axrisi. Slå sammen ansvarlig.

Kilder

  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

Relaterte videoer