Ein AI-Agent hat eine Produktionsdatenbank gelöscht. Was die Architektur damit zu tun hat.

Anfang März 2026 hat ein Entwickler detailliert dokumentiert, wie ein AI-Agent seine gesamte Produktionsinfrastruktur auf AWS gelöscht hat. Claude Code führte terraform destroy aus - Datenbank, VPC, ECS-Cluster, Load Balancer und sämtliche automatischen Snapshots waren weg. 1,9 Millionen Datensätze einer Kursplattform mit tausenden aktiven Nutzern. Nach 24 Stunden und einem Upgrade auf AWS Business Support konnte die Datenbank wiederhergestellt werden.

Dass der Entwickler diesen Vorfall so offen dokumentiert hat - mit Timeline, Screenshots und dem klaren Satz "This incident was my fault" - verdient Anerkennung. Die meisten hätten das still repariert und nie darüber gesprochen. Dass die Fachcommunity daraus lernen kann, ist nur möglich, weil er sich dafür entschieden hat, es zu veröffentlichen. Dieser Artikel baut auf seiner Analyse auf und versucht, das architektonische Problem dahinter einzuordnen.

Was passiert ist

Die Fehlerkette lässt sich in wenigen Schritten zusammenfassen:

Der Entwickler wollte eine statische Website von GitHub Pages nach AWS S3 migrieren. Anstatt eine separate Terraform-Konfiguration anzulegen, nutzte er die bestehende, die bereits die Produktionsinfrastruktur einer anderen Plattform verwaltete. Claude Code riet davon ab. Der Entwickler entschied sich dagegen, um etwa 5 Dollar monatlich zu sparen.

Beim Wechsel auf einen neuen Rechner fehlte die Terraform-State-Datei. Terraform ging davon aus, dass keine Infrastruktur existiert, und begann, Duplikate zu erstellen. Beim Versuch, diese Duplikate aufzuräumen, führte der Agent terraform destroy aus - allerdings mit der alten State-Datei, die auf die Produktionsinfrastruktur zeigte. Das Ergebnis war die vollständige Löschung der Produktionsumgebung, einschließlich aller automatischen Backups.

Die Reaktion

Der Entwickler hat eine Reihe von Maßnahmen umgesetzt: Deletion Protection auf Datenbank-Ebene, S3-Backups außerhalb von Terraform, tägliche automatisierte Restore-Tests, und die Verlagerung des Terraform State nach S3.

Die wichtigste Änderung: Der Agent darf keine Terraform-Befehle mehr ausführen. Jeder Plan wird manuell geprüft, jede destruktive Aktion vom Entwickler selbst ausgeführt.

Diese Maßnahmen sind sinnvoll. Deletion Protection und unabhängige Backups gehören zur grundlegenden Betriebshygiene und hätten von Anfang an vorhanden sein sollen. Die täglichen Restore-Tests gehen sogar darüber hinaus - das machen die wenigsten.

Aber die Entscheidung, dem Agent alle Ausführungsrechte zu entziehen, verdient einen genaueren Blick.

Das eigentliche Problem

Wenn ein Agent nur noch Pläne generieren darf, die ein Mensch prüft und ausführt, stellt sich die Frage, welchen Wert der Agent noch hat. Man hat dann ein aufwendiges Autocomplete für Terraform-Konfigurationen. Das mag im Einzelfall ausreichen, aber es ist keine Architektur für den Einsatz von AI-Agents in produktiven Umgebungen.

Der Konstruktionsfehler lag nicht im Verhalten des Agents. Der Agent hat getan, was das System ihm erlaubt hat. Der Fehler lag darin, dass es keine Grenze gab zwischen dem, was der Agent für seine Aufgabe brauchte, und dem, worauf er tatsächlich zugreifen konnte.

Claude Code hatte uneingeschränkte AWS-Credentials. Es gab keinen Mechanismus, der sagte: Du darfst terraform plan ausführen, aber nicht terraform destroy. Du darfst Ressourcen mit dem Tag dev anfassen, aber nicht prod. Du darfst S3-Objekte schreiben, aber keine RDS-Instanzen löschen.

Das ist kein neues Problem. Für menschliche Benutzer haben wir es vor Jahrzehnten gelöst - mit dem Prinzip der minimalen Rechte, rollenbasierter Zugriffskontrolle und scoped Tokens. Wir geben einem Datenbankadministrator nicht automatisch auch Zugriff auf die Firewall-Konfiguration. Wir geben einem Entwickler keinen Produktionszugriff ohne Review-Prozess.

Für AI-Agents wenden wir dieselben Prinzipien bisher kaum an.

Task-scoped Access für AI-Agents

Der Ansatz, an dem ich arbeite, überträgt etablierte Zugriffskontrollmuster auf die Interaktion zwischen AI-Agents und Infrastruktur. Die Kernidee ist einfach: Ein Agent bekommt nicht generelle Credentials, sondern einen Token, der auf die aktuelle Aufgabe zugeschnitten ist.

Konkret sieht das so aus:

Wenn ein Agent eine Aufgabe beginnt - zum Beispiel "deploye die statische Website nach S3" - erhält er über Keycloak Token Exchange einen kurzlebigen Token. Dieser Token gewährt Zugriff auf genau die Ressourcen, die für diese Aufgabe relevant sind: diesen S3-Bucket, diese CloudFront-Distribution, Schreibzugriff. Nicht mehr. Der Token läuft ab, wenn die Aufgabe abgeschlossen ist.

Zwischen dem Agent und der Infrastruktur sitzt ein Policy Enforcement Point - in meiner Architektur ein MCP-Server (Model Context Protocol), der jede Aktion des Agents gegen den Task-Scope prüft. Der Agent will terraform destroy ausführen? Der PEP prüft: Ist destroy eine erlaubte Aktion im aktuellen Scope? Nein. Abgelehnt. Der Agent will eine RDS-Instanz löschen? Der PEP prüft: Enthält der aktuelle Scope RDS-Ressourcen? Nein. Abgelehnt.

Das ist kein Prompt, der dem Agent sagt, er solle vorsichtig sein. Das ist eine architektonische Grenze, die der Agent nicht umgehen kann, unabhängig davon, was er entscheidet zu tun.

Für Aktionen, die außerhalb des Scope liegen, aber für die Aufgabe relevant sein könnten, gibt es einen Eskalationspfad. Der Agent meldet: "Ich müsste die VPC-Konfiguration ändern, um das Deployment abzuschließen. Das liegt außerhalb meines aktuellen Scope." Der Mensch entscheidet, ob der Scope erweitert wird oder ob er die Aktion selbst durchführt.

Für komplexere Policy-Anforderungen - etwa kontextabhängige Regeln wie "Löschungen nur während Wartungsfenstern" oder "Produktionsänderungen nur mit Vier-Augen-Prinzip" - kann OPA (Open Policy Agent) als zusätzliche Policy-Engine eingebunden werden.

Einordnung

Dieser Ansatz ist kein fertiges Produkt. Es ist ein Architektur-Pattern, das auf bewährten Sicherheitsprinzipien aufbaut und sie auf einen neuen Anwendungsfall überträgt. Die einzelnen Bausteine - Keycloak, MCP, OPA - sind ausgereift. Ihre Kombination für AI-Agent-Zugriffskontrolle ist neu und noch nicht in Produktionsumgebungen erprobt.

Was ich mit Sicherheit sagen kann: Die binäre Wahl zwischen "Agent hat vollen Zugriff" und "Agent hat keinen Zugriff" ist eine Sackgasse. Die erste Variante ist gefährlich, die zweite macht den Agent nutzlos. Dazwischen liegt die Architekturarbeit, die bisher weitgehend fehlt.

Der Terraform-Vorfall ist ein gut dokumentiertes Beispiel dafür, was passiert, wenn diese Architekturarbeit ausbleibt. Nicht weil der Entwickler nachlässig war, sondern weil die Werkzeuge und Frameworks, die wir für AI-Agents haben, diese Grenzziehung heute nicht vorsehen.

Das wird sich ändern müssen.