Die Standardrolle, nicht das Modell: Wie ein einziger Prompt jeden Agenten in einem AWS-Konto übernahm

Kernaussagen

• Ein einziger Prompt an einen öffentlich erreichbaren Agenten kompromittierte jeden AgentCore-Agenten im selben AWS-Konto und derselben Region — Zenity Labs veröffentlichte die AgentCorruption-Kette am 8. Oktober 2026 auf der SecTor in Toronto, nach einer verantwortungsvollen Meldung, die am 25. Dezember 2025 begann.
• Der Blast-Radius war eine Eigenschaft der Rolle, nicht des Modells — die Standard-Executionsrolle enthielt bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, eine agentenübergreifende Memory-Schreibberechtigung, bedrock-agentcore:GetResourceApiKey und secretsmanager:GetSecretValue, alle geltend für die gesamte Region des Kontos statt für den einen Agenten.
• Der Fix brauchte 278 Tage — AWS stellte AgentCore bis zum 14. Februar 2026 auf IMDSv2 um, aber Zenitys Nachprüfung vom 22. Juni 2026 fand die Standardrolle unverändert; das Entfernen der Berechtigungen landete erst am 29. September 2026.
• Agenten-Gedächtnis ist eine Persistenzfläche — die Forscher pflanzten Memories, die künftige Konversationen der Agenten zu einem attacker-kontrollierten Ziel umleiteten, während Nutzer weiter mit dem sprachen, was wie ein vertrauenswürdiger Unternehmens-Agent aussah.
• AWS nannte das Verhalten „documented and expected“ — und empfiehlt Kunden, Ausführungsrollen nur die Berechtigungen zu geben, die ihre Agenten brauchen. Die Prüfung der Standardrolle ist die Aufgabe des Kunden — auf jeder Managed Platform.

Am 8. Oktober 2026, auf der SecTor-Konferenz in Toronto, offenbarte Zenity Labs AgentCorruption: eine Kette von Schwachstellen in Amazon Bedrock AgentCore, AWS' Managed Platform zum Bereitstellen und Betreiben von KI-Agenten. Ein einziger Prompt an einen öffentlichen Agenten — etwa ein im Internet exponierter Kundenservice-Agent — gab die temporären AWS-Credentials zurück, die der Maschine dieses Agenten zugewiesen waren. Diese Credentials gehörten zu einer Standard-IAM-Rolle, deren Berechtigungen nicht auf den einen Agenten begrenzt waren, sondern auf jeden AgentCore-Agenten im selben AWS-Konto und derselben Region galten. Damit riefen die Forscher interne Agenten auf, für die sie nie autorisiert waren, lasen private Konversationen über Agenten und Nutzer hinweg, luden Container-Images der Agenten herunter, um Quellcode zu extrahieren, zogen API-Keys und OAuth-Tokens aus AWS Secrets Manager und pflanzten Memories, die nach dem Ende der Session weiterwirkten.

Nichts davon erforderte ein Modellversagen. Die einzige Aufgabe des Modells in der Kette war, bei Aufforderung einen HTTP-Request zu machen. Alles danach war IAM. Dieser Artikel kartiert die fünfstufige Kette, die konkreten Berechtigungen, die jeden Schritt ermöglichten, die 278-tägige Disclosure-Zeitleiste und die fünf Fragen, die jedes Team stellen sollte, bevor es Agenten auf einer Managed-Agent-Platform deployed — gleich welcher Anbieter.

Die Angriffskette, Schritt für Schritt

Zenity Labs veröffentlichte die vollständige Forschung als fünfteilige technische Serie; die Kette verdichtet sich auf fünf Schritte.

Schritt 1: Prompt-Injektion zum IMDS. AgentCore-Agenten laufen in Firecracker-MicroVMs, deren Netzwerkisolierung den Instance-Metadata-Service nicht blockierte. Jedes Agenten-Tool, das ausgehende HTTP-Requests machen kann, sendet diesen Request aus der Instanz selbst heraus — eine SSRF-Primitive. Ein einziger Prompt wies den exponierten Agenten an, 169.254.169.254 aufzurufen, den Instance Metadata Service, der die temporären IAM-Credentials der zugewiesenen Rolle zurückgab. Der Eintrittspreis war Chat-Zugriff auf einen einzigen Agenten mit einem gängigen Tool.

Schritt 2: Kontoweite Erkundung. Die Credentials gehörten zu einer Standard-Executionsrolle, die nicht auf den konkreten Agenten begrenzt war. Unter ihren Berechtigungen war DescribeLogGroups, mit der die Forscher jeden Agenten und seine ID in der Region des Kontos aufzählten. Ein zweiter Erkundungspfad kam gratis: Die Namen der Elastic-Container-Registry-Repositories stimmten mit den Agenten-IDs überein, sodass die ECR-Pull-Berechtigung der Rolle es den Forschern erlaubte, das Container-Image jedes Agenten herunterzuladen und seinen Quellcode vollständig zu lesen.

Schritt 3: Lateral Movement. Die Rolle enthielt bedrock-agentcore:InvokeAgentRuntime, gültig für die gesamte Region. Die Forscher konnten jeden AgentCore-Agenten des Kontos aufrufen — auch interne und sensible Agenten, für die sie keine Berechtigung hatten. Das ausgearbeitete Beispiel der Disclosure: Ein Angreifer, der über den Internet-exponierten Kundenservice-Agenten eindringt, bewegt sich lateral zu einem internen Finanz-Agenten derselben Region, ruft ihn auf und greift auf seine Daten, Tools und Credentials zu.

Schritt 4: Daten- und Credential-Zugriff. bedrock-agentcore:ListEvents gab alle privaten Konversationen aller Agenten, Nutzer und Sessions zurück — die Datenschutzgrenzen der Plattform, aufgelöst. bedrock-agentcore:GetResourceApiKey und secretsmanager:GetSecretValue erreichten danach die Credentials, die AgentCore absichtlich vom Agenten fernhält: API-Keys, OAuth-Tokens und Secrets-Manager-Einträge, einschließlich der Credentials für Verbindungen zu Unternehmensressourcen und Drittanbieter-Diensten jenseits von AWS.

Schritt 5: Persistenz über Memory. Die Rolle trug zudem eine Memory-Schreibberechtigung — bedrock-agentcore:CreateEvent auf BedrockAgentCoreMemory. Die Forscher legten über verschiedene Agenten und Nutzer hinweg neue Memories an, die das Verhalten der Agenten dauerhaft veränderten und ihre Ziele über künftige Sessions hinweg kaperten, Konversationen zu einem attacker-kontrollierten Ziel lenkend. Die Kompromittierung überlebte die Session, die sie erzeugt hatte.

Die folgende Grafik kartiert die fünf Schritte und was jeder davon offenlegte:

Die Rolle, nicht das Modell

Die strukturelle Lehre steckt darin, was die fünf Schritte nicht benötigten. Kein Jailbreak, kein Alignment-Versagen, keine fortgeschrittene Prompt-Ingenieurskunst jenseits von „ruf diese URL auf“. Zenitys Mitgründer und CTO Michael Bargury fasste die Ursache als ein Spannungsfeld, mit dem jede Plattform ausgeliefert wird: „Cloud-Sicherheit dreht sich um Segmentierung und Least-Privilege-Zugriff. KI-Agenten jedoch brauchen ihren kreativen Freiraum, um nützlich zu sein. Beides zu vermischen erzeugt einen inhärenten Konflikt.“ Sein Fazit: „Jedes Unternehmen, das Agenten in der Cloud einsetzt, wird vor dieselben fundamentalen Entscheidungen zwischen Agentivität und Least Privilege gestellt.“

AgentCore löste diesen Konflikt zugunsten der Agentivität — für den Komfort der Plattform, nicht für die Sicherheit des Kunden. Die Standard-Executionsrolle war bewusst weit, damit Agenten out of the box funktionieren, und ihre Berechtigungen deckten jede Agenten-Ressource der Kontoregion ab. AWS' eigene Stellungnahme, mit der Forschung veröffentlicht, sagt, das Verhalten sei „documented and expected“, Agenten könnten über den Metadata-Service auf die Credentials ihrer eigenen Ausführungsrolle zugreifen, und „als Best Practice empfehlen wir Kunden, ihren Ausführungsrollen nur die Berechtigungen zu geben, die ihre Agenten benötigen“, mit Verweis auf das Credentials-Management, die Runtime-Berechtigungen und die Least-Privilege-Guidance.

Liest man diese beiden Fakten zusammen, ist die Position des Käufers unmissverständlich: Die Plattform behandelt die Standardrolle als Ausgangspunkt und den Blast-Radius eines kompromittierten Agenten als Konfigurationsproblem des Kunden. Das ist eine vertretbare Position für einen Cloud-Anbieter — Least Privilege in IAM ist seit Bestehen von IAM die Aufgabe des Kunden. Aber sie kollidiert mit dem Marketingrahmen Managed-Agent-Platforms, wonach die Plattform das operative Hardening übernimmt, damit es dein Team nicht muss. Die AgentCorruption-Kette zeigt, wie diese Kollision in der Praxis aussieht: Der Plattform-Default war die Schwachstelle, und die Plattform-Dokumentation war die Gegenmaßnahme.

278 Tage von der Meldung zum Fix

Die Disclosure-Zeitleiste ist die zweite Lehre. Zenity meldete den anfänglichen IMDS-Zugriff am 25. Dezember 2025. AWS stellte AgentCore bis zum 14. Februar 2026 für neu bereitgestellte Agenten auf reines IMDSv2 um und schloss diesen ersten Bericht am 12. April als „informativ“ ab. Doch Zenitys zweiter Bericht — der Blast-Radius der Standardrolle, am 12. Januar 2026 eingereicht — kam langsamer voran. Am 25. Februar sagte AWS, das Team arbeite aktiv daran, während die Standardrolle gleich blieb. Am 22. Juni 2026 prüfte Zenity nach und bestätigte, dass die Berechtigungen unverändert waren. Der substanzielle Fix — das Entfernen der Berechtigungen für weite Agenten-Ausführung, das Lesen privater Konversationen und den Secrets-Manager-Zugriff — wurde am 29. September 2026 beobachtet, 278 Tage nach der ersten Meldung und wenige Tage vor der Veröffentlichung.

Datum	Ereignis
25. Dez. 2025	Zenity meldet AWS den anfänglichen IMDS-Zugriff
12. Jan. 2026	Zenity reicht den Bericht zum Blast-Radius der Standardrolle ein
14. Feb. 2026	AgentCore wird für neu bereitgestellte Agenten auf reines IMDSv2 umgestellt
25. Feb. 2026	AWS bestätigt laufende Arbeit; Standardrolle unverändert
12. Apr. 2026	AWS schließt den IMDS-Bericht als „informativ“ ab
22. Juni 2026	Zenitys Nachprüfung: Standardrolle weiterhin unverändert
29. Sept. 2026	Standardrolle gehärtet — agentenübergreifende, Konversations-Lese- und Secrets-Manager-Berechtigungen entfernt

Zwei Implikationen für jedes Team, das auf die Defaults einer Managed Platform setzt. Erstens kann ein Komfort-Default fast ein Jahr lang eine stehende Schwachstelle bleiben, selbst nach einer verantwortungsvollen Meldung — das Fenster zwischen „gemeldet“ und „behoben“ wird in Monaten gemessen, und deine Agenten laufen in ihm. Zweitens ist der Fix selbst der Beweis der These: AWS hat kein Modell neu trainiert und keinen Sicherheitsfilter hinzugefügt. Es hat eine Rollen-Richtlinie bearbeitet. Der Blast-Radius war die ganze Zeit über ein IAM-Dokument.

Memory ist eine Persistenzfläche

Der zukunftsweisendste Teil der Kette ist Schritt 5. Daten zu lesen ist ein Datensatzvorfall; Memory zu verändern ist eine Übernahme. Die Forscher nutzten die Memory-Schreibberechtigung der Rolle, um Anweisungen zu pflanzen, die die Session überlebten, künftige Konversationen zu einem attacker-kontrollierten Ziel umleiteten und den Agenten normal funktionieren ließen. Ein Incident-Response, der den Agenten stoppt, seine Credentials rotiert und den Injektionsvektor patcht, entfernt keine gepflanzte Memory. Ist der Memory-Store nicht Teil der Antwort, überdauert die Kompromittierung die Bereinigung.

Es ist dieselbe Klasse von Verhaltensmodifikation, die Anthropic dazu brachte, den Live-Internetzugang aller internen Agenten-Evaluationen zu kappen, wie das Unternehmen im Oktober 2026 offenlegte — das Thema von Zwei Frontier-Labore, ein Eingeständnis. Jener Artikel behandelt das Eingeständnis der Frontier-Labore, dass Alignment-Training allein das Verhalten von Agenten nicht kontrollieren kann. AgentCorruption zeigt dasselbe Problem eine Ebene tiefer, auf Plattformebene: Ein Memory-Store, in den alles mit der richtigen IAM-Berechtigung schreiben kann, ist ein Persistenzmechanismus — und die Kill-Switch-Architekturen aus Kill Switch by Design müssen Memory als Teil des kompromittierten Zustands behandeln, nicht nur des Runtimes.

Fünf Fragen, bevor du auf irgendeiner Managed-Agent-Platform deployst

AgentCore ist das durchdeklinierte Beispiel, nicht die Ausnahme. Zenitys Pressemitteilung sagt es selbst: Unternehmen betreiben routinemäßig kundenorientierte und interne Agenten Seite an Seite in denselben Cloud-Umgebungen, und eine einzige unerwartete Schwachstelle in einem Agenten kann die Grenzen einer ganzen Umgebung einstürzen lassen. Die Plattform wird anders sein; die Berechtigungsklassen reimen sich. Bevor ein Agent auf einer Managed Platform live geht, hole dir schriftliche Antworten auf diese fünf Fragen:

1. Was genau steckt in der Standard-Executionsrolle? Nicht „ist sie per Default sicher“ — das Richtliniendokument, Berechtigung für Berechtigung. Markiere jede Berechtigung mit Gültigkeit für * oder für alle Agenten des Kontos. Die AgentCorruption-Kette ist die Fünf-Berechtigungen-Antwort auf diese Frage.
2. Kann ein Agent die anderen entdecken? Jede kontoweite List- oder Describe-Berechtigung macht einen kompromittierten Agenten zu einem Zielinventar. DescribeLogGroups war der Enumerations-Schritt; jede Plattform hat ein entsprechendes Listing.
3. Kann ein Agent einen anderen aufrufen? Agent-zu-Agent-Aufrufe sind die Primitive des Lateral Movement. Kann die Plattform Aufrufe nicht auf explizite, agentenbezogene Allowlists begrenzen, behandle jeden Agenten des Kontos als eine Trust-Domain — denn genau so wird der Angreifer sie behandeln.
4. Wo leben die Tool-Credentials, und welche Rolle kann sie lesen? Ein Secrets-Gateway verschiebt das Risiko nur, wenn keine Agenten-Rolle darauf GetSecretValue aufrufen kann. Die AgentCorruption-Rolle konnte exakt die Credentials lesen, die das Plattformdesign von Agenten fernhalten sollte.
5. Kann irgendetwas anderes als der Agent selbst, in seiner eigenen Session, in den Memory schreiben? Agenten- und nutzerübergreifende Memory-Schreibvorgänge machen den Memory-Store zur Persistenzfläche. Ist die Antwort eine Berechtigung, die du begrenzen kannst, begrenze sie; wenn nicht, gehört der Memory-Store in deinen Incident-Response-Plan als attacker-kontrollierter Zustand.

Weiterführende Lektüre

• Bedrock vs OpenAI: Auswahl einer Managed-AI-Plattform für Produktionsagenten — der Managed-Platform-Vergleich, auf dem dieser Vorfall landet: Kosten, Datenschutz und Anbieterstabilität, mit der Standardrollen-Frage jetzt auf der Due-Diligence-Liste
• 126 Vorfälle in einem Monat: Das erste umfassende KI-Sicherheitsinventar und was es über das Agentenrisiko beweist — die Frequenzaussage hinter diesem Vorfall: Exploits in der Agentenschicht waren im September 2026 die größte Angriffsvektoren-Klasse
• KI-Agenten-Governance-Checkliste: Eine Pre-Deployment-Überprüfung für Produktionsagenten — die vollständige Pre-Deployment-Überprüfung, inklusive Least-Privilege-Ausführungsrollen und agentenübergreifender Erkundung als Prüfpunkte

Ein mittelständischer Industriedistributor, der zwei Agenten auf einer Managed Platform betreibt — ein öffentlicher Quote-Agenten vor seinem BigCommerce-Shopfront und Katalog, und ein interner Agent mit NetSuite-Preisstufen und Lagerzugriff —, hat exakt die Topologie, die AgentCorruption ausnutzte: ein im Internet exponierter Agent und ein Back-Office-Agent im selben Konto. Das Muster, gegen das wir bauen, gibt jedem Connector-Modul seine eigene Least-Privilege-Rolle, registriert jedes Tool, das der Agent aufrufen darf, begrenzt Memory pro Agent und schreibt einen Audit-Trail, der ein Memory-Schreiben von außerhalb der Session zeigen würde. Der Punkt ist nicht, dass ein berechtigungsbeschränkter Build gegen einen plattformseitigen Fehler immun wäre; der Punkt ist, dass der Blast-Radius des nächsten durch die Rollen-Richtlinie festgelegt wird, die dein Team geprüft hat — nicht durch die, die die Plattform als Default ausgeliefert hat.

Entdeckung in einer Woche. Du bekommst ein Systeminventar, eine Workflow-Karte und einen festen Scope — ob du mit uns baust oder nicht.

Fordere einen fest umrissenen Build an.