Ein Prompt kapert die Agentenflotte: Was die AgentCore-Lücke bei AWS für Unternehmen bedeutet

Die Sicherheitsfirma Zenity Labs hat am 8. Oktober 2026 eine Schwachstellenkette in Amazon Bedrock AgentCore veröffentlicht, dem Dienst, mit dem Unternehmen KI-Agenten in der AWS-Cloud betreiben. Nach Darstellung der Forscher Tamir Ishay Sharbat und Lana Salameh reichte ein einziger präparierter PromptPromptDie Eingabe bzw. Anweisung, mit der man eine KI steuert.Im Glossar ansehen → an einen öffentlich erreichbaren Agenten, um an temporäre AWS-Zugangsdaten zu kommen. Mit diesen ließen sich dann weitere Agenten im selben Konto und in derselben Region ansprechen, Gespräche mitlesen, Zugangsdaten abrufen und das Gedächtnis der Agenten verändern.

AWS hat beide Schwachstellen inzwischen entschärft, allerdings in zwei Schritten und mit deutlichem Abstand: Der erste Teil wurde im Februar 2026 behoben, die zu weit gefasste Standardrolle erst Monate später eingeschränkt. Für Unternehmen, die AgentCore schon länger einsetzen, ist das der eigentliche Punkt. Was vor den Korrekturen eingerichtet wurde, verdient einen zweiten Blick.

Wie aus einem Prompt Zugangsdaten wurden

Die Kette besteht aus zwei Teilen. Der erste betrifft die Abschottung der Agenten. AgentCore führt sie in kleinen virtuellen Maschinen aus. Laut Zenity boten diese nicht genug Netzwerktrennung: Ein Agent, der Webanfragen stellen darf, konnte per Prompt InjectionPrompt InjectionAngriff, bei dem versteckte Anweisungen eine KI zu unerwünschtem Verhalten bringen.Im Glossar ansehen → dazu gebracht werden, den internen Metadatendienst der Instanz (Instance Metadata Service, kurz IMDS) abzufragen. Weil die Anfrage von innen kam, gab der Dienst die temporären Zugangsdaten der Rolle heraus, unter der der Agent lief. Als Voraussetzung nennt Zenity lediglich Chat-Zugang zu einem einzigen erreichbaren Agenten.

Der zweite Teil macht aus einem einzelnen Vorfall ein Flottenproblem. Die Standard-Ausführungsrolle, die AgentCore anlegt, wenn man nichts Eigenes vorgibt, war nach Zenitys Analyse nicht auf den jeweiligen Agenten beschränkt, sondern galt für alle AgentCore-Ressourcen der Region. Mit den erbeuteten Zugangsdaten konnte ein Angreifer demnach andere Agenten aufrufen, die Gesprächsverläufe aller Sitzungen lesen, API-Schlüssel und Einträge aus dem AWS Secrets Manager abrufen und neue Einträge ins Langzeitgedächtnis der Agenten schreiben. Letzteres ist besonders heikel: Ein vergiftetes Gedächtnis wirkt weiter, auch wenn die Zugangsdaten längst abgelaufen sind.

Was AWS geändert hat und wann

Die Zeitleiste stammt aus der Veröffentlichung von Zenity. Die Meldung zum Metadatendienst ging am 25. Dezember 2025 an AWS. Nach Angaben von AWS laufen seit dem 14. Februar 2026 alle neu bereitgestellten Agenten nur noch mit IMDSv2, der abgesicherten Version des Dienstes, die solche einfachen Anfragen von innen deutlich erschwert. Die Meldung selbst schloss AWS am 12. April 2026 als informativ.

Den zweiten Bericht zur übermächtigen Standardrolle reichte Zenity am 12. Januar 2026 ein. Am 25. Februar meldete AWS, man arbeite daran. Bei einer erneuten Prüfung am 22. Juni stellte Zenity fest, dass die Rechte unverändert waren. Erst bei einer letzten Kontrolle vor der Veröffentlichung, am 29. September 2026, fanden die Forscher eine deutlich eingeschränkte Rolle vor: Der Aufruf anderer Agenten, das Lesen von Gesprächen und der Zugriff auf den Secrets Manager waren entfernt. The Decoder datiert die Änderung auf etwa August und weist darauf hin, dass auch die überarbeitete Rolle noch weiter gefasst sei als nötig.

Die Standardrolle von AgentCore war nicht auf den jeweiligen Agenten beschränkt. Sie enthielt weitreichende Berechtigungen für sämtliche AgentCore-Ressourcen der gesamten Region.

So fassen es die Zenity-Forscher zusammen (übersetzt). Eine eigene öffentliche Stellungnahme oder ein Security Bulletin von AWS zu diesem Fall war bis zum Redaktionsschluss nicht zu finden. Die Darstellung der Rechte stammt also vom Entdecker.

Neu ist das Grundproblem allerdings nicht. Bereits am 8. April 2026 hatte Unit 42 von Palo Alto Networks unter dem Titel Agent God Mode beschrieben, dass die vom Starter Toolkit automatisch erzeugten Rollen mit Platzhaltern auf alle Ressourcen des Kontos zielen, etwa auf das Gedächtnis anderer Agenten. AWS ergänzte daraufhin die Dokumentation. Dort heißt es heute, die vom AgentCore-Werkzeug erstellten Richtlinien seien für Entwicklung und Tests gedacht und nicht für den Produktivbetrieb geeignet.

Warum das über AWS hinaus lehrreich ist

Prompt Injection lässt sich bei Sprachmodellen nicht vollständig verhindern. Das haben zuletzt auch Fälle wie Ghostjacking bei KI-Coding-Agenten gezeigt. Entscheidend ist deshalb, was ein übernommener Agent anrichten kann. Hier lag der Schaden nicht im Modell, sondern in der Infrastruktur darum herum: fehlende Netzwerkgrenze und eine Rolle, die viel mehr durfte, als der einzelne Agent brauchte. Dass solche Vorfälle auch datenschutzrechtlich ernst werden, zeigt der erste gemeldete Datenschutzvorfall durch einen autonomen Agenten in Spanien.

Was das für Ihr Unternehmen heißt

• Rollen prüfen: Stellen Sie fest, unter welcher Ausführungsrolle jeder Agent läuft. Automatisch erzeugte Standardrollen gehören ersetzt durch eigene Rollen, die nur auf die Ressourcen dieses einen Agenten zeigen, ohne Platzhalter über die ganze Region.
• Altbestand gesondert ansehen: Agenten, die vor dem 14. Februar 2026 bereitgestellt wurden, liefen ursprünglich ohne IMDSv2-Pflicht, Rollen von vor Ende September 2026 tragen womöglich noch die alten weiten Rechte. Zenity lässt offen, ob bestehende Agenten und Rollen nachträglich angepasst wurden. Im Zweifel neu bereitstellen und die Rolle von Hand nachziehen.
• Gedächtnis und Gespräche kontrollieren: Prüfen Sie das Langzeitgedächtnis Ihrer Agenten auf Einträge, die niemand bewusst angelegt hat, und werten Sie die CloudTrail-Protokolle auf ungewöhnliche Zugriffe auf Gedächtnis, Gesprächsverläufe und Agentenaufrufe aus.
• Secrets und Schlüssel: Wenn Agenten mit weiten Rollen öffentlich erreichbar waren, sollten Sie die Zugangsdaten im Secrets Manager und die hinterlegten API-Schlüssel vorsorglich austauschen.
• Öffentliche Agenten trennen: Agenten, die Kunden oder das Internet erreichen, sollten in einem eigenen Konto oder zumindest strikt getrennt von internen Agenten laufen, mit eingeschränktem Netzwerkzugang und nur den Werkzeugen, die sie wirklich brauchen.

Fazit

Die AgentCore-Lücke ist weitgehend geschlossen, aber sie zeigt ein Muster, das bei vielen Agenten-Projekten vorkommt: Der Prototyp wird mit bequemen Standardrechten gebaut und geht dann unverändert in den Betrieb. Wer KI-Agenten in der Cloud einsetzt, sollte Berechtigungen, Gedächtnis und Netzwerkzugang so behandeln wie bei jeder anderen Anwendung mit Kundendaten. Wenn Sie Ihre Agenten auf AWS oder anderswo einmal unabhängig durchsehen lassen möchten, sprechen Sie mich gern an.