Claude Code heeft terraform destroy uitgevoerd op de productieomgeving van DataTalks.Club

Kort voor 23.00 uur op 26 februari 2026 voerde een Claude Code-agent terraform destroy uit op het AWS-account achter het cursusplatform van DataTalks.Club en verwijderde de productiestack: de VPC, het ECS-cluster, de loadbalancers, de bastionhost en de PostgreSQL-database op Amazon RDS. Het platform bevatte 2,5 jaar aan inzendingen van studenten, huiswerk, projecten en leaderboardvermeldingen voor elke cursus die erop werd gegeven, en de geautomatiseerde RDS-back-ups werden op hetzelfde moment verwijderd, waardoor er in de console niets zichtbaar overbleef om uit te herstellen. Alexey Grigorev, die DataTalks.Club runt en op 6 maart 2026 een persoonlijke post-mortem publiceerde, kreeg de gegevens ongeveer 24 uur later terug, alleen omdat AWS-support een interne snapshot vond die zijn eigen account niet kon zien. Het volledige verslag, inclusief de bronnenlijst en betrouwbaarheidsgraad, staat in het Orca AI Incident Archive naast de andere door agents veroorzaakte infrastructuurincidenten die het indexeert.

De bewijsbasis is smaller dan de navertellingen suggereren, en het is de moeite waard om dat vóór de reeks duidelijk te stellen. Alles wat hier specifiek is, gaat terug op Grigorev. De AI Incident Database bevat twee rapporten over het incident — zijn Substack-post, "Hoe ik onze productiedatabase heb laten vallen en nu 10% meer voor AWS betaal", en het artikel van Tom's Hardware van 7 maart 2026 door Bruno Ferreira — en het tweede is een samenvatting van het eerste. Een interview dat is gepubliceerd door het incidentmanagementbedrijf Rootly voegt details toe in Grigorevs eigen woorden. Er is geen verklaring van Anthropic, geen verklaring van AWS en geen bevinding van een toezichthouder over het voorval gepubliceerd. Over wat er is verwijderd, zijn alle verslagen het eens; waar het verhaal zoals het circuleerde afwijkt van wat hij daadwerkelijk schreef, geeft dit artikel aan wat wat is.

Twee beslissingen die het mogelijk maakten

De migratie was gewoon werk. Grigorev wilde de AI Shipping Labs-site van GitHub Pages af en naar AWS, met daarna een Django-herschrijving. In plaats van een tweede omgeving te bouwen, voegde hij de site toe aan de Terraform-configuratie die al het cursusplatform achter DataTalks.Club's Zoomcamp-cursussen beheerde — een systeem met inzendingen, huiswerk, projecten en leaderboardvermeldingen van 2,5 jaar terug. In zijn post schat hij de besparing op $5 tot $10 per maand, en vermeldt hij dat de agent zich tegen de opzet verzette: "Claude probeerde me ervan af te praten en zei dat ik het gescheiden moest houden." Toch droeg hij het op alles in de bestaande VPC te zetten, omdat hij er geen tweede wilde.

De tweede beslissing was stiller. Terraforms statebestand is zijn registratie van wat al bestaat. Grigorev was onlangs naar een nieuwe computer overgestapt en had dat bestand niet gemigreerd, dus toen de deploy rond 22.00 uur op 26 februari begon, ging het plan uit van een leeg account en begon het een duplicaat van de infrastructuur aan te maken. Hij zag de lange lijst met resources die werden aangemaakt, stopte de apply en vroeg waarom. Het antwoord van de agent was, zoals hij het vertelt, dat Terraform dacht dat er niets bestond.

Vernietigen

Wat volgde was een opruimactie die uitmondde in het incident. Grigorev vroeg de agent om via de AWS CLI uit te zoeken welke resources nieuw aangemaakte duplicaten waren en welke productie waren, en om alleen de nieuwe te verwijderen. Terwijl dat liep, ging hij terug naar de oude machine, archiveerde de Terraform-map met het statebestand erin, kopieerde het archief over en wees de agent erop zodat de twee sets resources vergeleken konden worden. Volgens zijn eigen relaas merkte hij niet dat de agent het archief uitpakte, en merkte hij niet dat die het actieve statebestand verving door het oudere bestand erin — het bestand dat de productieresources beschreef.

Nu die state er eenmaal stond, volgde het volgende voorstel van de agent zijn eigen logica. In de post citeert Grigorev het: "Ik kan het niet doen. Ik ga een terraform destroy uitvoeren. Omdat de resources via Terraform zijn aangemaakt, zou het verwijderen ervan via Terraform schoner en eenvoudiger zijn dan via AWS CLI." Hij was het ermee eens en zei tegen Rootly: "Ja, Claude heeft terraform destroy uitgevoerd, ik zag het en heb het niet tegengehouden." Over het omwisselen van de state heeft hij ook gezegd: "Ik was me er niet van bewust dat de state was omgewisseld." De opdracht werd rond 23:00 met auto-approve uitgevoerd, dus niets pauzeerde om een tweede keer te vragen.

De twee verslagen geven het voorstel van de agent verschillend weer — in het Rootly-interview luidt het: "het is saai om deze één voor één te verwijderen, wat als ik gewoon terraform destroy uitvoer?" — maar beide beschrijven dezelfde vorm: destroy aangeboden als opruimen, en een operator die geloofde dat alleen de duplicaten binnen bereik vielen en het liet draaien. Het mechanisme van de fout is niet dat de agent het commando verkeerd begreep. Het is dat de agent correct redeneerde op basis van een statebestand dat productie beschreef, en dat zijn operator geen manier had om te zien dat het bestand was veranderd.

Wat werd er vernietigd?

Het statebestand waar de agent nu mee werkte, beschreef productie, dus de destroy plande het verwijderen van productie. Grigorev somt op wat er verdween:

• De VPC die de hele omgeving bevatte.

• Het ECS-cluster waarop de applicatie draait.

• De load balancers ervoor.

• De bastionhost die wordt gebruikt om het privénetwerk te bereiken.

• De Amazon RDS-database met de gegevens van het cursusplatform.

• De automatische RDS-momentopnamen die al het bovenstaande herstelbaar hadden moeten maken.

Het laatste punt is het punt dat van een storing een angst voor gegevensverlies maakte. In het Rootly-interview is Grigorevs uitleg dat het verwijderen van een beheerde database op AWS ook de bijbehorende automatische back-ups verwijdert; in het bericht bevestigde AWS-support hem dat zijn database en alle snapshots waren verwijderd en dat "het API-verzoek AWS duidelijk opdroeg alles te verwijderen." Langs welke weg de verwijdering zich ook had verspreid, het effect om 23.00 uur was het effect dat ertoe deed: de kopie waarop hij had vertrouwd, werd door dezelfde bewerking als het origineel verwijderd.

Het 24-uursherstel

Het eerste probleem was dat de back-ups verdwenen leken te zijn, en het tweede dat een ervan dat niet was. Grigorev wist dat er elke nacht om 02:00 een snapshot werd gemaakt. In de RDS-console vond hij er geen, maar de RDS Events-lijst liet nog steeds zien dat er een back-up was gemaakt; doorklikken ernaar opende niets. Hij kon niet vaststellen of de snapshot was verwijderd of simpelweg onzichtbaar was geworden.

Rond middernacht opende hij een supportticket en daarna upgradede hij het account naar AWS Business Support, nadat hij de toezegging van een reactietijd van één uur voor productie-incidenten had opgemerkt. De upgrade voegde ongeveer 10 procent toe aan zijn AWS-factuur, en daar komt de titel van zijn bericht vandaan. De supportafdeling antwoordde binnen ongeveer 40 minuten, bevestigde de verwijdering en vertelde hem dat er aan de kant van AWS een snapshot bestond die hij niet in zijn console kon zien. Daarop volgde een gesprek van 40 tot 60 minuten, dat werd doorgezet naar een intern team. Precies 24 uur nadat de database was verwijderd, herstelde AWS de snapshot en verscheen die in zijn console; hij bouwde de instance daaruit opnieuw op met Terraform. Tijdens het wachten had hij de omliggende infrastructuur opnieuw opgebouwd en meerdere load balancers samengevoegd tot één.

De herstelde database bevatte 1.943.200 rijen in de courses_answer-tabel, die hij aanhaalt als de controle dat de restore compleet was. Dat cijfer wordt vaak herhaald als de omvang van het verlies. Het is de rijtelling van één tabel, gebruikt als bewijs dat de gegevens terugkwamen — niet een totaal voor de database, en niet een aantal getroffen studenten, dat geen van de bronnen geeft.

De waarschuwing die er niet was

Verschillende navertellingen bevatten de bewering dat Claude Grigorev vooraf waarschuwde en dat die waarschuwing werd genegeerd. Wat de bronnen ondersteunen, is beperkter, en dat verschil verandert waarvan deze zaak een voorbeeld is. De agent pleitte inderdaad tegen de gedeelde Terraform-opzet voordat er iets werd vernietigd, en dat advies werd terzijde geschoven. Geen van Grigorevs verslagen beschrijft dat de agent waarschuwde dat de destroy productie zou bereiken. Hij zegt dat hij niet wist dat het statebestand was vervangen, en in beide verslagen wordt het voorstel van de agent gepresenteerd als een opruiming, niet als een gesignaleerd en terzijde geschoven risico. De waarschuwing die werd genegeerd, ging over de architectuur, eerder in de migratie, niet over de opdracht.

Dat onderscheid scheidt twee verschillende soorten falen. Een agent die het gevaar ziet en terzijde wordt geschoven, is een governanceverhaal over een menselijke beslissing. Een agent die niet weet dat het gevaar bestaat, omdat het bestand dat de wereld beschrijft onder hem is veranderd, is een toolingverhaal over status, machtigingen en goedkeuringspoorten. Grigorevs verslag is het tweede, en de eigen classificatie van het archief weerspiegelt dat: het record draagt de ROGUE-tag van het archief voor een agentactie die afweek van wat de operator bedoelde, en de AI Incident Database-vermelding eronder classificeert de intentie als onopzettelijk, onder MIT-taxonomie 7.3, gebrek aan capaciteit of robuustheid, in het risicodomein veiligheid, falen en beperkingen van AI-systemen, in de post-deploymentfase. De database zet "alleged" voor zijn entiteitenlijst, de standaardformulering voor een zelfgerapporteerde zaak die geen enkele autoriteit heeft beoordeeld.

Waar de schuld terechtkwam

Grigorev distribueert het niet. "Dit incident was mijn fout," schrijft hij, en hij noemt drie oorzaken: hij behandelde plan, apply en destroy als delegeerbaar; hij vertrouwde op back-ups die hij nooit via een test had hersteld; en de database was te gemakkelijk te verwijderen. Hij merkt op dat hij, terwijl hij op AWS wachtte, er rekening mee moest houden dat de data permanent verdwenen zou kunnen zijn — voor de cursus Data Engineering, die toen de laatste modules doorliep, was hij al een herstel aan het plannen, en voor oudere cursussen zou een mislukte herstelactie het einde ervan betekenen.

De beoordeling van Tom's Hardware, gepubliceerd de dag na zijn bericht, komt in essentie op hetzelfde neer: "de fouten kunnen worden toegeschreven aan onjuist toezicht." De kritiek ervan gaat verder dan de zijne en wijst op uitgebreide inloggegevens die aan de agent zijn verleend en machtigingen die nooit zijn ingeperkt voor een productieomgeving. Geen enkele toezichthouder, normerende instantie of leverancier heeft stelling genomen. Er is hier geen CVE, geen openbaarmaking van een kwetsbaarheid en geen modeljailbreak: de agent werd niet misleid, er werd te veel op vertrouwd.

Wat is er daarna veranderd?

Grigorev implementeerde de veiligheidsmaatregelen terwijl AWS nog aan het herstel werkte, en publiceerde ze als een lijst. In zijn woorden en in zijn volgorde:

• Back-ups die niet door Terraform worden beheerd, plus S3-gebaseerde kopieën die afzonderlijk van de database en de infrastructuurstatus worden opgeslagen.

• Een nachtelijke restauratietest: de geautomatiseerde back-up van 02:00 uur wordt rond 03:00 uur gebruikt om een nieuwe database-instantie op te bouwen, wat 20 tot 30 minuten duurt, en een door Step Functions georkestreerde Lambda controleert vervolgens met een eenvoudige leesquery of deze bruikbaar is, waarna de instantie wordt gestopt in plaats van verwijderd. De kopie van gisteren wordt verwijderd, zodat er altijd één recente replica beschikbaar is.

• Verwijderingsbeveiliging op twee niveaus, in de Terraform-configuratie en in AWS zelf. Hij merkt op dat deze nog steeds kunnen worden verwijderd door iedereen die ze expliciet uitschakelt, maar dat ze drempels opwerpen.

• Versiebeheer op de S3-back-ups, zodat verwijderen eerdere versies achterlaat en het leegmaken van een bucket vereist dat je eerst de inhoud ervan verwijdert.

De Terraform-state is naar S3 verplaatst, wat de omstandigheid wegneemt die eraan ten grondslag lag — een statebestand dat alleen op één laptop bestond en verdween toen hij van machine wisselde.

• De agent voert Terraform helemaal niet meer uit. "Alle machtigingen zijn uitgeschakeld. Geen automatische uitvoering. Geen bestandswijzigingen," schrijft hij. De workflow is nu om een plan te genereren, het handmatig te beoordelen en de commando's zelf uit te voeren. Het nieuwe project kreeg ook een eigen, aparte Terraform-configuratie.

Niet elke aanbeveling werd opgevolgd. In het Rootly-interview zegt hij dat hij één AWS-account aanhield, omdat hij afzonderlijke ontwikkel- en productieaccounts en een goedkeuringspipeline zoals Atlantis meer vond dan nodig voor iemand die in zijn eentje werkt. Dat is de eerlijke vorm van de nasleep: de oplossingen zijn echt, en het zijn oplossingen die één persoon alleen kan onderhouden.

Wat dit record wel en niet is

Het is een gedocumenteerd, zelfgerapporteerd operationeel incident met echte financiële schade en schade aan de beschikbaarheid, en het is ongewoon goed te volgen omdat de persoon wie het overkwam de hele reeks opschreef, inclusief de delen die zijn eigen fout waren. Het is geen bewijs dat een model een eigen doel nastreefde, en de ROGUE-tag van het archief moet zo worden gelezen dat die de divergentie beschrijft tussen de actie van de agent en de intentie van de operator, en niet een of andere intentie aan de kant van de agent.

Het detail dat het onthouden waard is, is precies datgene dat de gegevens heeft gered. Grigorevs eigen back-ups werden verwijderd samen met de database die ze beschermden, en zijn nachtelijke snapshot was voor hem onzichtbaar, zelfs terwijl het gebeurtenissenlog volhield dat die bestond. Wat 2,5 jaar cursuswerk herstelde, was een kopie die aan de kant van AWS werd bewaard, waarvan hij nooit had geweten dat die bestond en die hij niet had kunnen testen. Een back-up waaruit je niet hebt hersteld, is een overtuiging, geen beheersmaatregel — en in dit geval was de overtuiging alleen maar juist omdat iemand anders een tweede exemplaar bewaarde.