Das Wichtigste in Kürze
Bei AgentCore war der Schadensradius eines einzelnen Agenten die ganze Region. Am 8. Oktober 2026 veröffentlichte Zenity Labs AgentCorruption, eine Kette von Schwachstellen in Amazon Bedrock AgentCore. Die Forscher baten einen öffentlich erreichbaren Agenten mit Web- oder Shell-Tool, den Instance Metadata Service auszulesen, erhielten die temporären Zugangsdaten seiner Ausführungsrolle und nutzten sie vom eigenen Rechner aus. Weil die Standardrolle das gesamte Konto und die gesamte Region abdeckte, reichten diese Zugangsdaten bis zu jedem anderen Agenten.
Von dort aus listeten die Forscher alle Agenten auf, luden deren Container-Images und Quellcode herunter, riefen interne Agenten auf, für die sie keine Berechtigung hatten, lasen private Konversationen, zogen API-Schlüssel und OAuth-Tokens aus dem AWS Secrets Manager und pflanzten gefälschte Langzeit-Erinnerungen ein, die spätere Antworten umlenkten. Eine CVE wurde nicht vergeben.
Wie konnte ein Prompt alle Agenten übernehmen?
Der Einstieg war gewöhnliche Agenten-Funktionalität. Viele AgentCore-Agenten erhalten ein Tool, das Web-Anfragen stellen oder Shell-Befehle ausführen kann – genau das macht sie nützlich. Laut dem Bericht von Zenity blockierten die Laufzeiten hinter diesen Agenten den Datenverkehr zum Metadaten-Endpunkt nicht. Eine Bitte in natürlicher Sprache genügte, damit der Agent Access Key, Secret Key und Session-Token der Ausführungsrolle abrief.
Die zweite Schwäche machte aus einem einzigen geleakten Zugangsdatensatz die Kompromittierung der ganzen Flotte. Die Standard-Ausführungsrolle galt für das gesamte Konto und die gesamte Region statt für einen einzelnen Agenten. Damit konnten die Forscher jeden Agenten auflisten, Code und Images abziehen, interne Agenten aufrufen, gespeicherte Konversationen und das Langzeitgedächtnis lesen und Secrets Manager abfragen. Der letzte Schritt war Persistenz: Sie schrieben gefälschte Memory-Events, sodass Agenten vor jeder Antwort eine vom Angreifer kontrollierte Seite aufriefen. The Next Web und The Decoder berichteten am 8. Oktober über die Kette und beriefen sich auf die vierteilige technische Serie von Zenity.
Was hat AWS geändert und was sagt AWS dazu?
AWS hat den Bericht nicht als Schwachstelle eingestuft. In einer von The Next Web und The Decoder zitierten Stellungnahme heißt es, ein Agent könne nur dann auf Ressourcen in einem anderen AWS-Konto zugreifen, wenn der Entwickler sowohl auf der Ausführungsrolle als auch auf der Zielressource ausdrücklich Berechtigungen erteilt; Kunden sollten Ausführungsrollen nur die Rechte geben, die ihre Agenten benötigen. Nach Angaben von Zenity schloss AWS die Meldung zum Metadatenzugriff zunächst als „informativ“.
Die Voreinstellungen haben sich trotzdem bewegt. Neue Agenten werden seit dem 14. Februar 2026 nur noch mit IMDSv2 bereitgestellt, und bei einer letzten Prüfung am 29. September 2026 stellte Zenity fest, dass die Standardrolle die Rechte zum Aufrufen anderer Agenten, zum Lesen privater Konversationen und zum Zugriff auf Secrets Manager verloren hatte. Entscheidend für Kunden: Eine geänderte Voreinstellung schützt neue Deployments – nicht Rollen, die in Ihren Konten bereits existieren.
Was das für Software-Teams in den USA und der EU bedeutet
Erstens: Die Tools eines Agenten sind ein Angriffspfad zur Cloud-Steuerungsebene. Ein Web-Fetch- oder Shell-Tool an einem öffentlich erreichbaren Agenten ist funktional dasselbe Risiko wie eine Server-Side-Request-Forgery-Lücke (SSRF) in einer Web-App. Wer mit dem Agenten chatten kann, kann versuchen, ihn zu internen Endpunkten zu lenken. Bedrohungsmodelle für KI-Agenten müssen jeden Prompt eines nicht vertrauenswürdigen Nutzers als potenziell feindliche Eingabe behandeln, nicht als Gespräch.
Zweitens: „Dokumentiertes Verhalten“ lässt das Risiko bei Ihnen. Im Modell der geteilten Verantwortung sieht AWS Least-Privilege-Rollen als Aufgabe des Kunden. Für SOC-2-, ISO-27001- und NIS2-Prüfungen heißt das: Ein Agent mit regionsweiter Rolle ist Ihr Befund, nicht der Ihres Anbieters. Teams, die KI-Agenten für den Produktivbetrieb entwickeln, sollten eine Rolle pro Agent vorsehen, zugeschnitten auf genau die Ressourcen, die er nutzt, und Secrets außer Reichweite des Agenten halten, sofern kein konkretes Tool sie braucht.
Drittens: Das Gedächtnis von Agenten gehört jetzt zum Datenschutz-Scope. Vergiftetes Langzeitgedächtnis übersteht Neustarts und kann Nutzer unbemerkt umlenken. Gespeicherte Konversationen enthalten häufig personenbezogene Daten im Sinne der DSGVO, und unbefugtes Auslesen wäre eine meldepflichtige Datenschutzverletzung. Memory-Speicher brauchen Integritätsprüfungen, Audit-Logs und Aufbewahrungsregeln – wie jede andere Datenbank mit Kundendaten.
Was bedeutet das für den DACH-Markt?
Im DACH-Raum laufen viele KI-Agenten-Projekte gerade auf AWS, weil Unternehmen Bedrock-Modelle in EU-Regionen wie Frankfurt nutzen und Datenresidenz als erledigt abhaken. AgentCorruption zeigt, dass der Standort der Daten nicht die Frage beantwortet, wer innerhalb des Kontos an sie herankommt: Ein falsch geschnittener Rollen-Scope öffnet Konversationen und Secrets unabhängig davon, in welchem Rechenzentrum sie liegen. Für Mittelständler, Versicherer und Banken, die Kundenservice- oder Sachbearbeitungs-Agenten öffentlich erreichbar machen, gehört deshalb das IAM-Design jedes Agenten in die Freigabe – nicht nur die Regionsauswahl.
Der rechtliche Rahmen ist bekannt: Werden über einen kompromittierten Agenten personenbezogene Daten ausgelesen, gilt die 72-Stunden-Meldefrist an die Aufsichtsbehörde nach Art. 33 DSGVO. Finanzunternehmen müssen schwerwiegende IKT-Vorfälle zusätzlich nach DORA melden, und deren Pflichten zum IKT-Drittparteienrisiko verlangen, dass Sie die Voreinstellungen Ihres Cloud-Anbieters aktiv überprüfen statt sie zu übernehmen. In der Schweiz verlangt das revidierte Datenschutzgesetz (revDSG) bei Verletzungen mit hohem Risiko eine Meldung an den EDÖB „so rasch als möglich“. Praktisch heißt das für Teams in Deutschland, Österreich und der Schweiz: Ausführungsrollen von Agenten gehören ins Berechtigungskonzept und in die ISMS-Audits wie jeder andere privilegierte Service-Account.
Was sollten AgentCore-Nutzer jetzt prüfen?
- Ausführungsrollen inventarisieren. Jeden AgentCore-Agenten und die Rolle, unter der er läuft, auflisten. Jede Rolle markieren, die sich mehrere Agenten teilen, und jede Rolle mit Wildcard-Ressourcen über Konto oder Region.
- Die alte Standardrolle ersetzen. Pro Agent eine eigene Rolle mit genau den Aktionen und Ressourcen-ARNs anlegen, die er braucht. Rechte zum Aufrufen anderer Agenten, zum Lesen fremder Sessions und Memories sowie zum Auflisten oder Lesen nicht benötigter Secrets entfernen.
- IMDSv2 bestätigen und Metadatenzugriff sperren, wo möglich. Prüfen, dass ältere Agenten nur mit IMDSv2 laufen, und den ausgehenden Verkehr der Tools so beschränken, dass Web- und Shell-Tools keine Link-Local-Adressen wie 169.254.169.254 erreichen.
- Öffentlich erreichbare Agenten zuerst prüfen. Agenten, die Kunden oder anonyme Nutzer erreichen, tragen das höchste Risiko. Shell-Tools entfernen, sofern sie nicht unverzichtbar sind, und Web-Tools auf freigegebene Domains beschränken.
- Memory und Logs prüfen. In CloudTrail nach unerwarteten Memory-Events, ungewöhnlichen Agent-zu-Agent-Aufrufen und Secrets-Manager-Zugriffen von unbekannten IP-Adressen suchen. Jedes Secret rotieren, das ein überprivilegierter Agent lesen konnte.
Häufige Fragen
Was ist AgentCorruption?
AgentCorruption ist eine Kette von Schwachstellen in Amazon Bedrock AgentCore, die Zenity Labs am 8. Oktober 2026 veröffentlicht hat. Ein einziger Prompt an einen öffentlich erreichbaren Agenten ermöglichte es den Forschern, die Zugangsdaten seiner Ausführungsrolle aus dem Instance Metadata Service abzurufen und damit jeden AgentCore-Agenten im selben AWS-Konto und in derselben Region zu steuern.
Hat AWS das AgentCore-Problem behoben?
AWS hat die Voreinstellungen geändert statt einen Patch zu veröffentlichen. Neue Agenten nutzen seit dem 14. Februar 2026 nur noch IMDSv2, und bis zum 29. September 2026 erlaubte die Standard-Ausführungsrolle weder das Aufrufen anderer Agenten noch das Lesen privater Konversationen oder den Zugriff auf Secrets Manager. AWS bezeichnet das Verhalten als erwartet und dokumentiert; eine CVE wurde nicht vergeben.
Sind Agenten, die vor den Änderungen angelegt wurden, weiterhin gefährdet?
Das kann sein. Eine neue Voreinstellung schützt neue Deployments, bestehende Rollen behalten aber die Berechtigungen, mit denen sie angelegt wurden. Teams sollten die Ausführungsrolle und die Metadaten-Einstellungen jedes Agenten prüfen, statt anzunehmen, dass das Update auch für sie gilt.
Worauf konnte ein Angreifer zugreifen?
In den Tests von Zenity: Container-Images und Quellcode anderer Agenten, interne Agenten ohne Berechtigung, private Konversationen und Langzeit-Erinnerungen sowie API-Schlüssel, OAuth-Tokens und andere im AWS Secrets Manager gespeicherte Secrets. Außerdem pflanzten die Forscher gefälschte Erinnerungen ein, um dauerhaft die Kontrolle zu behalten.
Wie senken wir das Risiko für unsere KI-Agenten?
Jedem Agenten eine eigene Least-Privilege-Ausführungsrolle geben, den Zugriff der Tools auf Link-Local-Metadatenadressen sperren, Web- und Shell-Tools an öffentlich erreichbaren Agenten begrenzen, Secrets außer Reichweite halten, sofern kein Tool sie braucht, und CloudTrail auf ungewöhnliche Agenten-Aufrufe und Secrets-Manager-Zugriffe überwachen.
Quellen
Zenity — Zenity Labs discloses AgentCorruption, a chain of AWS AgentCore flaws
Zenity Labs — AgentCorruption: initial IMDS access
The Next Web — One prompt let researchers take over every AWS AgentCore agent in a region
The Decoder — A single prompt was enough to hijack every AI agent in an AWS account
Dark Reading — ‘AgentCorruption’ puts AWS environments at risk with a single prompt