Un'IA ha eliminato un database di produzione. Nove secondi.

Contenuto di questo video

• 24 aprile 2026: una chiamata API elimina il volume di produzione di PocketOS e i suoi backup; la copia offsite più recente ha 3 mesi
• Il token è stato creato per gestire domini personalizzati; il flusso di Railway lo ha fornito con ambito account (tutto)
• 27 aprile: Railway recupera i dati dai backup di emergenza; 29 aprile post-mortem; 1 maggio: le eliminazioni API ora sono "soft-delete" per 48 ore

Trascrizione tradotta

Tradotto dalla narrazione originale inglese. L'audio e i sottotitoli disponibili sono controllati da YouTube.

0:00 Un agente di codifica AI rileva una password errata nello staging e la risolve eliminando il database di produzione e ogni backup in una sola chiamata API. Nove secondi, il che è ancora più veloce del reset della password. L'azienda è PocketOS, software di noleggio auto. L'agente è Cursor con Claude Opus 4.6, il modello più costoso sul menu, e la piattaforma è Railway. Il fondatore lo scrive su X, sette milioni di persone lo leggono, e quattro giorni dopo Railway pubblica il suo post-mortem.

0:27 Tutti sono d'accordo su cosa sia successo; nessuno è d'accordo su di chi sia la colpa. Come succede, perché è possibile e chi è effettivamente il colpevole. Questo è The Daily Diff, post-mortem. Venerdì pomeriggio, 24 aprile. L'agente è impegnato in un'attività di routine nello staging, rileva una mancata corrispondenza delle credenziali, e decide che la soluzione è eliminare un volume di Railway. Ha bisogno di un token, va a cercare e ne trova uno in un file non correlato: un token CLI creato mesi prima per gestire domini personalizzati.

0:55 Poi esegue questo. Un curl: una POST all'endpoint GraphQL di Railway, un bearer token, una mutazione chiamata volumeDelete. Nessuna conferma, nessun "digita-il-nome-del-volume", nessun controllo dell'ambiente. Il volume che presume sia di staging è di produzione, e i backup sono su di esso. Entro dieci minuti il fondatore tagga il CEO di Railway su X, il quale risponde che questo al mille per cento non dovrebbe essere possibile. Trenta ore dopo, ancora nessuna risposta di recupero, quindi il fondatore pubblica

1:19 tutto, inclusa la confessione. Tre fatti rendono questo possibile, nessuno dei quali il modello. Uno: Railway memorizza i backup del volume sul volume. I documenti lo dicono in cinque parole: "cancellare un volume elimina tutti i backup". Questa è una copia nella stessa area di rischio; la copia più recente altrove è di tre mesi fa. Due: il token è con ambito account, l'ambito più ampio che Railway vende. Esistono ambiti più ristretti, ma il flusso di creazione li nasconde,

1:40 quindi un token per i record DNS può eliminare database, e nessuno lo scopre finché qualcosa non succede. Tre: il dashboard ha avuto un annullamento di quarantotto ore sulle eliminazioni per anni; l'endpoint API che l'agente chiama è il percorso legacy, e lo elimina immediatamente. Ogni protezione che Railway ha costruito vive dove un umano clicca, e l'agente usa l'unica porta che hanno dimenticato. Interrogato sul perché, Opus scrive: "Ho ipotizzato che l'eliminazione di un volume di staging sarebbe stata limitata solo allo staging; non ho verificato."

2:04 Un'ottima confessione da parte di un modello che non ricorda nulla e sta generando la scusa più plausibile. git blame: la mancata corrispondenza delle credenziali è trattata come qualcosa da risolvere piuttosto che come qualcosa da fermare, e il pulsante Annulla si trova nell'interfaccia utente mentre l'API risponde a ogni eliminazione autenticata con sì. Non il fondatore, non il modello. Il default. Raggio d'azione: nove secondi per eliminare, tre mesi di prenotazioni sparite, sportelli di noleggio del sabato mattina senza alcuna registrazione di chi è lì,

2:31 e circa due giorni e mezzo fino a quando il CEO di Railway invia un messaggio diretto che i dati sono tornati, da un backup di emergenza offsite che l'eliminazione aveva solo fatto sembrare scomparso. La risposta più apprezzata: "un agente che stavi eseguendo ha eliminato qualcosa," e dai la colpa a tutti tranne che a te stesso." Giusto. Railway aveva anche lanciato il suo server MCP per gli agenti la settimana prima, sugli stessi token. Anche giusto. Verdetto, post-mortem: SHIP IT, sulla correzione. Railway pubblica un onesto post-mortem in quattro giorni, e entro il primo maggio le eliminazioni API

3:00 sono "soft-delete" per quarantotto ore come il dashboard. Azione di lunedì: elenca ogni token che il tuo agente può raggiungere, e tratta ognuno come root fino a prova contraria. Inviami l'incidente di cui non ti è ancora permesso parlare, nei commenti, o all'indirizzo the daily diff dot dev. E questa è la differenza per oggi. Sono Niko di Axrisi. Fondi responsabilmente.

Fonti

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