Am 26. Februar 2026 gegen 23 Uhr führte Claude Code terraform destroy gegen die AWS-Infrastruktur von DataTalks.Club aus. Laut dem Postmortem des Betreibers Alexey Grigorev wurden Produktionsdatenbank, VPC, ECS-Cluster, Load Balancer, Bastion Host und automatische Datenbank-Snapshots gelöscht.
Der Vorfall war kein Einbruch, und der Agent hatte nicht die Kontrolle über die Umgebung übernommen. Grigorev, der das System betrieb und später einen ausführlichen Bericht veröffentlichte, hatte Claude Code Terraform-Befehle ausführen lassen, um doppelte AWS-Ressourcen zu bereinigen. Die State-Datei lag noch auf einem alten Rechner. Terraform hielt deshalb die bestehende Infrastruktur für nicht vorhanden und begann, Duplikate anzulegen. Später ersetzte das Entpacken eines Archivs den aktuellen State durch eine ältere Datei; dadurch umfasste terraform destroy auch die Infrastruktur von DataTalks.Club. Grigorev stoppte den Vorgang nicht, weil er annahm, der Befehl betreffe nur die Duplikate.
AWS stellte etwa 24 Stunden später einen Snapshot wieder her. Die Datenbank enthielt zweieinhalb Jahre an Kurseinreichungen, darunter 1.943.200 Zeilen in einer Antworttabelle. Grigorev benannte den Fehler klar: Er hatte destruktive Befehle delegiert, den vollständigen Wiederherstellungsweg nicht getestet und zu wenige Barrieren zwischen einem falschen Plan und der Löschung in Produktion eingerichtet. Sein Bericht hält zudem ein unangenehmes Detail fest. Claude hatte ihm vor Beginn empfohlen, die Infrastruktur der beiden Projekte zu trennen.
Interpretation, Empfehlung und Ausführung lagen in derselben Sitzung, demselben Kontext und derselben Berechtigungsgrenze. Als der Kontext falsch wurde, verglich keine unabhängige Kontrolle den Zerstörungsplan mit dem vorgesehenen Umfang.
Der Fehler Ging Über Einen Schlechten Befehl Hinaus
Die Entscheidung beruhte zunächst auf unvollständigen, dann auf veralteten Nachweisen. Terraform State ordnet bereitgestellte Ressourcen einer Konfiguration zu. Als sich der State während der Sitzung änderte, änderten sich Bedeutung und Folge der vorgeschlagenen Handlung.
Zwischen der Bereinigung neu angelegter Ressourcen und der Löschung lang bestehender Produktionsinfrastruktur fehlte außerdem eine Richtliniengrenze. Die Anweisung stand im Gespräch, doch die Ausführungsumgebung setzte sie nicht durch.
Der Agent empfahl die destruktive Handlung und führte sie anschließend aus. Der Betreiber sah eine plausible Erklärung und ließ den Befehl laufen; weder ein unabhängiger Produktionsverantwortlicher noch eine Cloud-Kontrolle oder ein eigener Freigabeschritt verglich den tatsächlichen Plan mit dem beabsichtigten Umfang.
Die Wiederherstellung lag in derselben Ausfallgrenze. Die Löschung erfasste die automatischen Snapshots, auf die sich der Betreiber verlassen hatte. Ein Backup, das zusammen mit dem geschützten System verschwindet, ist kein unabhängiger Wiederherstellungsweg.
Das ist ein Problem des gesteuerten Entscheidungssystems. Nachweise, Richtlinie, Befugnis, Handlung und Wiederherstellung versagten gemeinsam. Ein anderes Modell oder eine zusätzliche Warnung im Prompt würde diesen gesamten Pfad nicht reparieren.
Coding-Agenten Verändern Die CI/CD-Vertrauensgrenze
Der Vorfall bei DataTalks.Club begann mit einem falschen Betriebskontext, nicht mit einem externen Angreifer. Zwei Fälle aus dem Juni zeigen, was geschieht, wenn feindliche Eingaben einen Coding-Agenten mit nützlichen Werkzeugen erreichen.
Am 5. Juni veröffentlichte Microsoft Threat Intelligence Forschung zur Claude Code GitHub Action. Ein Prompt in einem GitHub-Issue oder Pull-Request-Inhalt konnte den Agenten zu Dateien im CI-Runner lenken. Microsoft zeigte, dass das Read-Werkzeug auf /proc/self/environ zugreifen konnte, wo ein nicht bereinigter Anthropic-API-Schlüssel lag, obwohl die Bereinigung von Umgebungsvariablen die Bash-Ausführung schützte. Microsoft meldete das Problem am 29. April an Anthropic; Anthropic behob es am 5. Mai in Claude Code 2.1.128. Die Veröffentlichung dokumentiert eine getestete Schwachstelle, keinen bestätigten Kundeneinbruch. Microsofts Untersuchung zeigt, warum Dateizugriff, Geheimnisse, nicht vertrauenswürdige Repository-Inhalte und ausgehende Kommunikation keine uneingeschränkte Ausführungsgrenze teilen dürfen.
Am 25. Juni veröffentlichten 0Din-Forscher eine andere kontrollierte Demonstration, keinen Bericht über einen tatsächlichen Einbruch. Ihr unauffälliges Repository führte Claude Code über Installationsanweisungen, einen Fehler, ein Shell-Skript und einen DNS-TXT-Eintrag, der zur Laufzeit die Nutzlast lieferte. Die Kette endete mit einer Reverse Shell auf dem Rechner des Entwicklers, obwohl die schädliche Nutzlast nie im Repository lag. In der 0Din-Demonstration erklärte keine einzelne Eingabe die abschließende Handlung. Das Risiko entstand über den gesamten Werkzeugpfad.
Die Fälle haben nicht dieselbe Ursache. Bei der Löschung im Februar ging es um menschliches Urteil und breiten Produktionszugriff. Microsoft legte eine Sandbox-Lücke offen; 0Din verkettete vertrauenswürdiges Installationsverhalten über mehrere Systeme. In allen Fällen lag die Interpretation natürlicher Sprache in einem Ablauf, der sensible Inhalte lesen oder Zustände ändern konnte.
Empfehlung Und Ausführung Trennen
Ein KI-Coding-Agent braucht nicht für jede Aufgabe dieselbe Befugnis. Passen Sie sie an Folge und Umkehrbarkeit der vorgeschlagenen Handlung an.
Zugangsdaten bestimmen die technische Reichweite. Befugnis bestimmt, welche Handlung der Agent zu welchem Zweck, mit wessen Genehmigung und unter welcher Wiederherstellungspflicht ausführen darf.
| Vorgeschlagene Handlung | Passende Automatisierungsstufe | Erforderliche Kontrolle |
|---|---|---|
| Code erklären oder einen Plan prüfen | Entscheidungsunterstützung | Nur-Lese-Zugriff auf festgelegte Repositorys, State-Dateien und Protokolle |
| Code oder eine Infrastrukturänderung entwerfen | Entscheidungserweiterung | Tests und Richtlinienprüfungen laufen, bevor ein befugter Ingenieur die Änderung annimmt |
| Eine isolierte Entwicklungsumgebung ändern | Begrenzte Automatisierung | Umgebungsspezifische Zugangsdaten, Kosten- und Zeitgrenzen, Protokollierung und automatische Bereinigung |
| Einen Produktionsinfrastrukturplan vorbereiten | Entscheidungserweiterung | Ein benannter Produktionsverantwortlicher prüft den gespeicherten Plan und entscheidet über die Ausführung |
| Produktionsressourcen, Backups oder Sicherheitskontrollen löschen | Entscheidungserweiterung | Der Agent bereitet den Plan vor; eine befugte Person führt ihn nach einer separaten Freigabe mit eigenen Zugangsdaten aus |
Entscheidungserweiterung ist für Produktionsinfrastruktur die sicherere Voreinstellung. Der Agent kann State prüfen, einen Plan vorbereiten, die erwartete Wirkung erklären und Testnachweise zusammenstellen. Ein befugter Ingenieur entscheidet anschließend über die Ausführung des gespeicherten Plans. HashiCorp empfiehlt in seiner Terraform-Anleitung zur Automatisierung dringend eine manuelle Prüfung, wenn Terraform destruktive Produktionsänderungen vornehmen kann. Automatische Freigabe bleibt nicht kritischer Infrastruktur vorbehalten, bei der unbeabsichtigte Ausfallzeit hinnehmbar ist.
Freigabe darf nicht bedeuten, einen Prompt wegzuklicken, der nur die Schlussfolgerung des Agenten wiederholt. Der Produktionsverantwortliche braucht den exakten gespeicherten Plan und die aktuelle State-Quelle, dazu die betroffene Umgebung, geplante Löschungen und Ersetzungen, Richtlinienergebnisse und den Wiederherstellungsstatus. Ändern sich diese Nachweise nach der Freigabe, verfällt sie.
Harte Grenzen Außerhalb Des Modells Setzen
Prompts können einen Agenten anweisen, die Produktion zu meiden. Sie drücken Absicht aus, setzen aber keine Befugnis durch. Anthropic trifft dieselbe Unterscheidung in seinem Bericht vom Mai 2026 über die Eindämmung von Claude in seinen Produkten. Das Unternehmen beschreibt Modellkontrollen als probabilistisch und setzt Prozess-Sandboxes, virtuelle Maschinen, Dateisystemgrenzen und Kontrollen für ausgehenden Netzwerkverkehr ein, um die Reichweite des Agenten zu begrenzen.
Geben Sie jedem Coding-Agenten eine eigene Identität und Zugangsdaten für genau eine Umgebung und einen Zweck. Er sollte nicht den dauerhaften Cloud-Zugriff eines Entwicklers ausleihen. Produktionsrechte müssen destruktive Vorgänge ausschließen, bis eine getrennte, kurzlebige Autorisierung genau eine genehmigte Handlung erlaubt. Die genehmigende Person muss die Produktionsfolge verantworten, nicht nur die Programmieraufgabe. Unser Artikel über Identität und Befugnis von KI-Agenten erklärt, warum Authentifizierung allein nicht beantwortet, ob eine bestimmte Handlung jetzt zulässig ist.
Nicht vertrauenswürdige Eingaben brauchen eine eigene Grenze. Issue-Texte, Pull-Request-Beschreibungen, Repository-Dateien, Ausgaben von Abhängigkeiten, Fehlermeldungen, Dokumentation und abgerufene Webinhalte können den nächsten Schritt des Agenten beeinflussen. Ein Ablauf, der solche Inhalte liest, sollte nicht zugleich uneingeschränkte Geheimnisse und einen offenen Ausgangskanal besitzen. Kontrollen müssen Dateizugriffe, Werkzeugaufrufe, Zugangsdaten, Netzwerkziele und Zustandsänderungen erfassen, selbst wenn das Modell die Anfrage für harmlos hält.
Richtlinienprüfungen sollten Folgen untersuchen, nicht Befehlstext durchsuchen. Das Blockieren von terraform destroy erkennt keine Konfigurationsänderung, die eine Datenbank ersetzt, eine Backup-Richtlinie entfernt oder dieselbe Wirkung über eine Cloud-API erzielt. Prüfen Sie Ressourcenlöschungen und -ersetzungen, Umgebungsumfang, Datenklassifizierung und Auswirkungen auf die Wiederherstellung.
Die Wiederherstellung braucht eine eigene Kontrollgrenze. Löschschutz, getrennt verwaltete Backups, gegebenenfalls unveränderliche oder versionierte Kopien und geplante Wiederherstellungstests verringern das Risiko, dass eine autorisierte Sitzung Dienst und Rückweg zugleich entfernt. AWS bietet geplante Wiederherstellungstests für unterstützte Dienste wie Amazon RDS an. Ein erfolgreicher Backup-Auftrag zeigt, dass ein Wiederherstellungspunkt existiert. Ein erfolgreicher Wiederherstellungsauftrag zeigt, dass AWS die Ressource wiederherstellen konnte; eine eigene Validierung muss bestätigen, dass das wiederhergestellte System wie vorgesehen arbeitet.
Das Entscheidungsprotokoll sollte die verwendeten Nachweise, Identität, vorgeschlagenen und ausgeführten Befehle, Werkzeugergebnisse, Richtlinienprüfungen, Genehmiger, ausgegebenen Zugangsdaten, Ergebnisse und Wiederherstellungshandlungen festhalten. Ein Chatprotokoll reicht Technik- und Sicherheitsteams nicht, um zu verstehen, warum sich die Produktion geändert hat.
Begrenzte Automatisierung Behält Ihren Platz
Wer jede Ausführungsbefugnis entfernt, nimmt Coding-Agenten einen großen Teil ihres Nutzens. Die Grenze sollte der Folge entsprechen.
Eine isolierte Entwicklungsumgebung verträgt oft automatische Dateiänderungen, Tests, Paketinstallationen und Bereinigung, weil die Zugangsdaten begrenzt sind und die Umgebung neu aufgebaut werden kann. Auch eine risikoarme Produktionsänderung kann für begrenzte Automatisierung geeignet sein, nachdem repräsentative Tests zeigen, dass der Ablauf festgelegte Akzeptanzschwellen erfüllt und die Organisation die Handlung innerhalb ihres Betriebsziels rückgängig machen kann.
Destruktive Infrastrukturarbeit liegt außerhalb dieser Grenze. Kann ein Befehl eine Datenbank löschen, Identitätsrichtlinien verändern, ein Geheimnis offenlegen, eine Sicherheitskontrolle abschalten oder den Wiederherstellungsweg beschädigen, sollte der Agent Nachweise und eine Empfehlung vorbereiten. Er sollte nicht allein alle Rechte zur Ausführung besitzen.
Unsere Analyse, warum ein Red-Team-Test keinen KI-Agenten freigeben kann, führt zum selben Betriebsprinzip. Sicherheitstests liefern Nachweise. Produktionsbefugnis hängt jedoch vom bereitgestellten Ablauf, seinen aktuellen Rechten und der Reaktion auf eine versagende Schutzmaßnahme ab.
Wie KI-Coding-Agenten Produktionsbefugnis Erlangen Sollten
Die Löschung im Februar bleibt im Gedächtnis, weil terraform destroy den Fehler sofort sichtbar machte. Viele Fehler von Coding-Agenten werden weniger auffallen, sofern sie kurzfristig überhaupt entdeckt werden. Möglich sind eine geschwächte Zugriffsregel, eine ungeprüft akzeptierte Abhängigkeit, ein Geheimnis im Protokoll oder ein Release auf Grundlage veralteter Nachweise.
Verlangen Sie vor dem Produktionszugriff klare Antworten. Welchen Nachweisen darf der Agent vertrauen, und wie wird deren Aktualität geprüft? Welche Identität und welche Zugangsdaten führen die Handlung aus? Welche Folgen verlangen eine unabhängige Genehmigung? Kann dieselbe Sitzung den Wiederherstellungsweg beschädigen? Bleibt eine Antwort unklar, sollte der Ablauf auf der Stufe der Entscheidungserweiterung bleiben.
Wenn Ihr Team die Produktionsbefugnis eines Coding-Agenten festlegt, kann Evodant die Nachweise, Richtlinien, Berechtigungen und Wiederherstellungskontrollen rund um diesen Ablauf definieren. Vereinbaren Sie ein Beratungsgespräch.