AgentCorruption: Ein Prompt, alle AWS-Agenten

Die Sicherheitsforscher von Zenity Labs haben am 08.10.2026 eine Angriffskette auf Amazon Bedrock AgentCore veröffentlicht, AWS' Plattform für den Betrieb von KI-Agenten. Sie nennen sie AgentCorruption. Wer mit einem einzigen öffentlich erreichbaren Agenten chatten konnte, kam mit einer Nachricht an dessen AWS-Zugangsdaten. Mit denen ließen sich alle AgentCore-Agenten im selben Konto und in derselben Region erreichen: Quellcode, private Gespräche, Gedächtnis und hinterlegte API-Keys.

Der Einstieg ist seit Februar erschwert, die zu breite Standardrolle hat AWS laut Zenity irgendwann zwischen Juni und Ende September beschnitten. AWS selbst sieht darin keine Schwachstelle. Für alle, die Agenten in der Cloud betreiben, steckt in dem Fall trotzdem mehr als eine AWS-Meldung.

Wie die Kette funktioniert

Neu ist an dem Angriff nur der erste Schritt, nämlich dass ein Satz im Chat genügt. Der Rest ist ein Muster, das Cloud-Teams seit Jahren kennen.

flowchart TB
  A([Angreifer chattet mit<br/>öffentlichem Agenten]) --> B(Agent ruft per HTTP- oder Shell-Tool<br/>169.254.169.254 ab)
  B --> C(Metadatendienst liefert temporäre<br/>Zugangsdaten der Ausführungsrolle)
  C --> D(Angreifer nutzt die Zugangsdaten<br/>auf dem eigenen Rechner)
  D --> E{Wie weit reicht<br/>die Rolle?}
  E --->|"Standardrolle,<br/>regionsweit"| F(Alle Agenten finden, Images laden,<br/>fremde Agenten aufrufen, Gespräche lesen,<br/>Gedächtnis manipulieren, Secrets holen)
  E --->|"eigene Rolle,<br/>eng gefasst"| G(Schaden bleibt bei<br/>diesem einen Agenten)
  classDef check fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A
  classDef bad fill:#7F1D1D,stroke:#EF4444,color:#FCA5A5
  classDef good fill:#14532D,stroke:#22C55E,color:#86EFAC
  class E check
  class F bad
  class G good

Schritt 1, die Zugangsdaten. Jeder AgentCore-Agent läuft in einer eigenen Firecracker-microVM. Darin gibt es einen Metadatendienst, der wie bei EC2 unter 169.254.169.254 antwortet und temporäre Zugangsdaten für die Rolle des Agenten ausgibt. Die Forscher bauten einen einfachen Agenten mit dem Strands SDK und dessen eingebautem http_request-Tool und baten ihn im Chat, die Metadaten abzurufen und an einen eigenen Server zu schicken. Der Agent tat es. Mit dem Shell-Tool ging es genauso. Zenity dazu: "The isolation failure is at the platform level, not the tool level, so anything that can generate outbound traffic reaches IMDS just the same."

Schritt 2, die Rolle. Die Zugangsdaten gelten auch außerhalb der Plattform. Entscheidend war deshalb, was die standardmäßig angehängte Ausführungsrolle durfte. Laut Zenity war sie nicht auf den einen Agenten zugeschnitten, sondern galt für alle AgentCore-Ressourcen der Region:

Schritt 3, die Dauerhaftigkeit. Am unangenehmsten ist der Gedächtnis-Teil. Die Forscher schrieben Einträge in das Langzeitgedächtnis fremder Agenten, die den Agenten anwiesen, vor jeder Antwort eine vom Angreifer kontrollierte URL abzurufen und den Anweisungen dort zu folgen. Gestohlene Zugangsdaten laufen nach Stunden ab, ein vergiftetes Gedächtnis bleibt. Der Nutzer redet weiter mit einem scheinbar vertrauten Firmen-Agenten.

Was AWS geändert hat und was AWS dazu sagt

Wann genau AWS die Rolle geändert hat, weiß Zenity nicht, nur dass es zwischen dem 22.06. und dem 29.09.2026 passiert ist. Zenitys Meldung zur Rolle lag da schon mehr als fünf Monate bei AWS.

AWS widerspricht der Einordnung. Gegenüber CSO Online und The Next Web erklärte ein Sprecher, die Forschung stelle "expected and documented behavior" fälschlich als Schwachstelle dar, und: "As a best practice, we recommend that customers grant their execution roles only the permissions their agents need."

Dokumentiert ist das Verhalten tatsächlich. In der AgentCore-Doku steht: "any code or actor running inside the VM can access these credentials by calling the metadata endpoint." Damit sagt AWS selbst, dass die Zugangsdaten für alles erreichbar sind, was in der VM läuft, also auch für einen Agenten, der sich per Prompt steuern lässt. Die eigentliche Grenze ist die Rolle. Und genau die war in der Voreinstellung so weit gefasst, dass sie keine Grenze war. Darauf geht die Stellungnahme nicht ein.

Was ihr jetzt prüfen solltet

Wenn ihr AgentCore nutzt:

1. Ausführungsrollen ansehen, vor allem ältere. Zenity beschreibt, dass die Standardrolle heute enger ist. Ob AWS bereits vorhandene Rollen nachträglich angepasst hat, geht aus den Berichten nicht hervor. Im Beispiel der Forscher hieß die Rolle AmazonBedrockAgentCoreSDKRuntime-<Region>-<Hash>. Sucht in IAM nach diesem Muster und prüft die Policies auf die Berechtigungen aus der Tabelle oben, besonders auf Ressourcen mit *.
2. Eine Rolle pro Agent, auf dessen eigene Ressourcen beschränkt. Ein öffentlich erreichbarer Agent darf nicht dieselbe Rolle tragen wie ein interner mit Zugriff auf Kundendaten.
3. Images als kompromittiert betrachten, wenn die alte Rolle im Einsatz war. Was in einem Container-Image an Keys, .env-Dateien oder internen Endpunkten lag, war mit der alten Rolle lesbar. Im Zweifel Secrets rotieren.
4. Langzeitgedächtnis stichprobenartig prüfen, wenn ihr AgentCore Memory nutzt und ein Agent öffentlich erreichbar war. Hinweise auf einen tatsächlichen Angriff außerhalb der Forschung gibt es in den Berichten nicht.

Wenn ihr Agenten woanders betreibt, gilt dieselbe Logik. Der Metadatendienst existiert bei jedem großen Cloud-Anbieter, und ein Agent mit HTTP- oder Shell-Tool erreicht ihn, wenn die Plattform es nicht verhindert. Drei Fragen lohnen sich für jeden Agenten in eurer Umgebung: Unter welcher Identität läuft er? Was darf diese Identität, wenn jemand anderes sie in die Hand bekommt? Und welche anderen Agenten, Gespräche und Secrets liegen in ihrer Reichweite?

Einordnung

Das Muster ist dasselbe wie beim Capital-One-Einbruch von 2019: eine Anfrage an den Metadatendienst, gestohlene Rollen-Zugangsdaten, eine Rolle mit zu vielen Rechten. Damals brauchte es dafür eine Lücke in einer Webanwendung. Hier genügt ein Agent, der tut, worum man ihn bittet. Prompt Injection ist in dieser Kette der Türöffner. Den Schaden richtet die geteilte Standardrolle an, ein Cloud-Fehler, den es schon vor den Agenten gab.

Dass es um die Identität des Agenten geht und nicht um die Stärke der Sandbox, haben wir schon beim Fall Agent ruft Agent gesehen: Auch dort war der öffentliche Agent harmlos, bis er etwas Privilegiertes erreichen konnte. In den OWASP Top 10 für agentische KI deckt der Fall gleich zwei Einträge ab: ASI03 (Identity & Privilege Abuse) und, mit dem vergifteten Gedächtnis, ASI06 (Memory & Context Poisoning).

AWS hat recht damit, dass enge Rollen Aufgabe der Kunden sind. Nur übernehmen die meisten Teams, was die Plattform beim ersten Deployment anlegt. Wenn die Voreinstellung jedem Agenten die Rechte aller gibt, hilft der Verweis auf die Best Practice in der Doku wenig. Dass AWS die Rolle inzwischen geändert hat, spricht dafür, dass man das dort ähnlich sieht.