Der Vorfall rüttelte ein Team wach, das sein gesamtes AWS-Zugriffsmodell auf der Annahme aufgebaut hatte, dass nur vorsichtige Menschen jemals Produktionsschlüssel besitzen würden. Da KI-Agenten nun in den Workflow jedes Entwicklers eingebettet sind, erwies sich diese Annahme als falsch. Das Unternehmen reagierte mit der Einrichtung eines „Access Brokers“, der jede Operation auf Produktionsebene dazu zwingt, einen „Human-in-the-loop“-Genehmigungsschritt zu durchlaufen.
Wie es zum Unfall kam
Ein Ingenieur forderte einen KI-Coding-Agenten auf, ein Pipeline-Skript zu erstellen. Der Agent übernahm die IAM-Rolle des Ingenieurs für die Produktion – eine AWS-Identität, die CloudFormation-Stacks erstellen, ändern und löschen kann. Das Skript wurde ausgeführt, erstellte einen Stack in der Live-Umgebung und entfernte ihn sofort als „Cleanup“-Schritt. Da die Operation die standardmäßige CI/CD-Pipeline umging, sah die Policy-Engine, die normalerweise solche Änderungen kontrolliert, sie nie.
Die Monitoring-Plattform, die darauf eingestellt war, jede Rolle zu melden, die eine privilegierte Aktion außerhalb der genehmigten Pipeline ausführte, schlug in dem Moment Alarm, als der Stack gelöscht wurde. Es fielen keine Dienste aus, aber der Alarm verdeutlichte ein Szenario, in dem ein falsch getippter Ressourcenname oder ein fehlerhafter KI-Prompt kritische Infrastruktur hätte löschen können.
Das Team erkannte: Erkennung ist nicht gleich Prävention. Hätte die KI den falschen Stack gelöscht, wäre eine Katastrophe gefolgt.
Warum das alte Credential-Modell versagte
Der bisherige Ansatz der Organisation stützte sich auf kurzlebige Sitzungen, die durch Multi-Faktor-Authentifizierung (MFA) geschützt waren. Theoretisch würde ein Entwickler eine Sitzung anfordern, eine Aufgabe ausführen und die Anmeldedaten würden automatisch ablaufen. In der Praxis blieb eine Sitzung, sobald sie auf einem Laptop gestartet wurde, für die gesamte Laufzeit der Maschine bestehen. Jeder Prozess – Test-Suites, Hintergrundskripte und nun auch KI-Agenten – verwendete diese Anmeldedaten ohne zusätzliche Prüfung wieder.
Dieses Problem der „Ambient Credentials“ führte dazu, dass die IAM-Rolle für die Produktion fest in der Workstation des Entwicklers verankert war. Der KI-Agent, der als Unterprozess in derselben Shell lief, übernahm dieselben Berechtigungen und konnte auf Produktionsressourcen genauso zugreifen wie ein Mensch.
Der Access Broker: Ein neuer Gatekeeper
Um die Kette der Ambient Credentials zu durchbrechen, überarbeitete das Team die Architektur dafür, wer Produktionsrollen übernehmen darf. Anstatt jede Entwickler-Identität direkt eine privilegierte Rolle übernehmen zu lassen, führten sie eine einzige, streng kontrollierte Instanz ein: einen internen Access Broker.
Anfrageablauf
- Webportal – Der Ingenieur öffnet ein Self-Service-Portal, wählt die erforderliche Zugriffsebene (Read-only, Developer oder Administrator) aus und gibt eine Begründung an.
- Slack-Freigabe – Die Anfrage wird in einen dedizierten Slack-Kanal gepostet, in dem ein benannter Genehmiger die Erlaubnis explizit erteilen muss.
Der Slack-Schritt fungiert als zweiter Faktor auf einer anderen Plattform als das Terminal, in dem der KI-Agent läuft. Da die Genehmigung in einer separaten Benutzeroberfläche erfolgen muss, kann ein autonomes Skript den Workflow nicht eigenständig abschließen.
Gestufter Zugriff
- Read-only – Benutzer können Ressourcen und Logs einsehen, aber nichts ändern.
- Developer – Beabsichtigt für Support-Aufgaben und Infrastruktur-Anpassungen; diese Ebene blockiert destruktive Aktionen wie das Löschen von Stacks oder den direkten Zugriff auf Kundendaten.
- Administrator – Volle Berechtigungen, reserviert für Notfallinterventionen und nur nach einer Prüfung auf höherer Ebene gewährt.
Durch die Bündelung des gesamten Produktionszugriffs über den Broker konzentrierte das Team das Risiko auf einen einzigen, stark geschützten Dienst, anstatt privilegierte Anmeldedaten auf jedem einzelnen Laptop zu verteilen.
Was der Broker tatsächlich verhindert
Der Hauptzweck des Brokers besteht darin, Ambient Credentials zu stoppen, die KI-Agenten heimlich ausnutzen könnten. Selbst wenn ein Mensch eine Anfrage genehmigt, ist diese Genehmigung eine bewusste Entscheidung; die KI kann diesen Schritt nicht fälschen. Folglich:
- Unbeabsichtigte Löschungen – Die KI kann keinen Löschbefehl mehr ausführen, es sei denn, ein Mensch hat die Sitzung explizit autorisiert.
- Credential Sprawl – Produktionsschlüssel befinden sich nicht mehr auf den Geräten der Entwickler, was die Angriffsfläche für böswillige Insider und externe Akteure, die einen Laptop kompromittieren könnten, verringert.
Das Team betont, dass das System menschliche Fehler nicht ausschließt; eine Fehlentscheidung bei einer Genehmigung kann immer noch Schaden anrichten. Es beseitigt jedoch das „stille“ Risiko, dass autonomer Code ohne menschliche Kontrolle auf Produktionsressourcen zugreift.
Fazit
Wenn KI-Agenten dieselben uneingeschränkten Berechtigungen erhalten wie menschliche Ingenieure, erben sie auch die Macht, die Produktionsumgebung lahmzulegen – oft, ohne dass es jemand bemerkt. Durch die Zentralisierung des privilegierten Zugriffs hinter einem Broker, der einen separaten menschlichen Genehmigungskanal erzwingt, kann ein Team verhindern, dass autonome Skripte im Stillen Verwüstung anrichten, selbst wenn menschliche Fehler weiterhin Probleme verursachen können. Der eigentliche Sicherheitsgewinn liegt in der Beseitigung von Ambient Credentials, nicht in der Überwachung jeder einzelnen Entscheidung.