AWS AgentCore gab temporäre Zugangsdaten preis
Sicherheitsforscher von Zenity Labs haben eine Angriffskette in Amazon Bedrock AgentCore offengelegt. Nach ihren Angaben genügte der Chat-Zugriff auf einen entsprechend konfigurierten KI-Agenten, um temporäre AWS-Zugangsdaten aus dem Instance Metadata Service abzurufen.
Der Instance Metadata Service, kurz IMDS, stellt virtuellen Maschinen Informationen über ihre Cloud-Umgebung bereit. Dazu gehören Region, Netzwerk, System-Images und Sicherheitsgruppen. Abhängig von der Konfiguration liefert der Dienst auch temporäre Zugangsdaten für die zugewiesene IAM-Rolle.
Der Agent erhielt per Prompt die Anweisung, eine URL zu diesem Metadaten-Endpunkt aufzurufen und das Ergebnis als JSON auszugeben. Damit wurde der Agent für eine Server-Side Request Forgery, kurz SSRF, genutzt. Bei diesem Angriff ruft ein Server interne Ressourcen im Auftrag eines externen Angreifers ab.
Sinngemäß erklärten die Forscher: Ein externer Angreifer mit Chat-Zugriff auf einen einzelnen Agenten konnte dessen IMDS-Zugangsdaten auslesen und damit weitere AgentCore-Ressourcen im selben AWS-Konto und in derselben Region übernehmen.
Drei Schwächen verstärkten sich gegenseitig
Der Angriff beruhte nicht auf einem einzelnen Fehler. Entscheidend war das Zusammenspiel aus erreichbarem Metadaten-Endpunkt, unzureichender Netzwerkisolation und zu umfangreichen IAM-Berechtigungen.
| Schwachstelle | Auswirkung |
|---|---|
| Zugriff auf IMDSv1 | Der Agent konnte temporäre Zugangsdaten aus den Instanzmetadaten abrufen. |
| Unzureichende Isolation der Firecracker MicroVM | Vom Agenten ausgelöste Anfragen erreichten interne Cloud-Endpunkte. |
| Zu weit gefasste IAM-Rolle | Die erbeuteten Rechte galten für mehrere AgentCore-Ressourcen in der Region statt nur für einen Agenten. |
Nach Darstellung der Forscher ließen sich mit den Zugangsdaten weitere Agenten auflisten und starten. Zudem konnten Container-Images aus Amazon Elastic Container Registry geladen und lokal mit Root-Rechten untersucht werden. Damit wäre auch ein Einblick in Quellcode und eingebundene Komponenten möglich gewesen.
Besonders kritisch war der Zugriff auf Sitzungen und Speicherressourcen der Agenten. Darin konnten sich Nutzerinformationen und Gesprächsverläufe befinden. Die Berechtigungen sollen außerdem Zugriffe auf AWS Secrets Manager ermöglicht haben, in dem Unternehmen üblicherweise API-Schlüssel und andere Geheimnisse hinterlegen.
Manipulierte Erinnerungen wirken über Sitzungen hinweg
Die Forscher konnten nach eigenen Angaben neue Einträge in den Speicher anderer Agenten schreiben. Solche persistenten Erinnerungen bleiben über einzelne Sitzungen hinaus erhalten. Ein Angreifer könnte dadurch Ziele oder Verhalten eines Agenten langfristig verändern.
Das Risiko ähnelt damit den bereits bekannten Sicherheitsproblemen bei internen KI-Agenten und MCP-Anbindungen. Sobald ein Agent Werkzeuge, Cloud-Rollen und dauerhaften Speicher kombinieren darf, kann ein einzelner manipulierter Auftrag mehrere Schutzschichten überspringen.
AWS stellte auf IMDSv2 um
Zenity Labs meldete die ersten Ergebnisse im Dezember 2025 an AWS. Im Januar 2026 folgten Informationen zu den weitreichenden Berechtigungen. AWS stellte AgentCore nach eigenen Angaben bis zum 14. Februar 2026 vollständig auf IMDSv2 um.
| Zeitpunkt | Entwicklung |
|---|---|
| Dezember 2025 | Erste Meldung des möglichen Zugriffs auf Instanzmetadaten |
| Januar 2026 | Hinweis auf zu umfangreiche AgentCore-Berechtigungen |
| 14. Februar 2026 | AgentCore verwendet laut AWS ausschließlich IMDSv2 |
| 22. Juni 2026 | Die Forscher sahen die Berechtigungsprobleme noch nicht vollständig behoben |
| 29. September 2026 | Abschließende Prüfung bestätigte nach Angaben der Forscher die Behebung |
AWS widerspricht allerdings der Einordnung als Produktlücke. Das Unternehmen bezeichnete das beobachtete Verhalten als dokumentiert und erklärte, für den Angriff sei eine fehlerhafte Konfiguration durch Entwickler erforderlich gewesen. Damit bleibt strittig, welcher Anteil auf AgentCore selbst und welcher auf die konkrete Bereitstellung entfiel.
Managed Service ersetzt kein Berechtigungskonzept
Für Unternehmen im DACH-Raum ist vor allem die Reichweite der IAM-Rollen relevant. Ein Agent sollte nur auf genau die Ressourcen zugreifen können, die für seine Aufgabe erforderlich sind. Rollen auf Konto- oder Regionsebene vergrößern den Schaden, wenn ein Prompt, ein Werkzeug oder eine Integration kompromittiert wird.
Cloud-Agenten sollten zudem in isolierten Laufzeitumgebungen arbeiten. Ein ähnliches Prinzip verfolgen Docker Cloud Sandboxes zur Isolation von KI-Agenten. Netzwerkzugriffe auf Metadaten-Endpunkte gehören blockiert, sofern sie nicht zwingend benötigt werden.
Auch Speicher, Sitzungen und Geheimnisse benötigen getrennte Zugriffsregeln. Ein Beispiel für feinere Zugriffskontrollen liefert Cohere North 2 mit ACLs für KI-Agenten. Entscheidend ist nicht der konkrete Anbieter, sondern die konsequente Trennung von Identitäten, Daten und ausführbaren Aktionen.
Der Vorfall zeigt zugleich eine Grenze verwalteter KI-Plattformen. Der Anbieter übernimmt zwar Infrastruktur und Laufzeit, nicht aber automatisch eine sichere Rechtevergabe. Self-Hosting schafft mehr Kontrolle über Netzwerkpfade und Datenhaltung, erhöht jedoch den eigenen Betriebsaufwand und beseitigt Fehlkonfigurationen nicht von selbst.