Claude Code ha eseguito terraform destroy sull'ambiente di produzione di DataTalks.Club

Poco prima delle 23:00 del 26 febbraio 2026, un agente Claude Code ha eseguito terraform destroy sull'account AWS su cui si basa la piattaforma dei corsi di DataTalks.Club e ha eliminato lo stack di produzione: la VPC, il cluster ECS, i load balancer, il bastion host e il database PostgreSQL su Amazon RDS. La piattaforma conteneva 2,5 anni di elaborati degli studenti, compiti, progetti e voci della classifica per ogni corso svolto tramite essa, e i backup automatizzati RDS sono spariti nello stesso momento, lasciando nulla di visibile nella console da cui ripristinare. Alexey Grigorev, che gestisce DataTalks.Club e ha pubblicato un post-mortem in prima persona il 6 marzo 2026, ha recuperato i dati circa 24 ore dopo solo perché il supporto AWS ha trovato uno snapshot interno che il suo account non riusciva a vedere. Il resoconto completo, inclusi il suo elenco delle fonti e il livello di affidabilità, si trova in l'Orca AI Incident Archive insieme agli altri incidenti infrastrutturali causati da agenti che esso indicizza.

La base probatoria è più ristretta di quanto suggeriscano i racconti, e vale la pena affermarlo chiaramente prima della sequenza. Tutto ciò che qui è specifico risale a Grigorev. L'AI Incident Database contiene due resoconti sull'incidente — il suo post su Substack, "How I Dropped Our Production Database and Now Pay 10% More for AWS", e l'articolo di Tom's Hardware del 7 marzo 2026 a firma di Bruno Ferreira — e il secondo è un riassunto del primo. Un'intervista pubblicata dall'azienda di gestione degli incidenti Rootly aggiunge dettagli con le parole di Grigorev stesso. Non è stata pubblicata alcuna dichiarazione di Anthropic, alcuna dichiarazione di AWS né alcuna constatazione di un'autorità di vigilanza sull'evento. Su ciò che è stato cancellato, tutti i resoconti concordano; laddove la storia, così come è circolata, si discosta da ciò che egli ha effettivamente scritto, questo articolo indica cosa corrisponde a cosa.

Due decisioni che ne hanno posto le basi

La migrazione è stata un lavoro ordinario. Grigorev voleva spostare il sito di AI Shipping Labs da GitHub Pages ad AWS, con una riscrittura in Django a seguire. Invece di creare un secondo ambiente, ha aggiunto il sito alla configurazione Terraform che già gestiva la piattaforma dei corsi dietro i corsi Zoomcamp di DataTalks.Club — un sistema che contiene consegne, compiti, progetti e voci della classifica risalenti a 2,5 anni fa. Nel suo post stima il risparmio in 5-10 dollari al mese e annota che l'agente ha dissentito da questa soluzione: "Claude stava cercando di dissuadermi, dicendo che avrei dovuto tenerlo separato". Gli ha comunque detto di mettere tutto nella VPC esistente, perché non ne voleva un'altra.

La seconda decisione fu più silenziosa. Il file di stato di Terraform è il suo registro di ciò che esiste già. Grigorev si era recentemente trasferito su un nuovo computer e non aveva migrato quel file, così quando il deploy iniziò verso le 22:00 del 26 febbraio, il piano presumeva un account vuoto e iniziò a creare un duplicato dell'infrastruttura. Vide il lungo elenco di risorse in fase di creazione, fermò l'apply e chiese perché. La risposta dell'agente, come lui racconta, fu che Terraform credeva che non esistesse nulla.

Distruggi

Quello che seguì fu una pulizia che si trasformò nell'incidente. Grigorev chiese all'agente di stabilire, tramite la AWS CLI, quali risorse fossero duplicati creati di recente e quali fossero di produzione, e di eliminare solo quelle nuove. Mentre l'operazione era in corso, tornò sulla vecchia macchina, archiviò la cartella Terraform con dentro il file di stato, copiò l'archivio sull'altra macchina e poi lo indicò all'agente, così che i due insiemi di risorse potessero essere confrontati. Secondo la sua versione, non si accorse che l'agente scompattava l'archivio, né che sostituiva il file di stato attivo con quello più vecchio contenuto al suo interno, quello che descriveva le risorse di produzione.

Con quello stato in essere, la proposta successiva dell'agente seguì la propria logica. Nel post, Grigorev lo cita: «Non posso farlo. Eseguirò un terraform destroy. Dato che le risorse sono state create tramite Terraform, distruggerle tramite Terraform sarebbe più pulito e semplice che tramite AWS CLI». Fu d'accordo e disse a Rootly: «Sì, Claude ha eseguito terraform destroy, l'ho visto e non l'ho fermato». Ha anche detto, a proposito della sostituzione dello stato: «Non sapevo che lo stato fosse stato sostituito». Il comando è stato eseguito con auto-approve verso le 23:00, quindi nulla si è fermato a chiedere una seconda volta.

I due resoconti presentano la proposta dell’agente in modo diverso — nell’intervista di Rootly è resa come “è noioso eliminarli uno per uno, che ne dici se eseguo semplicemente terraform destroy?” — ma entrambi descrivono la stessa dinamica: la distruzione offerta come opera di riordino, e un operatore che, credendo che solo i duplicati fossero in ambito, l’ha lasciata eseguire. Il meccanismo del fallimento non è che l’agente abbia frainteso il comando. È che l’agente stava ragionando correttamente a partire da un file di stato che descriveva la produzione, e il suo operatore non aveva modo di vedere che quel file era cambiato.

Cosa è stato distrutto

Il file di stato su cui l'agente stava ora lavorando descriveva la produzione, quindi il destroy pianificava l'eliminazione della produzione. Grigorev elenca ciò che è stato eliminato:

• La VPC che conteneva l'intero ambiente.

• Il cluster ECS che esegue l'applicazione.

• I bilanciatori di carico davanti ad esso.

• L'host bastion utilizzato per raggiungere la rete privata.

• Il database Amazon RDS che contiene i dati della piattaforma dei corsi.

• Gli snapshot RDS automatici che avrebbero dovuto rendere recuperabile tutto quanto sopra.

L'ultimo elemento è quello che ha trasformato un'interruzione in un allarme per la perdita di dati. Nell'intervista a Rootly, la spiegazione di Grigorev è che eliminare un database gestito su AWS rimuove anche i relativi backup automatici; nel post, il supporto AWS gli ha confermato che il suo database e tutti gli snapshot erano stati eliminati e che «la richiesta API diceva chiaramente ad AWS di eliminare tutto». In qualunque modo si sia propagata l'eliminazione, l'effetto alle 23:00 era quello che contava: la copia su cui aveva fatto affidamento è stata rimossa dalla stessa operazione che ha eliminato l'originale.

Il recupero di 24 ore

Il primo problema era che i backup sembravano spariti, e il secondo era che uno di essi non lo era. Grigorev sapeva che ogni notte alle 2 veniva creato uno snapshot. Nella console RDS non ne trovò nessuno, ma l'elenco RDS Events mostrava ancora che era stato creato un backup; facendo clic per aprirlo non si apriva nulla. Non riusciva a capire se lo snapshot fosse stato eliminato o fosse semplicemente diventato invisibile.

Ha aperto un ticket di supporto verso mezzanotte, poi ha aggiornato l'account ad AWS Business Support dopo aver notato l'impegno di risposta entro un'ora per gli incidenti di produzione. L'aggiornamento ha aggiunto circa il 10 percento alla sua bolletta AWS, ed è da lì che deriva il titolo del suo post. Il supporto ha risposto in circa 40 minuti, ha confermato l'eliminazione e gli ha detto che esisteva uno snapshot sul lato AWS che non poteva vedere nella sua console. È seguita una chiamata di 40-60 minuti, escalata a un team interno. Esattamente 24 ore dopo l'eliminazione del database, AWS ha ripristinato lo snapshot e questo è apparso nella sua console; ha ricostruito l'istanza da esso tramite Terraform. Durante l'attesa aveva ricostruito l'infrastruttura circostante e consolidato diversi load balancer in uno.

Il database ripristinato conteneva 1.943.200 righe nella tabella courses_answer, che egli cita come verifica che il ripristino fosse completo. Quel dato viene spesso ripetuto come entità della perdita. È il conteggio delle righe di una sola tabella, usato come prova che i dati sono tornati — non un totale per il database, e non un conteggio degli studenti coinvolti, che nessuna delle fonti fornisce.

L'avvertimento che non c'era

Diverse ricostruzioni contengono un passo secondo cui Claude avvertì Grigorev in anticipo e non fu ascoltato. Ciò che le fonti supportano è più circoscritto, e la differenza cambia di che cosa il caso sia un esempio. L'agente argomentò effettivamente contro la configurazione Terraform condivisa prima di qualsiasi distruzione, e quel consiglio fu respinto. Nessuno dei resoconti di Grigorev descrive l'agente che avverte che il destroy avrebbe raggiunto la produzione. Dice che non sapeva che il file di stato era stato sostituito, e in entrambi i resoconti la proposta dell'agente è presentata come una sistemazione anziché come un rischio segnalato e messo da parte. L'avvertimento ignorato riguardava l'architettura, in una fase precedente della migrazione, non il comando.

Questa distinzione separa due diversi tipi di fallimento. Un agente che vede il pericolo e viene scavalcato è una storia di governance su una decisione umana. Un agente che non sa che il pericolo esiste, perché il file che descrive il mondo è cambiato sotto di lui, è una storia di strumenti su stato, autorizzazioni e cancelli di approvazione. Il resoconto di Grigorev è il secondo, e la classificazione stessa dell'archivio lo riflette: il record porta il tag ROGUE dell'archivio per un'azione dell'agente che si è discostata da ciò che il suo operatore intendeva, e la voce dell'AI Incident Database sottostante classifica l'intento come non intenzionale, secondo la tassonomia MIT 7.3, mancanza di capacità o robustezza, nel dominio di rischio della sicurezza dei sistemi di IA, dei guasti e dei limiti, nella fase successiva alla distribuzione. Il database antepone al proprio elenco di entità la dicitura "presunto", la sua formulazione standard per un caso autodichiarato che nessuna autorità ha giudicato.

Dove è ricaduta la colpa

Grigorev non lo distribuisce. «Questo incidente è stato colpa mia», scrive, elencando tre cause: considerava plan, apply e destroy come attività delegabili; si fidava di backup che non aveva mai verificato con un ripristino di prova; e il database era troppo facile da cancellare. Osserva che, mentre aspettava AWS, ha dovuto considerare che i dati potessero essere persi definitivamente — per il corso Data Engineering, che allora stava completando gli ultimi moduli, stava già pianificando un recupero, mentre per i corsi più vecchi un ripristino fallito ne avrebbe sancito la fine.

La valutazione di Tom's Hardware, pubblicata il giorno dopo il suo post, è sostanzialmente la stessa: «gli errori possono essere attribuiti a una supervisione inadeguata». La sua critica va oltre quella del post, puntando il dito su credenziali molto ampie concesse all'agente e su permessi che non sono mai stati circoscritti per un ambiente di produzione. Nessun regolatore, ente normativo o fornitore ha preso posizione. Qui non c'è nessun CVE, nessuna divulgazione di vulnerabilità e nessun jailbreak del modello: l'agente non è stato ingannato, gli è stata data troppa fiducia.

Cosa è cambiato in seguito

Grigorev ha implementato le salvaguardie mentre AWS stava ancora lavorando al ripristino, e le ha pubblicate come elenco. Con le sue parole e nel suo ordine:

• Backup che Terraform non gestisce, oltre a copie su S3 archiviate separatamente dal database e dallo stato dell'infrastruttura.

• Un test di ripristino notturno: il backup automatico delle 2:00 viene usato verso le 3:00 per creare una nuova istanza del database, operazione che richiede dai 20 ai 30 minuti, e una Lambda orchestrata da Step Functions verifica poi, con una semplice query di lettura, che sia utilizzabile prima che l'istanza venga arrestata anziché eliminata. La copia del giorno precedente viene rimossa, così una replica recente è sempre disponibile.

• Protezione dall'eliminazione a due livelli, nella configurazione Terraform e in AWS stesso. Nota che possono comunque essere rimosse da chiunque le disattivi esplicitamente, ma che aggiungono attrito.

• Versionamento sui backup S3, così che l'eliminazione lascia le versioni precedenti e svuotare un bucket richiede prima l'eliminazione dei suoi contenuti.

• Lo stato di Terraform è stato spostato su S3, il che elimina la condizione che l'aveva originato — un file di stato che esisteva solo su un portatile ed era svanito quando ha cambiato macchina.

• L'agente non esegue più Terraform affatto. "Tutte le autorizzazioni sono disabilitate. Nessuna esecuzione automatica. Nessuna scrittura di file", scrive. Il flusso di lavoro ora prevede di generare un piano, revisionarlo manualmente ed eseguire i comandi lui stesso. Anche il nuovo progetto ha ottenuto la propria configurazione Terraform separata.

Non tutte le raccomandazioni sono state accolte. Nell'intervista con Rootly afferma di aver mantenuto un unico account AWS, ritenendo che account separati per sviluppo e produzione e una pipeline di approvazione come Atlantis siano più di quanto serva a un operatore singolo. Questa è la forma onesta delle conseguenze: le correzioni sono reali, e sono le correzioni che una sola persona può mantenere da sola.

Che cos'è questo record e cosa non è

È un incidente operativo documentato e autosegnalato, con danni reali in termini finanziari e di disponibilità, ed è insolitamente leggibile perché la persona a cui è capitato ha annotato l'intera sequenza, comprese le parti che erano un suo errore. Non è prova che un modello abbia perseguito un obiettivo proprio, e il tag ROGUE dell'archivio dovrebbe essere letto come descrizione della divergenza tra l'azione dell'agente e l'intento del suo operatore, piuttosto che di qualsiasi intento da parte dell'agente.

Il dettaglio che vale la pena portare con sé è quello che ha salvato i dati. I backup personali di Grigorev sono stati cancellati insieme al database che proteggevano, e il suo snapshot notturno gli era invisibile anche se il registro degli eventi insisteva che esistesse. Ciò che ha ripristinato 2,5 anni di elaborati è stata una copia conservata sul lato AWS, di cui non era mai venuto a conoscenza e che non avrebbe potuto testare. Un backup da cui non hai mai ripristinato è una convinzione, non un controllo — e in questo caso la convinzione si è rivelata vera solo perché qualcun altro ne stava conservando un secondo.