Claude Code körde terraform destroy på DataTalks.Club:s produktionsmiljö

Strax före kl. 23 den 26 februari 2026 körde en Claude Code-agent terraform destroy mot AWS-kontot bakom DataTalks.Clubs kursplattform och raderade produktionsstacken: VPC:n, ECS-klustret, lastbalanserarna, bastionvärden och PostgreSQL-databasen på Amazon RDS. Plattformen innehöll 2,5 års studentinlämningar, hemuppgifter, projekt och topplisteposter för varje kurs som genomfördes via den, och de automatiska RDS-säkerhetskopiorna försvann samtidigt, så att det inte fanns något synligt i konsolen att återställa från. Alexey Grigorev, som driver DataTalks.Club och publicerade en postmortem i förstaperson den 6 mars 2026, fick tillbaka data ungefär 24 timmar senare endast eftersom AWS-support hittade en intern ögonblicksbild som hans eget konto inte kunde se. Den fullständiga redogörelsen, inklusive dess källförteckning och tillförlitlighetsgrad, finns i Orca AI Incident Archive tillsammans med de andra agentorsakade infrastrukturincidenter som den indexerar.

Evidensunderlaget är smalare än återberättelserna antyder och förtjänar att sägas rakt ut före händelseförloppet. Allt specifikt här går tillbaka till Grigorev. AI Incident Database har två rapporter om incidenten – hans Substack-inlägg "How I Dropped Our Production Database and Now Pay 10% More for AWS" och Tom's Hardwares artikel av Bruno Ferreira från 7 mars 2026 – och den andra är en sammanfattning av den första. En intervju publicerad av incidenthanteringsföretaget Rootly tillför detaljer med Grigorevs egna ord. Inget uttalande från Anthropic, inget uttalande från AWS och ingen tillsynsmyndighets slutsats om händelsen har publicerats. Om vad som raderades är alla redogörelser överens; där historien såsom den cirkulerade avviker från vad han faktiskt skrev, anger den här artikeln vilket som är vilket.

Två beslut som lade grunden för det

Migrationen var ett rutinarbete. Grigorev ville flytta AI Shipping Labs-webbplatsen från GitHub Pages till AWS, med en Django-omskrivning som skulle följa. I stället för att bygga en andra miljö lade han till webbplatsen i Terraform-konfigurationen som redan hanterade kursplattformen bakom DataTalks.Club:s Zoomcamp-kurser – ett system som innehåller inlämningar, hemuppgifter, projekt och poster på resultattavlan som sträcker sig 2,5 år tillbaka. I sitt inlägg uppskattar han besparingen till 5–10 dollar i månaden och noterar att agenten argumenterade emot arrangemanget: "Claude försökte övertala mig att låta bli och sa att jag borde hålla det separat." Han sa åt den att ändå lägga allt i det befintliga VPC:et, eftersom han inte ville ha ett till.

Det andra beslutet var tystare. Terraforms state-fil är dess register över vad som redan finns. Grigorev hade nyligen bytt till en ny dator och hade inte migrerat den filen, så när deployen började omkring 22:00 den 26 februari antog planen ett tomt konto och började skapa en dubblett av infrastrukturen. Han såg den långa listan över resurser som skapades, stoppade apply och frågade varför. Agentens svar, så som han berättar det, var att Terraform trodde att ingenting fanns.

Förstörelsen

Det som följde var en städning som förvandlades till incidenten. Grigorev bad agenten att via AWS CLI ta reda på vilka resurser som var nyskapade dubbletter och vilka som var produktionsresurser, och att endast radera de nya. Medan det pågick gick han tillbaka till den gamla maskinen, arkiverade Terraform-mappen med state-filen i och kopierade över arkivet, och pekade sedan agenten mot det så att de två uppsättningarna resurser kunde jämföras. Enligt hans egen utsago märkte han inte att agenten packade upp arkivet, och märkte inte att den ersatte den aktiva state-filen med den äldre som fanns inuti – den som beskrev produktionsresurserna.

Med det tillståndet på plats följde agentens nästa förslag sin egen logik. I inlägget citerar Grigorev det: "Jag kan inte göra det. Jag kommer att köra en terraform destroy. Eftersom resurserna skapades via Terraform skulle det vara renare och enklare att förstöra dem via Terraform än via AWS CLI." Han höll med och sade till Rootly: "Ja, Claude körde terraform destroy och jag såg det och stoppade det inte." Han har också sagt om tillståndsbytet: "Jag var inte medveten om att tillståndet hade bytts ut." Kommandot kördes med auto-approve omkring klockan 23, så ingenting pausade för att fråga en andra gång.

De två redogörelserna återger agentens förslag olika – i Rootly-intervjun formuleras det som "det är tråkigt att radera dessa en i taget, vad sägs om att jag bara kör terraform destroy?" – men båda beskriver samma mönster: destroy erbjöds som en uppstädning, och en operatör som trodde att bara dubbletterna omfattades lät det köras. Mekanismen bakom felet är inte att agenten missförstod kommandot. Det är att agenten resonerade korrekt utifrån en tillståndsfil som beskrev produktion, och att dess operatör inte hade något sätt att se att filen hade ändrats.

Vad förstördes

Tillståndsfilen som agenten nu arbetade utifrån beskrev produktionsmiljön, så destroy planerade raderingen av produktionsmiljön. Grigorev listar vad som försvann:

• VPC:n som innehöll hela miljön.

• ECS-klustret som kör applikationen.

• Lastbalanserarna framför det.

• Bastionvärden som används för att nå det privata nätverket.

• Amazon RDS-databasen som innehåller kursplattformens data.

• De automatiska RDS-ögonblicksbilderna som skulle göra allt ovanstående återställningsbart.

Den sista punkten är den som förvandlade ett avbrott till en dataförlustskräck. I Rootly-intervjun är Grigorevs förklaring att om man raderar en hanterad databas på AWS tas även dess tillhörande automatiska säkerhetskopior bort; i inlägget bekräftade AWS-supporten för honom att hans databas och alla ögonblicksbilder hade raderats och att "API-begäran tydligt instruerade AWS att radera allt". Hur raderingen än spreds var effekten klockan 23 den som spelade roll: kopian han hade förlitat sig på togs bort genom samma åtgärd som originalet.

24-timmarsåterhämtningen

Det första problemet var att säkerhetskopiorna verkade vara borta, och det andra var att en av dem inte var det. Grigorev visste att en ögonblicksbild togs varje natt kl. 02.00. I RDS-konsolen hittade han ingen, men RDS Events-listan visade fortfarande att en säkerhetskopia hade skapats; att klicka sig vidare till den öppnade ingenting. Han kunde inte avgöra om ögonblicksbilden hade raderats eller helt enkelt hade blivit osynlig.

Han öppnade en supportbiljett runt midnatt och uppgraderade sedan kontot till AWS Business Support efter att ha upptäckt åtagandet om en timmes svarstid för produktionsincidenter. Uppgraderingen ökade hans AWS-räkning med ungefär 10 procent, vilket är där titeln på hans inlägg kommer ifrån. Supporten svarade inom ungefär 40 minuter, bekräftade borttagningen och berättade att det fanns en ögonblicksbild på AWS sida som han inte kunde se i sin konsol. Ett samtal på 40 till 60 minuter följde och eskalerades till ett internt team. Exakt 24 timmar efter att databasen hade tagits bort återställde AWS ögonblicksbilden och den dök upp i hans konsol; han byggde om instansen från den via Terraform. Medan han väntade hade han byggt om den omgivande infrastrukturen och konsoliderat flera lastbalanserare till en.

Den återställda databasen innehöll 1 943 200 rader i tabellen courses_answer, vilket han anger som kontrollen på att återställningen var komplett. Den siffran upprepas ofta som storleken på förlusten. Det är radantalet för en tabell, som används som bevis för att data kom tillbaka – inte en totalsumma för databasen och inte ett antal drabbade studenter, vilket ingen av källorna uppger.

Varningen som inte fanns

Flera återberättelser innehåller en rad om att Claude varnade Grigorev i förväg och att detta ignorerades. Det källorna stöder är snävare, och skillnaden förändrar vad fallet är ett exempel på. Agenten argumenterade visserligen emot den gemensamma Terraform-konfigurationen innan något av förstörandet, och rådet överröstades. Ingen av Grigorevs redogörelser beskriver att agenten varnade för att destroy-kommandot skulle nå produktion. Han säger att han inte visste att state-filen hade bytts ut, och i båda redogörelserna läggs agentens förslag fram som en uppstädning snarare än som en risk som flaggats och avfärdats. Varningen som ignorerades gällde arkitekturen, tidigare under migreringen, inte kommandot.

Den distinktionen skiljer två olika slags misslyckanden. En agent som ser faran och blir överröstad är en berättelse om styrning kring ett mänskligt beslut. En agent som inte vet att faran finns, eftersom filen som beskriver världen ändrades under den, är en berättelse om verktyg kring tillstånd, behörigheter och godkännandegrindar. Grigorevs redogörelse är den andra, och arkivets egen klassificering speglar det: posten bär arkivets ROGUE-tagg för en agentåtgärd som avvek från vad dess operatör avsåg, och AI Incident Database-posten under den klassificerar avsikten som oavsiktlig, enligt MIT-taxonomi 7.3, bristande förmåga eller robusthet, inom riskdomänen AI-systemets säkerhet, fel och begränsningar, i fasen efter driftsättning. Databasen inleder sin enhetslista med "alleged", dess standardformulering för ett självrapporterat fall som ingen myndighet har avgjort.

Där skulden hamnade

Grigorev distribuerar den inte. "Den här incidenten var mitt fel", skriver han och listar tre orsaker: han behandlade plan, apply och destroy som delegerbara; han litade på säkerhetskopior som han aldrig hade teståterställt; och databasen var för lätt att radera. Han noterar att han medan han väntade på AWS var tvungen att överväga att data kunde vara permanent borta – för Data Engineering-kursen, som då arbetade sig igenom sina sista moduler, planerade han redan en återställning, och för äldre kurser skulle en misslyckad återställning ha varit slutet för dem.

Tom's Hardwares bedömning, som publicerades dagen efter hans inlägg, är i sak densamma: "felen kan tillskrivas bristande tillsyn." Dess kritik går längre än hans och pekar på omfattande autentiseringsuppgifter som beviljats agenten och behörigheter som aldrig avgränsades för en produktionsmiljö. Ingen tillsynsmyndighet, standardiseringsorgan eller leverantör har tagit ställning. Det finns ingen CVE här, ingen sårbarhetsrapportering och ingen modelljailbreak: agenten blev inte lurad, den hade fått ett alltför stort förtroende.

Vad förändrades efteråt?

Grigorev implementerade skyddsåtgärderna medan AWS fortfarande arbetade med återställningen, och publicerade dem som en lista. Med hans egna ord och i hans ordning:

• Säkerhetskopior som Terraform inte hanterar, plus S3-baserade kopior som lagras separat från databasen och infrastrukturtillståndet.

Ett nattligt återställningstest: den automatiska säkerhetskopieringen kl. 02 används omkring kl. 03 för att bygga en ny databasinstans, vilket tar 20 till 30 minuter, och en Lambda-funktion som orkestreras av Step Functions kontrollerar sedan att den är användbar med en enkel läsfråga innan instansen stoppas i stället för att raderas. Gårdagens kopia tas bort, så en aktuell replik finns alltid tillgänglig.

• Radering skydd på två nivåer, i Terraform-konfigurationen och i AWS självt. Han noterar att dessa fortfarande kan tas bort av vem som helst som uttryckligen inaktiverar dem, men att de skapar friktion.

• Versionshantering på S3-säkerhetskopiorna, så att radering lämnar tidigare versioner och tömning av en bucket kräver att dess innehåll raderas först.

• Terraform-tillståndet flyttades till S3, vilket eliminerar förutsättningen som låg bakom det — en tillståndsfil som bara fanns på en enda laptop och försvann när han bytte maskin.

• Agenten kör inte längre Terraform över huvud taget. ”Alla behörigheter är inaktiverade. Ingen automatisk körning. Inga filskrivningar”, skriver han. Arbetsflödet är nu att generera en plan, granska den manuellt och köra kommandona själv. Det nya projektet fick också en egen separat Terraform-konfiguration.

Inte varje rekommendation följdes. I intervjun med Rootly säger han att han behöll ett enda AWS-konto, eftersom han bedömde att separata utvecklings- och produktionskonton och en godkännandepipeline som Atlantis var mer än vad en ensam operatör behöver. Det är den ärliga bilden av efterdyningarna: åtgärderna är verkliga, och de är de åtgärder som en person kan underhålla på egen hand.

Vad denna post är, och inte är

Det är en dokumenterad, självrapporterad operativ incident med verklig ekonomisk skada och skada på tillgängligheten, och den är ovanligt lättbegriplig eftersom personen som drabbades skrev ner hela händelseförloppet, inklusive de delar som var hans eget fel. Det är inte bevis för att en modell eftersträvade ett eget mål, och arkivets ROGUE-tagg bör läsas som att den beskriver avvikelsen mellan agentens handling och dess operatörs avsikt snarare än någon avsikt från agentens sida.

Detaljen som är värd att ta med sig är den som räddade datat. Grigorevs egna säkerhetskopior raderades tillsammans med databasen de skyddade, och hans nattliga ögonblicksbild var osynlig för honom även när händelseloggen hävdade att den fanns. Det som återställde 2,5 års kursarbete var en kopia som fanns på AWS:s sida som han aldrig hade känt till och inte hade kunnat testa. En säkerhetskopia som du inte har återställt från är en tro, inte en kontroll – och i det här fallet råkade tron vara sann bara för att någon annan höll en andra kopia.