Ein Prompt, ein Agent, ein ganzes AWS-Konto: Einblick in AgentCorruption auf Amazon Bedrock AgentCore

Am 8. Oktober 2026, Zenity Labs gab AgentCorruption bekannt: eine Kette von Schwachstellen in Amazon Bedrock AgentCore, AWS' verwaltete Plattform zum Bereitstellen und Ausführen von KI-Agenten, die es einem einzigen natürlichsprachlichen Prompt an einen öffentlich zugänglichen Agenten ermöglichte, die Kontrolle über jeden AgentCore-Agenten im selben AWS-Konto und in derselben Region zu übernehmen. Die Forschung wurde zusammen mit einem Vortrag auf der SecTor 2026 in Toronto, wo Zenitys Direktor für Sicherheitsforschung, Tamir Ishay Sharbat, sie vorstellte (Dark Reading, 8. Oktober 2026). Zenitys eigener Bericht, der Sharbat, Lana Salameh, Dmitry Lozovoy und João Donato zugeschrieben wird, beginnt mit dem Mechanismus: Ein AgentCore-Agent, der über ein Werkzeug verfügt, das eine ausgehende Anfrage stellen kann, kann dazu gebracht werden, den AWS Instance Metadata Service (IMDS) unter der link-lokalen Adresse 169.254.169.254 aufzurufen, der temporäre Anmeldeinformationen für die eigene Ausführungsrolle des Agenten zurückgibt. Zenity gibt an, diese Anmeldeinformationen auf seinen eigenen Rechner exportiert und bestätigt zu haben, dass sie von dort aus funktionierten. Es wurde keine CVE-Kennung zugewiesen.

Das Archiv verzeichnet dies als eine Schwachstelle – etwas, das gefunden wurde, nicht unbedingt ausgenutzt – mit hohem Schweregrad, Konfidenz A, keinem dokumentierten tatsächlichen Schaden und bestätigter KI-Beteiligung. Die Parteien sind sich über die Einordnung uneinig, obwohl sie beim Verhalten übereinstimmen: AWS sagte gegenüber Dark Reading, die Untersuchung „stelle erwartetes und dokumentiertes Verhalten unzutreffend als Schwachstelle dar.“

Was die Kette eigentlich war

AgentCore verpackt jeden Agenten als Container und führt ihn in einer sitzungsspezifischen Firecracker MicroVM. Zenitys erster Beitrag in der Serie reproduziert den gesamten Einstiegspunkt mit einer in Klartext verfassten Anfrage an einen Testagenten, der mit dem Strands SDK, AWS' Open-Source-Agenten-Framework, das über ein integriertes HTTP-Anfrage-Tool und ein Shell-Tool verfügt. Die MicroVM beschränkte den Datenverkehr zum Metadatendienst nicht, sodass die Anfrage aus der Instanz selbst kam und IMDS sie beantwortete. Die Forscher durchliefen danach die Endpunkte: den IAM-Rollennamen, die temporären STS-Anmeldeinformationen selbst, den User-Data-Endpunkt — der die Konto-ID, vollständige ARNs, die Runtime-URL und die Amazon Elastic Container Registry (ECR)-Image-URI des Agenten zurückgab — und Instanz-Tags, darunter eine mTLS-Zertifikatskette, einen privaten Schlüssel und eine vorab signierte URL zum internen Speicher. Zenity sagt, dasselbe Ergebnis kam über das Shell-Tool zustande, weil der Isolationsfehler auf Plattformebene liegt und nicht in einem einzelnen Tool.

Zwei Details in dieser Abfolge sind leicht zu überlesen. Die Anmeldedaten blieben nicht auf die Sandbox beschränkt: Zenity exportierte sie außerhalb von AgentCore und führte einen AWS-Identitätsaufruf aus, der als übernommene Rolle des Agenten zurückkam. Und die gestohlene Rolle konnte das Container-Image abrufen, wodurch der Quellcode der Agenten lesbar wurde – Zenitys Beitrag merkt an, dass Images routinemäßig hartcodierte Schlüssel, übrig gebliebene Tokens und Konfigurationen enthalten, die niemals hätten eingebacken werden dürfen, und dass ein abgerufenes Image eine Karte der zugrunde liegenden Geschäftslogik ist.

Die Standardrolle ist dort, wo aus einem Standbein ein Konto wurde.

Der zweite Fehler, über den separat berichtet wurde, besteht darin, dass die Ausführungsrolle, die AgentCore standardmäßig an Agenten anhängte, nicht auf einen einzelnen Agenten beschränkt war. Zenity beschreibt Berechtigungen, die sich über jede AgentCore-Ressource im Konto und in der Region erstrecken, einschließlich bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, bedrock-agentcore:CreateEvent, bedrock-agentcore:DeleteEvent und, am Ende der Kette bei den Anmeldedaten, bedrock-agentcore:GetResourceApiKey und secretsmanager:GetSecretValue.

Die Aufzählbarkeit verwandelte diese Wildcards in eine Zielliste. Zenity nutzte die logs:DescribeLogGroups-Berechtigung der Rolle, weil AgentCore die CloudWatch-Log-Gruppe jedes Agents /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME} nennt und Agent-IDs aus diesen Log-Gruppennamen ableitete. ECR-Repository-Namen folgten einer Konvention, die die Forscher beobachteten — bedrock-agentcore-<agent_name> —, sodass jedes Agent-Image in der Region abgerufen werden konnte. Memory-Ressourcen wurden auf dieselbe Weise gefunden, aus dem Log-Gruppen-Muster /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}, und die Berechtigungen ListActors, ListSessions und ListEvents der Rolle lieferten die Actor- und Session-IDs, die benötigt wurden, um den Gesprächsinhalt zu lesen.

Zenitys Write-up liefert eine konkrete Demonstration lateraler Bewegung: Eintritt über einen öffentlich zugänglichen Agenten, Entdeckung der Tools eines billing_agent in derselben Region, Erkennung einer Datei namens billing.json und Exfiltration über ein Dateilese-Tool. Die Pressemitteilung beschreibt dasselbe Szenario in allgemeinen Worten – ein Angreifer, der über einen internetzugänglichen Kundendienst-Agenten eindringt, könnte zu einem internen Finanz-Agenten wechseln, der in derselben Region bereitgestellt ist, ihn aufrufen und auf seine Daten, Tools, zugehörige Zugangsdaten und private Konversationen zugreifen.

Das Gedächtnis war der Teil, der den Prompt überlebte.

AgentCore Memory behält die Konversation selbst als Kurzzeitgedächtnis und speichert extrahierte Datensätze als Langzeitgedächtnis, wobei Strategien namens SEMANTIC, USER_PREFERENCE, SUMMARIZATION und EPISODIC. Zenity verwendete CreateEvent, um Konversationsereignisse in die Speicherressourcen anderer Agenten zu schreiben. In seinem Beitrag wird sorgfältig erläutert, was dieses Primitiv kann und nicht kann: CreateEvent erlaubt dem Aufrufer nicht, einen Langzeit-Namespace auszuwählen oder einen Datensatz direkt zu überschreiben — die konfigurierten Strategien des Zielspeichers entscheiden, was extrahiert wird und wo es landet. Zenity beschreibt außerdem, dass DeleteEvent verwendet wird, um Tool-Ergebnis-Ereignisse zu entfernen, damit ein Agent aus fehlenden Daten eine falsche Schlussfolgerung zieht, und um Spuren zu verwischen, indem das Ereignis gelöscht wird, das eine Erinnerung eingepflanzt hat.

Was das Write-Primitive hervorbrachte, war Persistenz. Zenitys Demonstration implantierte eine Anfrage, dass der Agent vor der Antwort eine Seite abruft, die die Forscher kontrollierten, und den Inhalt dieser Seite befolgt – einen Command-and-Control-Endpunkt, dessen Anweisungen geändert werden konnten, ohne einen weiteren Speicher zu implantieren. Derselbe Kanal transportierte dann Gesprächsinhalte nach außen: Der Bericht beschreibt, wie der Agent die Nachrichten des Nutzers und seine eigenen Antworten an einen Sammel-Endpunkt sendet, und stellt fest, dass die Speicherberechtigungen der Rolle über das Konto und die Region hinweg galten und nicht nur für den kompromittierten Agenten. Ein zusammen mit der Forschung veröffentlichtes Video zeigt einen Nutzer, der ein Gespräch fortsetzt, während dieser Inhalt auf dem Server der Forscher eintrifft.

Zugangsdaten jenseits von AWS

Der letzte Beitrag der Serie schließt den Kreis zu den Tool-Anmeldedaten, die AgentCore Identity und Outbound Auth in AWS Secrets speichern, und zwar unter Namen, die aus einem Provider-Namen und einem festen Muster wie bedrock-agentcore-identity!default/apikey/{provider_name} gebildet werden. Zenity ermittelte Provider-Namen, indem es den Agent-Quellcode auswertete, den es bereits aus ECR gezogen hatte, und weitere durch Brute-Force: Dem Bericht zufolge wird das standardmäßige fünfstellige Suffix clientseitig aus Ziffern und Kleinbuchstaben erzeugt, was 2 x (10+26)^5 = 120.932.352 Kombinationen über die beiden Provider-Typen hinweg ergibt. Bei der Rate, die es gegenüber Secrets Manager aufrechterhalten konnte, dauert eine vollständige Enumeration laut Zenity mehrere Stunden – länger, als die STS-Anmeldedaten gültig bleiben –, weshalb es eine Schleife baute, die den IMDS-Endpunkt des Agents während des Ablaufs der alten Anmeldedaten erneut nach frischen Anmeldedaten abfragte. Zenity ergänzt, dass Umgebungsvariablen über den User-Data-Endpunkt der Metadaten lesbar waren, wobei jedem Namen CONTAINER_ENV_ vorangestellt war, einschließlich des Schlüssels, mit dem sich ein Agent bei seinem Modell-Provider authentifiziert, und dass das Aufrufen jedes entdeckten Agents mit einem geeigneten Prompt diese Werte in großem Umfang erntete.

Festgestellt und aus formalen Gründen bestritten.

Was feststeht, ist eng begrenzt und spezifisch. AgentCore-Agenten konnten IMDS erreichen und die temporären Anmeldedaten ihrer eigenen Ausführungsrolle erhalten – AWS bestreitet dies nicht und bezeichnet es in seiner Stellungnahme als „dokumentiert und erwartet“. Die Standard-Ausführungsrolle trug Berechtigungen, die auf das Konto und die Region statt auf einen einzelnen Agenten beschränkt waren; AWS hat sie seitdem geändert, und Zenity sagt, eigene Tests hätten die Reduzierung bestätigt. Die Untersuchung ist eine Demonstration, keine beobachtete Kampagne: Sharbat sagte gegenüber Dark Reading, Zenity habe keine Belege dafür gesehen, dass die Schwachstelle vor der Behebung in freier Wildbahn ausgenutzt wurde, was er teilweise auf die Schwierigkeit zurückführte, zu ermitteln, welche Organisationen Agenten auf AgentCore betreiben, und er fügte hinzu, er sei „100 % sicher, dass es Wege gibt, das zu tun“.

Strittig ist, ob irgendein Teil davon als Schwachstelle bezeichnet werden sollte. AWS’ Erklärung, wie sie gegenüber Dark Reading und The Next Web abgegeben wurde, lautet: „AWS ist die veröffentlichte Forschungsarbeit zu Amazon Bedrock AgentCore bekannt, die erwartetes und dokumentiertes Verhalten fälschlicherweise als Schwachstelle darstellt. Ein Agent kann nur dann auf Ressourcen in einem anderen AWS-Konto zugreifen, wenn der Entwickler ausdrücklich Berechtigungen sowohl für die Ausführungsrolle des Agenten als auch für die Zielressource erteilt.“ Die in Zenitys eigenen Beiträgen wiedergegebene AWS-Erklärung behält den Kern des ersten Satzes bei – „Das beschriebene Verhalten ist dokumentiert und zu erwarten“ – und ergänzt, dass Kunden Ausführungsrollen nur die Berechtigungen gewähren sollten, die ihre Agenten benötigen. Zwei Punkte liegen dieser Meinungsverschiedenheit zugrunde. AWS definiert die Grenze über den Zugriff auf Ressourcen in einem anderen AWS-Konto, während Zenitys Befund Agenten innerhalb eines einzelnen AWS-Kontos und einer einzelnen Region betrifft; und die von Zenity beschriebenen Rollen stammten aus den Standardeinstellungen der Plattform und nicht daraus, dass ein Kunde eine Richtlinie von Hand geschrieben hat.

Die Korrektur, die The Next Web an seiner eigenen Story vorgenommen hat, ist es wert, festgehalten zu werden, denn sie zeigt, dass die Behauptung von jemand anderem als den Forschern selbst eingegrenzt wurde. Zunächst berichtete es über eine Schlagzeile, die besagte, die Forscher hätten jeden AgentCore-Agenten in einer Region übernommen, und korrigierte diese später; die korrigierte Version gibt an, dass die Untersuchung Agenten innerhalb eines einzelnen AWS-Kontos und einer Region abdeckte, und merkt an, dass die frühere Schlagzeile die Behauptung der Forscher als Tatsache dargestellt hatte.

Der Offenlegungszeitplan

Zenity reichte zwei Berichte statt einen ein, und sie wurden unterschiedlich beantwortet. Der Bericht zum IMDS-Zugriff ging am 25. Dezember 2025 ein; AWS schloss ihn am 12. April 2026 als „informativ“ ab und schrieb, dass AgentCore IMDSv2 erst seit dem 14. Februar 2026 verwendet habe, wobei neu bereitgestellte Agents auf diese Weise starteten. Diese Korrektur ist für die Einzelheiten dieser Untersuchung von Bedeutung, weil IMDSv2 bei jeder Anfrage ein Sitzungstoken erfordert und den einfachen unauthentifizierten Abruf vereitelt, den die Forscher zum Erlangen von Anmeldedaten nutzten. Der zweite Bericht, über die Standardrolle und ihren Wirkungsradius, ging am 12. Januar 2026 ein. AWS teilte Zenity am 25. Februar 2026 mit, dass das Team daran arbeitete, während die Rolle unverändert blieb; Zenity überprüfte die Rolle erneut am 22. Juni 2026 und stellte fest, dass ihre Berechtigungen unverändert waren. Eine abschließende Überprüfung am 29. September 2026 ergab, dass die Rolle erheblich eingeschränkt worden war, und in Zenitys Pressemitteilung heißt es, die Entfernung habe das Aufrufen anderer Agents, das Lesen privater Unterhaltungen und den Zugriff auf Geheimnisse in AWS Secrets Manager betroffen, wobei auch andere Berechtigungen deutlich eingeschränkt wurden. In Zenitys eigenen Beiträgen heißt es, dass AWS IMDSv2 inzwischen zum Standard für AgentCore-Bereitstellungen gemacht habe und dass beide Seiten während des Prozesses zusammengearbeitet hätten.

Was nicht bekannt ist

Zenity hat nicht veröffentlicht, wie viele Agenten oder Organisationen in dem Zeitraum zwischen der IMDSv2-Änderung im Februar und der Eingrenzung Ende September mit der Standardrolle liefen, und in den zitierten Quellen steht nichts darüber, dass irgendwelche Kundendaten außerhalb der eigenen Umgebung der Forscher offengelegt wurden. Die IMDSv2-Änderung gilt laut AWS, wie von Zenity berichtet, für Agenten, die nach dem 14. Februar 2026 bereitgestellt wurden; was sie für vor diesem Datum bereitgestellte Agenten bedeutet, wird in den hier geprüften Quellen nicht angegeben. Das Archiv verzeichnet keinen realen Schaden, und die Quellen stützen diese Lesart, indem sie eine Demonstration beschreiben und AWS das Schwachstellen-Label bestreitet, statt einen eigenen Vorfall zu melden.

Sharbat sagte gegenüber Dark Reading, dass Zenity derzeit andere Cloud-Plattformen auf ähnliche Probleme beim Metadatenzugriff untersucht und dass das Unternehmen sie noch nicht benennen möchte. Sein erklärtes Fazit betrifft Berechtigungen und nicht nur den Metadatendienst allein: „Selbst wenn jemand an das IMDS gelangt, wird der Blast Radius deutlich kleiner sein.“

Why this record is kept

AgentCorruption ist nicht bemerkenswert, weil Metadaten-Endpunkte eine neue Idee wären. Sharbat verwies das SecTor-Publikum auf den Capital-One-Datenleck von 2019, bei dem ein SSRF IMDS erreichte und zu gestohlenen Zugangsdaten wurde, und beschrieb das als einen Least-Privilege-Fehler derselben Art. Neu ist der Akteur, der das Abrufen vornimmt. Die Anfrage, die eine AWS-Identität erzeugte, wurde von einem KI-Agenten gestellt, der tat, worum er gebeten wurde, in einfacher Sprache, über ein Tool, das ihm gegeben worden war, damit er nützlich sein konnte – und der Agent gab die Antwort zurück. Die beiden Bedingungen, die daraus ein kontoweites Problem machten, waren ein Metadaten-Endpunkt, den die Sandbox nicht blockierte, und eine Standardrolle, die weiter gefasst war als der Agent, der sie innehatte.

Die vollständige Untersuchung, einschließlich der fünfteiligen technischen Reihe und des Demonstrationsvideos, ist in Zenitys Pressemitteilung vom 8. Oktober 2026 verlinkt. Dieser Datensatz ist ein Eintrag unter den dokumentierten Agenten-Vorfällen in dem KI-Vorfallarchiv, wobei jeder Eintrag über eigene Quellen, Schweregrad, Konfidenzstufe und eine Kennzeichnung als strittig verfügt – die Felder, die es ermöglichen, einen Anbieterstreit über die Darstellung, wie hier, von einem umstrittenen Schadensbefund zu unterscheiden.

Dies ist ein einzelner Eintrag, von anderen recherchiert und gemeldet und hier unter Verweis auf sie zitiert. Die übrigen dokumentierten Agent-Vorfälle, jeweils mit eigenen Quellen, Schweregrad, Konfidenzstufe und Markierung als umstritten, befinden sich in dem KI-Vorfallarchiv — sodass eine Plattform-Standardeinstellung, die einen Prompt in eine kontoweite Fußfassung verwandelt, neben dem gelesen werden kann, was anderswo tatsächlich passiert ist.