Claude Code hat auf der DataTalks.Club-Produktionsumgebung terraform destroy ausgeführt

Kurz vor 23 Uhr am 26. Februar 2026 führte ein Claude Code-Agent terraform destroy gegen das AWS-Konto aus, das hinter der Kursplattform von DataTalks.Club steht, und löschte den Produktions-Stack: die VPC, den ECS-Cluster, die Load Balancer, den Bastion-Host und die PostgreSQL-Datenbank auf Amazon RDS. Die Plattform enthielt 2,5 Jahre an Abgaben von Studierenden, Hausaufgaben, Projekten und Leaderboard-Einträgen für jeden darüber abgewickelten Kursdurchlauf, und die automatisierten RDS-Backups gingen im selben Moment verloren, sodass in der Konsole nichts Sichtbares zum Wiederherstellen übrig blieb. Alexey Grigorev, der DataTalks.Club leitet und am 6. März 2026 einen Post-mortem-Bericht aus erster Hand veröffentlichte, bekam die Daten etwa 24 Stunden später nur deshalb zurück, weil der AWS-Support einen internen Snapshot fand, den sein eigenes Konto nicht sehen konnte. Der vollständige Eintrag, einschließlich seiner Quellenliste und seines Konfidenzgrads, steht im Orca AI Incident Archive neben den anderen von Agenten verursachten Infrastrukturvorfällen, die es indexiert.

Die Evidenzbasis ist schmaler, als die Nacherzählungen nahelegen, und es lohnt sich, sie vor der Abfolge der Ereignisse klar zu benennen. Alles Konkrete hier geht auf Grigorev zurück. Die AI Incident Database enthält zwei Berichte zu dem Vorfall – seinen Substack-Beitrag „Wie ich unsere Produktionsdatenbank gelöscht habe und jetzt 10 % mehr für AWS zahle“ und den Tom's-Hardware-Artikel vom 7. März 2026 von Bruno Ferreira –, und der zweite ist eine Zusammenfassung des ersten. Ein von dem Incident-Management-Unternehmen Rootly veröffentlichtes Interview ergänzt Details in Grigorevs eigenen Worten. Es wurde keine Stellungnahme von Anthropic, keine von AWS und keine Feststellung einer Aufsichtsbehörde zu dem Vorfall veröffentlicht. Hinsichtlich dessen, was gelöscht wurde, stimmen alle Darstellungen überein; wo die Geschichte in ihrer Verbreitung von dem abweicht, was er tatsächlich schrieb, sagt dieser Artikel, welche Darstellung welche ist.

Zwei Entscheidungen, die den Grundstein dafür legten

Die Migration war Routinearbeit. Grigorev wollte die Website von AI Shipping Labs von GitHub Pages weg und auf AWS bringen, mit einer anschließenden Django-Neufassung. Statt eine zweite Umgebung aufzubauen, fügte er die Website der Terraform-Konfiguration hinzu, die bereits die Kursplattform hinter den Zoomcamp-Kursen von DataTalks.Club verwaltete – ein System, das seit 2,5 Jahren Einreichungen, Hausaufgaben, Projekte und Leaderboard-Einträge enthält. In seinem Beitrag beziffert er die Einsparung auf 5 bis 10 US-Dollar pro Monat und hält fest, dass der Agent gegen diese Regelung argumentierte: „Claude versuchte, mir das auszureden, und sagte, ich sollte es getrennt halten.“ Er wies ihn dennoch an, alles in die bestehende VPC zu packen, weil er keine weitere wollte.

Die zweite Entscheidung war stiller. Die State-Datei von Terraform ist seine Aufzeichnung darüber, was bereits existiert. Grigorev war kürzlich auf einen neuen Computer umgestiegen und hatte diese Datei nicht migriert, sodass der Plan, als das Deployment am 26. Februar gegen 22 Uhr begann, ein leeres Konto annahm und begann, ein Duplikat der Infrastruktur zu erstellen. Er sah die lange Liste der Ressourcen, die gerade erstellt wurden, stoppte den Apply und fragte, warum. Die Antwort des Agenten, wie er sie erzählt, war, dass Terraform glaubte, es existiere nichts.

Die Zerstörung

Was folgte, war eine Aufräumaktion, die zum eigentlichen Vorfall wurde. Grigorev bat den Agenten, über die AWS CLI herauszufinden, welche Ressourcen neu erstellte Duplikate und welche Produktionsressourcen waren, und nur die neuen zu löschen. Während das lief, ging er zurück zur alten Maschine, archivierte den Terraform-Ordner samt der darin enthaltenen State-Datei, kopierte das Archiv hinüber und verwies den Agenten darauf, damit die beiden Ressourcensätze verglichen werden konnten. Seiner Darstellung zufolge bemerkte er nicht, wie der Agent das Archiv entpackte, und bemerkte auch nicht, dass er die aktive State-Datei durch die ältere darin ersetzte – diejenige, die die Produktionsressourcen beschrieb.

Da dieser State nun vorlag, folgte der nächste Vorschlag des Agenten seiner eigenen Logik. In dem Beitrag zitiert Grigorev ihn: „Ich kann es nicht tun. Ich werde ein terraform destroy ausführen. Da die Ressourcen über Terraform erstellt wurden, wäre es sauberer und einfacher, sie über Terraform zu zerstören als über die AWS CLI.“ Er stimmte zu und sagte zu Rootly: „Ja, Claude hat terraform destroy ausgeführt, und ich habe es gesehen und nicht gestoppt.“ Er hat außerdem über den State-Tausch gesagt: „Mir war nicht bewusst, dass der State ausgetauscht worden war.“ Der Befehl lief gegen 23 Uhr mit automatischer Genehmigung, sodass nichts anhielt, um ein zweites Mal nachzufragen.

Die beiden Berichte geben den Vorschlag des Agenten unterschiedlich wieder – im Rootly-Interview heißt es: „Es ist langweilig, diese einzeln zu löschen, wie wäre es, wenn ich einfach terraform destroy ausführe?“ –, aber beide beschreiben dieselbe Form: Destroy wird als Aufräumen angeboten, und ein Bediener, der glaubte, nur die Duplikate seien betroffen, ließ es laufen. Der Mechanismus des Fehlers ist nicht, dass der Agent den Befehl missverstanden hat. Vielmehr hat der Agent korrekt auf Grundlage einer Statusdatei geschlussfolgert, die die Produktion beschrieb, und sein Bediener hatte keine Möglichkeit zu erkennen, dass sich die Datei geändert hatte.

Was wurde zerstört?

Die State-Datei, mit der der Agent nun arbeitete, beschrieb die Produktion, daher plante der Destroy-Vorgang die Löschung der Produktion. Grigorev listet auf, was dabei verloren ging:

• Die VPC, die die gesamte Umgebung beherbergte.

• Der ECS-Cluster, auf dem die Anwendung läuft.

• Die Load Balancer davor.

• Der Bastion-Host, über den das private Netzwerk erreicht wird.

• Die Amazon-RDS-Datenbank, die die Daten der Kursplattform enthält.

• Die automatisierten RDS-Snapshots, die all das oben Genannte wiederherstellbar machen sollten.

Der letzte Punkt ist derjenige, der aus einem Ausfall einen Datenverlust-Schrecken machte. In dem Rootly-Interview erklärt Grigorev, dass das Löschen einer verwalteten Datenbank auf AWS auch ihre zugehörigen automatischen Backups entfernt; in dem Beitrag bestätigte der AWS-Support ihm, dass seine Datenbank und alle Snapshots gelöscht worden waren und dass „die API-Anfrage AWS eindeutig anwies, alles zu löschen“. Wie auch immer sich die Löschung fortpflanzte, entscheidend war die Wirkung um 23 Uhr: Die Kopie, auf die er sich verlassen hatte, wurde durch denselben Vorgang wie das Original entfernt.

Die 24-Stunden-Erholung

Das erste Problem war, dass die Backups offenbar verschwunden waren, und das zweite, dass eines davon nicht verschwunden war. Grigorev wusste, dass jede Nacht um 2 Uhr ein Snapshot erstellt wurde. In der RDS-Konsole fand er keine, aber die RDS-Events-Liste zeigte weiterhin an, dass ein Backup erstellt worden war; ein Klick darauf öffnete nichts. Er konnte nicht sagen, ob der Snapshot gelöscht worden war oder einfach unsichtbar geworden war.

Er öffnete gegen Mitternacht ein Support-Ticket und führte anschließend ein Upgrade des Kontos auf AWS Business Support durch, nachdem ihm die Ein-Stunden-Reaktionszusage für Produktionsvorfälle aufgefallen war. Das Upgrade erhöhte seine AWS-Rechnung um rund 10 Prozent – daher stammt der Titel seines Beitrags. Der Support antwortete in etwa 40 Minuten, bestätigte die Löschung und teilte ihm mit, dass auf AWS-Seite ein Snapshot existierte, den er in seiner Konsole nicht sehen konnte. Es folgte ein Anruf von 40 bis 60 Minuten, der an ein internes Team eskaliert wurde. Genau 24 Stunden nach dem Löschen der Datenbank stellte AWS den Snapshot wieder her, und er erschien in seiner Konsole; er baute die Instanz daraus über Terraform neu auf. Während der Wartezeit hatte er die umliegende Infrastruktur neu aufgebaut und mehrere Load Balancer zu einem zusammengefasst.

Die wiederhergestellte Datenbank enthielt 1.943.200 Zeilen in der courses_answer Tabelle, die er als Beleg dafür anführt, dass die Wiederherstellung vollständig war. Diese Zahl wird oft als Umfang des Verlusts wiederholt. Sie ist die Zeilenzahl einer einzelnen Tabelle, verwendet als Beleg dafür, dass die Daten zurückkamen – keine Gesamtzahl für die Datenbank und keine Zahl der betroffenen Studierenden, die keine der Quellen angibt.

Die Warnung, die keine war

Mehrere Nacherzählungen enthalten die Aussage, Claude habe Grigorev vorher gewarnt und sei ignoriert worden. Was die Quellen stützen, ist enger gefasst, und dieser Unterschied verändert, wofür der Fall ein Beispiel ist. Der Agent sprach sich tatsächlich gegen das gemeinsame Terraform-Setup aus, bevor es zu irgendeiner der Zerstörungen kam, und dieser Rat wurde überstimmt. Keine von Grigorevs Schilderungen beschreibt, dass der Agent davor gewarnt hätte, der Destroy werde die Produktion erreichen. Er sagt, er habe nicht gewusst, dass die State-Datei ausgetauscht worden sei, und in beiden Darstellungen wird der Vorschlag des Agenten als Aufräumen dargeboten und nicht als ein benanntes und gebilligtes Risiko. Die ignorierte Warnung betraf die Architektur, früher in der Migration, nicht den Befehl.

Diese Unterscheidung trennt zwei verschiedene Fehlerarten. Ein Agent, der die Gefahr erkennt und überstimmt wird, ist eine Governance-Geschichte über eine menschliche Entscheidung. Ein Agent, der nicht weiß, dass die Gefahr existiert, weil sich die Datei, die die Welt beschreibt, unter ihm verändert hat, ist eine Tooling-Geschichte über Zustand, Berechtigungen und Freigabe-Gates. Grigorevs Darstellung ist die zweite, und die Klassifizierung des Archivs selbst spiegelt das wider: Der Datensatz trägt das ROGUE-Tag des Archivs für eine Agentenaktion, die von dem abwich, was ihr Betreiber beabsichtigt hatte, und der darunterliegende Eintrag in der AI Incident Database klassifiziert die Absicht als unbeabsichtigt, unter MIT-Taxonomie 7.3, mangelnde Fähigkeit oder Robustheit, im Risikobereich Sicherheit, Fehler und Einschränkungen von KI-Systemen, in der Phase nach der Bereitstellung. Die Datenbank stellt ihrer Entitätsliste „alleged“ voran, ihre übliche Formulierung für einen selbst gemeldeten Fall, den keine Behörde entschieden hat.

Wo die Schuld landete

Grigorev gibt es nicht weiter. „Dieser Vorfall war mein Fehler“, schreibt er und nennt drei Ursachen: Er habe Plan, Apply und Destroy als delegierbar behandelt; er habe Backups vertraut, die er nie testweise wiederhergestellt hatte; und die Datenbank sei zu leicht zu löschen gewesen. Er merkt an, dass er während des Wartens auf AWS in Betracht ziehen musste, dass die Daten dauerhaft verloren sein könnten – für den Kurs Data Engineering, der damals gerade seine letzten Module durchlief, plante er bereits eine Wiederherstellung, und für ältere Kurse wäre eine fehlgeschlagene Wiederherstellung das Ende gewesen.

Die Bewertung von Tom's Hardware, die am Tag nach seinem Beitrag veröffentlicht wurde, kommt inhaltlich zum selben Ergebnis: „Die Fehler lassen sich auf unzureichende Aufsicht zurückführen.“ Ihre Kritik geht weiter als seine und verweist auf weitreichende Zugangsdaten, die dem Agenten gewährt wurden, sowie auf Berechtigungen, die für eine Produktionsumgebung nie eingeschränkt wurden. Keine Regulierungsbehörde, kein Standardisierungsgremium und kein Anbieter hat Stellung bezogen. Es gibt hier keine CVE, keine Offenlegung einer Sicherheitslücke und keinen Model-Jailbreak: Der Agent wurde nicht ausgetrickst, ihm wurde zu sehr vertraut.

Was hat sich danach geändert?

Grigorev implementierte die Schutzmaßnahmen, während AWS noch an der Wiederherstellung arbeitete, und veröffentlichte sie als Liste. In seinen Worten und seiner Reihenfolge:

• Backups, die nicht von Terraform verwaltet werden, plus S3-basierte Kopien, die getrennt von der Datenbank und dem Infrastruktur-Zustand gespeichert werden.

• Ein nächtlicher Wiederherstellungstest: Die automatisierte Sicherung um 2 Uhr wird gegen 3 Uhr genutzt, um eine frische Datenbankinstanz aufzubauen, was 20 bis 30 Minuten dauert, und ein von Step Functions orchestrierter Lambda prüft dann mit einer einfachen Leseabfrage, ob sie nutzbar ist, bevor die Instanz gestoppt statt gelöscht wird. Die gestrige Kopie wird entfernt, sodass immer eine aktuelle Replik verfügbar ist.

• Löschschutz auf zwei Ebenen, in der Terraform-Konfiguration und in AWS selbst. Er merkt an, dass diese zwar von jedem entfernt werden können, der sie explizit deaktiviert, dass sie aber eine zusätzliche Hürde darstellen.

• Versionierung für die S3-Backups, sodass beim Löschen frühere Versionen erhalten bleiben und zum Leeren eines Buckets zuerst dessen Inhalte gelöscht werden müssen.

• Der Terraform-State wurde nach S3 verschoben, wodurch die Bedingung entfällt, die das ausgelöst hat – eine State-Datei, die nur auf einem einzigen Laptop existierte und verschwand, als er den Rechner wechselte.

• Der Agent führt Terraform überhaupt nicht mehr aus. „Alle Berechtigungen sind deaktiviert. Keine automatische Ausführung. Keine Dateischreibvorgänge“, schreibt er. Der Workflow besteht nun darin, einen Plan zu erstellen, ihn manuell zu prüfen und die Befehle selbst auszuführen. Das neue Projekt erhielt außerdem seine eigene separate Terraform-Konfiguration.

Nicht jede Empfehlung wurde umgesetzt. Im Rootly-Interview sagt er, er habe ein einziges AWS-Konto beibehalten, da er getrennte Entwicklungs- und Produktionskonten und eine Genehmigungspipeline wie Atlantis für mehr hielt, als ein Einzelbetreiber braucht. Das ist die ehrliche Gestalt der Nachwirkungen: Die Korrekturen sind real, und es sind die Korrekturen, die eine Person allein aufrechterhalten kann.

Was dieser Datensatz ist und was nicht

Es ist ein dokumentierter, selbst gemeldeter Betriebsvorfall mit realen finanziellen Schäden und Beeinträchtigungen der Verfügbarkeit, und er ist ungewöhnlich nachvollziehbar, weil die Person, der er passiert ist, den gesamten Ablauf aufgeschrieben hat, einschließlich der Teile, die auf ihren eigenen Fehler zurückgingen. Es ist kein Beleg dafür, dass ein Modell ein eigenes Ziel verfolgte, und das ROGUE-Tag des Archivs sollte so gelesen werden, dass es die Abweichung zwischen der Handlung des Agenten und der Absicht seines Betreibers beschreibt und nicht irgendeine Absicht auf Seiten des Agenten.

Das Detail, das es wert ist, mitzunehmen, ist dasjenige, das die Daten gerettet hat. Grigorevs eigene Backups wurden zusammen mit der Datenbank gelöscht, die sie schützten, und sein nächtlicher Snapshot war für ihn unsichtbar, selbst als das Ereignisprotokoll darauf beharrte, dass er existierte. Was 2,5 Jahre Kursarbeit wiederherstellte, war eine Kopie, die auf AWS-Seite aufbewahrt wurde, von der er nie gewusst hatte und die er nicht hätte testen können. Ein Backup, aus dem man nicht wiederhergestellt hat, ist ein Glaube, keine Kontrolle – und in diesem Fall traf der Glaube nur deshalb zufällig zu, weil jemand anderes ein zweites aufbewahrte.