# AgentCorruption: Ein Prompt, alle AWS-Agenten übernommen > Ein Prompt an einen AWS-Agenten reichte, um alle Agenten im Konto zu übernehmen. Was hinter AgentCorruption steckt und was Betriebe prüfen sollten. Quelle: https://www.krynexlabs.de/blog/agentcorruption-aws-agentcore-standardrolle-ki-agenten/ Stand: 2026-10-13 Anbieter: Krynex Labs UG (haftungsbeschränkt) i. G., Chemnitz · https://www.krynexlabs.de --- [Alle Artikel](https://www.krynexlabs.de/blog/) #KI-Agenten#Sicherheit#AWS#Prompt Injection#Governance#Mittelstand # Ein Prompt, alle Agenten: Was der AgentCorruption-Fall bei AWS über die Standardrechte von KI-Agenten lehrt Sicherheitsforscher von Zenity haben am 8. Oktober 2026 gezeigt, wie ein einziger Prompt an einen öffentlich erreichbaren Agenten auf AWS Bedrock AgentCore genügte, um alle Agenten im selben Konto und in derselben Region zu übernehmen: private Gespräche lesen, Erinnerungen fälschen, Zugangsdaten aus dem Secrets Manager holen. AWS nennt das Verhalten dokumentiert und erwartet. Was genau passiert ist, warum die eigentliche Ursache eine zu breite Standardrolle war und was jeder Betrieb mit Agenten daraus mitnehmen sollte, egal auf welcher Plattform. [Annett Krusch](https://www.krynexlabs.de/ueber-uns/) 13\. Oktober 2026 Am **8\. Oktober 2026** hat die Sicherheitsfirma Zenity eine Forschungsreihe veröffentlicht, deren Titel nicht untertreibt: „AgentCorruption: How A Single Prompt Collapsed The Entire Cloud Security Model”. Ein einziger Prompt an einen öffentlich erreichbaren KI-Agenten auf **AWS Bedrock AgentCore** reichte, um an Zugangsdaten zu kommen, mit denen sich **alle Agenten im selben AWS-Konto und in derselben Region** erreichen ließen. Das Spannende an dem Fall ist nicht der Prompt. Prompt Injection ist bekannt, und jeder Agent, der fremde Inhalte liest, lässt sich damit irgendwann zu etwas überreden. Spannend ist, wie weit der Schaden reichte. Und der hing an einer einzigen Einstellung, die fast niemand anfasst: der Rolle, mit der ein Agent standardmäßig läuft. Wir haben den Bericht von Zenity und die Dokumentation von AWS im Original gelesen. Hier steht, was passiert ist, worüber AWS und Zenity unterschiedlicher Meinung sind und was ein Betrieb daraus mitnehmen sollte, auch wenn er AWS gar nicht nutzt. *Offenlegung: Wir bauen KI-Agenten für Unternehmen und verkaufen mit [AgentGuard](https://www.krynexlabs.de/services/agentguard/) ein eigenes Produkt, das Agenten protokolliert und Aktionen zur Freigabe vorlegt. Mit AWS und Zenity haben wir keine Geschäftsbeziehung.* ## Was AgentCore ist AgentCore ist die verwaltete Plattform von AWS, auf der Firmen eigene KI-Agenten betreiben: Laufzeitumgebung, Werkzeuge, Gedächtnis, Anbindung an externe Dienste und Überwachung aus einer Hand. Jeder Agent läuft in einer kleinen virtuellen Maschine und bekommt eine sogenannte Ausführungsrolle. Diese Rolle legt fest, was der Agent in AWS darf. ## Was Zenity gezeigt hat Die Angriffskette hat drei Schritte. **Erstens: an Zugangsdaten kommen.** Jede Rechenumgebung bei AWS hat einen internen Metadatendienst (IMDS) unter der Adresse 169.254.169.254. Er liefert unter anderem **temporäre Zugangsdaten für die Rolle**, mit der die Umgebung läuft. Laut Zenity waren die virtuellen Maschinen von AgentCore netzwerkseitig nicht ausreichend abgeschottet. Ein Agent mit einem Werkzeug, das Webadressen abruft, konnte deshalb auch diese interne Adresse abrufen. Die Forscher schrieben dem Agenten im Chat, er solle genau das tun. Zitat aus dem Bericht: „All it took was a simple prompt injection.” **Zweitens: feststellen, was diese Zugangsdaten dürfen.** Hier lag nach Zenity das eigentliche Problem. Die Standardrolle galt nicht nur für den einen Agenten, sondern für **alle AgentCore-Ressourcen im Konto und in der Region**. Über eine Leseberechtigung für Protokollgruppen ließen sich die Kennungen aller anderen Agenten herausfinden. **Drittens: alles andere.** Mit den Rechten der Standardrolle konnten die Forscher nach eigener Darstellung: - jeden anderen Agenten im Konto aufrufen, auch interne, die nie öffentlich erreichbar sein sollten, - die privaten Gespräche aller Agenten, Nutzer und Sitzungen lesen, - in Agenten mit Langzeitgedächtnis **gefälschte Erinnerungen anlegen**, die deren Verhalten in künftigen Sitzungen still verändern, - die Container-Images der Agenten herunterladen, - über AgentCore Identity und den AWS Secrets Manager die **Zugangsdaten der angebundenen Werkzeuge** auslesen, also genau die Schlüssel, die die Plattform eigentlich vom Agenten fernhalten soll. Besonders der Punkt mit dem Gedächtnis sollte jeden aufhorchen lassen, der Agenten mit Kunden sprechen lässt. Zenity beschreibt es so: Nutzer hätten weiter mit einem scheinbar vertrauenswürdigen Firmen-Agenten gesprochen, der im Hintergrund nach den Anweisungen eines Angreifers handelt. ## Wie AWS reagiert hat Laut der Zeitleiste im Bericht hat Zenity den ersten Teil am **25\. Dezember 2025** an AWS gemeldet, den zweiten zur Standardrolle am **12\. Januar 2026**. - Seit dem **14\. Februar 2026** starten neu angelegte Agenten nur noch mit IMDSv2. Bei dieser Version muss vor dem Abruf von Zugangsdaten erst ein Token angefordert werden, ein einfacher Seitenabruf reicht nicht mehr. - Am **12\. April 2026** schloss AWS den ersten Bericht als „informative”. - Am **22\. Juni 2026** war die Standardrolle laut Zenity noch unverändert. - Bei einer letzten Prüfung am **29\. September 2026** fand Zenity sie deutlich eingeschränkt. Die Rechte, andere Agenten aufzurufen, fremde Gespräche zu lesen und Geheimnisse aus dem Secrets Manager zu holen, waren entfernt. Zenity schreibt, alle beschriebenen Probleme seien behoben. AWS sieht das grundsätzlicher anders. Die Stellungnahme, die Zenity im Wortlaut abdruckt, beginnt so: „The behavior described is documented and expected. AgentCore agents can access the credentials for their own execution role through the metadata service.” Und weiter: „As a best practice, we recommend that customers grant their execution roles only the permissions their agents need.” Beide Sichtweisen sind in sich schlüssig. AWS hat recht damit, dass ein Agent die Zugangsdaten seiner eigenen Rolle sehen darf und dass Kunden ihre Rollen eng fassen sollten. Zenity hat recht damit, dass die Rolle, die Kunden ohne weiteres Nachdenken bekamen, alles andere als eng war. Für die Praxis ist der Streit weniger wichtig als die Frage, was mit den Rollen passiert, die schon angelegt sind. ## Die offene Frage: Was ist mit älteren Agenten? Die Ausführungsrolle ist laut AWS-Dokumentation eine **IAM-Rolle im Konto des Kunden**. Konsole und Werkzeuge legen sie beim Erstellen eines Agenten an. Dass AWS die Vorlage für neue Rollen geändert hat, heißt nicht automatisch, dass bestehende Rollen in Kundenkonten mitgeändert wurden. Weder Zenity noch AWS sagen dazu etwas. Die AWS-Dokumentation warnt außerdem selbst, dass die Richtlinien, die das AgentCore-Kommandozeilenwerkzeug anlegt, für Entwicklung und Tests gedacht und „not suitable for production environments” sind. Wer einen Prototypen mit dem Werkzeug gebaut und dann einfach live geschaltet hat, sollte das ernst nehmen. Unsere Empfehlung für jeden, der Agenten auf AgentCore betreibt: die Ausführungsrollen aller Agenten öffnen, die vor Ende September 2026 angelegt wurden, und nachsehen, ob dort Rechte auf `*` oder auf ganze Regionen stehen, besonders für das Aufrufen anderer Agenten, das Lesen von Sitzungen und Gedächtnis sowie den Zugriff auf Secrets. ## Was das für Ihren Betrieb heißt, auch ohne AWS Der konkrete Fall betrifft nur AgentCore. Das Muster dahinter finden wir in fast jedem Agenten-Projekt, das wir prüfen. Fünf Lehren, die für jede Plattform gelten. ### Standardrechte sind keine Sicherheitsentscheidung Jede Plattform liefert eine Vorgabe, mit der der Agent sofort läuft. Diese Vorgabe ist so gebaut, dass möglichst wenig scheitert, nicht so, dass möglichst wenig passieren kann. Ein Agent für Kundenanfragen braucht Lesezugriff auf die Produktdaten, nicht auf die Gespräche der Buchhaltung. Diese Grenze muss jemand bewusst ziehen. ### Öffentliche Agenten gehören in eine eigene Zone Ein Agent, mit dem jeder im Internet chatten kann, ist ein Eingang. Er sollte in einem eigenen Konto oder Projekt laufen, getrennt von internen Agenten, und keine Rechte haben, diese aufzurufen. Im Fall AgentCorruption lag genau darin die Hebelwirkung: Der öffentliche Agent war der Weg zu den internen. ### Ein Werkzeug, das Adressen abruft, ist ein Werkzeug für alles Sobald ein Agent beliebige Webadressen abrufen darf, kann er auch interne Adressen abrufen, wenn das Netzwerk es nicht verhindert. Werkzeuge für Webzugriffe brauchen eine Liste erlaubter Ziele, und interne Adressen wie der Metadatendienst gehören ausdrücklich gesperrt. Wie Angreifer Anweisungen überhaupt in einen Agenten bekommen, haben wir in [Prompt Injection: wie Sie KI-Agenten schützen](https://www.krynexlabs.de/blog/prompt-injection-ki-agenten-schuetzen/) beschrieben. ### Das Gedächtnis ist eine Angriffsfläche Agenten mit Langzeitgedächtnis merken sich, was ihnen gesagt wurde. Wer in dieses Gedächtnis schreiben kann, verändert den Agenten dauerhaft, ohne dass am Code etwas sichtbar wird. Schreibzugriffe auf das Gedächtnis gehören deshalb protokolliert und regelmäßig angesehen, wie jede andere Änderung an der Konfiguration. Wie wir Agenten-Gedächtnisse gegen solche Einträge absichern, steht unter [KI-Gedächtnis-Schutz](https://www.krynexlabs.de/services/ki-gedaechtnis-schutz/). ### Ohne Protokoll merkt es niemand Der beschriebene Angriff nutzt gültige Zugangsdaten und gültige Schnittstellen. Es gibt keinen Absturz und keine Fehlermeldung. Bemerken lässt sich so etwas nur, wenn jemand protokolliert, welcher Agent was aufruft, und Abweichungen auffallen: ein Kundenservice-Agent, der plötzlich Geheimnisse abfragt oder fremde Sitzungen liest. Was ein brauchbarer Audit-Trail enthalten sollte, steht in [Audit-Trail für KI-Chatbots: was Sie protokollieren müssen](https://www.krynexlabs.de/blog/ki-chatbot-audit-trail-was-protokollieren/). ## Unsere Einschätzung Der Fall passt in eine Woche, in der BSI und TÜV-Verband in ihrer [KI-Sicherheitsstudie 2026](https://www.krynexlabs.de/blog/ki-sicherheitsstudie-bsi-tuev-2026-ki-vorfaelle/) Unternehmen ausdrücklich raten, bei KI-Agenten auf technisch begrenzte Rechte und kontrollierte Schnittstellen zu achten. AgentCorruption ist das Lehrbeispiel dafür, warum. Wir halten die Lehre für wichtiger als den konkreten Fehler. AWS hat die Vorgabe nachgebessert, und andere Plattformen werden ähnliche Fälle haben. Was bleibt, ist eine einfache Regel: **Wie viel ein Angreifer mit einem Agenten anrichten kann, entscheidet nicht der Prompt, sondern die Rolle.** Eine Prompt Injection gegen einen Agenten mit engen Rechten erzeugt eine falsche Antwort. Dieselbe Injection gegen einen Agenten mit breiten Rechten öffnet das ganze Konto. In Kundenprojekten ziehen wir diese Grenze zweimal: einmal in den Rechten der Plattform und einmal mit [AgentGuard](https://www.krynexlabs.de/services/agentguard/), das als eigener Dienst vor den Agenten sitzt, jede gemeldete Aktion manipulationssicher protokolliert und folgenreiche Aktionen einem Menschen zur Freigabe vorlegt. Wenn Sie Ihre bestehenden Agenten prüfen lassen möchten, ist unser [KI-Pentest](https://www.krynexlabs.de/blog/ki-pentest-was-ein-sicherheitstest-prueft/) der passende Einstieg. ## Quellen - Zenity Labs, 8. Oktober 2026: [AgentCorruption: How A Single Prompt Collapsed The Entire Cloud Security Model](https://labs.zenity.io/post/agentcorruption-how-a-single-prompt-collapsed-the-entire-cloud-security-model) (mit Zeitleiste und Stellungnahme von AWS im Wortlaut) - AWS-Dokumentation: [IAM Permissions for AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-permissions.html) - AWS-Dokumentation: [Security best practices for AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-security-best-practices.html) - AWS-Dokumentation: [Credentials management in AgentCore](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/security-credentials-management.html) ## Häufige Fragen Was ist AgentCorruption? So nennt die Sicherheitsfirma Zenity eine Angriffskette auf AWS Bedrock AgentCore, die sie am 8. Oktober 2026 veröffentlicht hat. Über eine Prompt Injection brachten die Forscher einen öffentlich erreichbaren Agenten dazu, beim Metadatendienst seiner Laufzeitumgebung (IMDS) temporäre AWS-Zugangsdaten abzurufen. Weil die Standardrolle der Agenten sehr breite Rechte hatte, ließen sich damit alle AgentCore-Agenten im selben AWS-Konto und in derselben Region erreichen. Was konnte ein Angreifer damit tun? Laut Zenity: andere Agenten im Konto aufrufen, private Gespräche aller Agenten und Nutzer lesen, dauerhafte Erinnerungen in Agenten mit Langzeitgedächtnis anlegen und so ihr Verhalten in künftigen Sitzungen verändern, Container-Images der Agenten herunterladen sowie Zugangsdaten für angebundene Werkzeuge aus AgentCore Identity und dem AWS Secrets Manager auslesen. Ist die Lücke geschlossen? Zenity schreibt, AWS habe alle beschriebenen Probleme behoben. Seit dem 14. Februar 2026 starten neue Agenten nur noch mit IMDSv2, und bei der letzten Prüfung am 29. September 2026 war die Standardrolle deutlich eingeschränkt. AWS selbst bezeichnet das Verhalten in seiner Stellungnahme als dokumentiert und erwartet und empfiehlt, Ausführungsrollen nur die Rechte zu geben, die ein Agent braucht. Sind ältere Agenten automatisch sicher? Das geht aus keiner der Quellen hervor. Die Ausführungsrolle eines AgentCore-Agenten ist eine IAM-Rolle im Konto des Kunden, die beim Anlegen über Konsole oder Werkzeug erzeugt wird. Ob AWS bereits angelegte Rollen nachträglich ändert, sagen weder Zenity noch AWS. Wer Agenten vor Ende September 2026 angelegt hat, sollte deren Rollen selbst prüfen. Betrifft das auch Betriebe, die nicht AWS nutzen? Der konkrete Fall betrifft nur AgentCore. Das Muster dahinter gilt für jede Agenten-Plattform: Ein öffentlich erreichbarer Agent, der Webseiten oder Adressen abrufen kann, läuft mit Rechten, die weit über seine Aufgabe hinausgehen. Dann wird aus einer Prompt Injection, die sonst nur eine falsche Antwort erzeugt, ein Zugriff auf alles, was die Rolle darf. ## Passend dazu Insights Anthropic nimmt seinen eigenen Agenten-Tests das Internet weg. Was Betriebe daraus lernen sollten → https://www.krynexlabs.de/blog/anthropic-kappt-internetzugang-agenten-tests/ Insights KI-Sicherheitsstudie 2026 von BSI und TÜV: Nur jedes zehnte Unternehmen hat einen Plan, wenn die KI selbst der Vorfall ist → https://www.krynexlabs.de/blog/ki-sicherheitsstudie-bsi-tuev-2026-ki-vorfaelle/ Insights Ein KI-Prüfer fälscht Dateien und beschädigt seine eigene Umgebung. Was OpenAIs Vorfallbericht für Agenten im Betrieb heißt → https://www.krynexlabs.de/blog/openai-pruefmodell-faelscht-dateien-beschaedigt-umgebung/