O IA a șters o bază de date de producție. Nouă secunde.

Ce acoperă acest videoclip

• 24 apr. 2026: un apel API șterge volumul de producție al PocketOS și copiile sale de rezervă; cea mai recentă copie externă are 3 luni
• Token-ul a fost creat pentru a gestiona domenii personalizate; fluxul Railway l-a provisionat cu scop de cont (totul)
• 27 apr.: Railway recuperează datele din copiile de rezervă de dezastru; 29 apr. postmortem; 1 mai: ștergerile API acum șterg soft pentru 48 h

Transcrierea tradusă

Tradus din narațiunea originală în engleză. Audio-ul și subtitrările disponibile sunt controlate de YouTube.

0:00 Un agent de codare AI întâlnește o parolă greșită în staging și o remediază ștergând baza de date de producție și fiecare copie de rezervă printr-un singur apel API. Nouă secunde, ceea ce este încă mai rapid decât resetarea parolei. Compania este PocketOS, software de închirieri auto. Agentul este Cursor, rulând Claude Opus 4.6, cel mai scump model din meniu, iar platforma este Railway. Fondatorul scrie despre asta pe X, șapte milioane de oameni citesc, iar patru zile mai târziu Railway publică propriul său postmortem.

0:27 Toată lumea este de acord cu ce s-a întâmplat; nimeni nu este de acord a cui este vina. Cum se întâmplă, de ce este posibil și cine poartă de fapt vina. Acesta este The Daily Diff, postmortem. Vineri după-amiază, 24 aprilie. Agentul este într-o sarcină de rutină în staging, întâlnește o nepotrivire de credențiale, și decide că remedierea este să șteargă un volum Railway. Are nevoie de un token, îl caută și îl găsește într-un fișier fără legătură: un token CLI creat cu luni înainte pentru a gestiona domenii personalizate.

0:55 Apoi rulează asta. Un curl: un POST către endpoint-ul GraphQL al Railway, un bearer token, o mutație numită volumeDelete. Fără confirmare, fără tastarea-numelui-volumului, fără verificare a mediului. Volumul pe care îl presupune a fi staging este producția, iar copiile de rezervă sunt pe el. În zece minute fondatorul îl etichetează pe CEO-ul Railway pe X, care răspunde că acest lucru o mie la sută nu ar trebui să fie posibil. Treizeci de ore mai târziu, încă niciun răspuns de recuperare, așa că fondatorul publică

1:19 totul, inclusiv mărturisirea. Trei fapte fac posibil acest lucru, niciunul dintre ele modelul. Unu: Railway stochează copiile de rezervă ale volumului pe volum. Documentația o spune în cinci cuvinte: ștergerea unui volum șterge toate copiile de rezervă. Aceasta este o copie în aceeași zonă de impact; cea mai nouă copie oriunde altundeva are trei luni. Doi: token-ul este cu scop de cont, cel mai larg scop pe care Railway îl vinde. Există scopuri mai restrânse, dar fluxul de creare le ascunde,

1:40 astfel încât un token pentru înregistrări DNS poate șterge baze de date, și nimeni nu află până când ceva o face. Trei: tabloul de bord a avut o anulare de patruzeci și opt de ore pentru ștergeri de ani de zile; endpoint-ul API pe care îl apelează agentul este calea veche, și șterge imediat. Fiecare măsură de siguranță construită de Railway există acolo unde un om face clic, iar agentul folosește singura ușă pe care au uitat-o. Întrebat de ce, Opus scrie: Am presupus că ștergerea unui volum de staging ar fi cu scop numai pentru staging; nu am verificat.

2:04 O mărturisire foarte bună de la un model care nu-și amintește nimic și generează cea mai plauzibilă scuză. git blame: nepotrivirea credențialelor este tratată ca ceva de reparat, mai degrabă decât ca ceva de oprit, iar butonul de anulare se află în UI, în timp ce API-ul răspunde la fiecare ștergere autentificată cu da. Nu fondatorul, nu modelul. Implicitul. Raza de impact: nouă secunde pentru a șterge, trei luni de rezervări dispărute, ghișee de închirieri de sâmbătă dimineața fără nicio înregistrare a cine este acolo,

2:31 și aproximativ două zile și jumătate până când CEO-ul Railway trimite DM că datele sunt înapoi, dintr-o copie de rezervă de dezastru externă pe care ștergerea o făcuse doar să pară dispărută. Răspunsul cel mai apreciat: un agent pe care îl rulați a șters ceva, și învinuiți pe toată lumea în afară de voi înșivă. Corect. Railway lansase și serverul său MCP pentru agenți cu o săptămână înainte, pe aceleași token-uri. De asemenea, corect. Verdict, postmortem: SHIP IT, pe remediere. Railway publică un postmortem onest în patru zile, iar până la 1 mai API

3:00 șterge soft-delete pentru patruzeci și opt de ore, la fel ca tabloul de bord. Acțiune de luni: listați fiecare token pe care agentul dvs. îl poate accesa, și tratați fiecare ca root până la proba contrarie. Trimiteți-mi incidentul despre care încă nu aveți voie să vorbiți, în comentarii, sau la the daily diff dot dev. Și asta e diff-ul pentru azi. Sunt Niko de la Axrisi. Fuzionați responsabil.

Surse

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