Zenitys AgentCorruption-Veröffentlichung vom 8. Oktober beschreibt einen historischen Weg von einem öffentlich erreichbaren Amazon-Bedrock-AgentCore-Agenten zu benachbarten Laufzeiten und dauerhaftem Speicher. Entscheidend war eine zu weit gefasste Ausführungsrolle im selben AWS-Konto und derselben Region, nicht der Einbruch bei fremden AWS-Kunden oder ein gestohlenes Administratorpasswort.
Eine durch einen Prompt ausgelöste Netzwerkanfrage legte temporäre Workload-Zugangsdaten offen; IAM vergrößerte deren Reichweite. Vor Veröffentlichung fanden Forscher erheblich eingeschränkte AWS-Standardrollen. Die Studie belegt frühere getestete Standards, nicht die vollständige Angreifbarkeit jeder heutigen AgentCore-Installation.
Ein Prompt überschritt die Grenze zur Workload-Identität
AgentCore ist seit Oktober 2025 allgemein verfügbar und verbindet isolierte Laufzeiten mit Identität, Speicher, Gateways, Browserautomatisierung, Codeausführung und Beobachtbarkeit. Das löst echte Betriebsprobleme, schafft aber Autorisierungsabhängigkeiten außerhalb der MicroVM-Grenze.
Im Test folgte ein HTTP-fähiges Werkzeug unvertrauenswürdigen Anweisungen und fragte lokale Workload-Metadaten ab. AWS nutzt einen linklokalen Metadatendienst; Firecracker-MicroVMs in AgentCore besitzen den verwandten MMDS. Temporäre Rollendaten erlauben legitimen Codezugriff, ohne Dauerschlüssel in Images einzubauen.
Die Anfrage kam aus der MicroVM, wurde lokal behandelt und lieferte temporären Zugriffsschlüssel, geheimen Schlüssel und Sitzungstoken. Das ist ein SSRF-Muster: Ein Angreifer bringt eine Serverkomponente zu einem für ihn unerreichbaren Ziel. Prompt Injection lieferte Absicht, das Werkzeug Netzwerkfähigkeit, Metadaten eine Cloud-Identität.
Unsicherer Text allein hätte diese Kette nicht erzeugt. Unnötigen Metadatenzugriff aus Werkzeugen zu blockieren hätte sie unterbrochen; eine enge Rolle hätte Folgen nach Diebstahl begrenzt. AWS erklärt ausdrücklich, dass Code oder Akteure innerhalb einer MicroVM verfügbare Zugangsdaten erreichen können, und fordert minimale Berechtigungen.
Zenity meldete die Metadatenfrage am 25. Dezember 2025. AWS schloss sie am 12. April 2026 als informativ und verwies auf IMDSv2 für neue Bereitstellungen seit 14. Februar. Der vorherige Tokenabruf blockiert viele klassische SSRF-Pfade, doch flexible autonome Werkzeuge können auch diese Anfragen ausführen. Zenity sieht zusätzliche Reibung statt gelöstes Vertrauen.
Die heutige Anleitung sagt, Laufzeiten ohne MMDSv2 würden seit 30. Juni 2026 abgelehnt. Kunden sollten die tatsächliche Konfiguration einschließlich requireMMDSV2 prüfen, statt eine Änderung aller alten Installationen anzunehmen. Metadatenhärtung ist eine Schicht, keine Rechtfertigung übergroßer Rollenrechte für legitimen Code.
Breite Rechte machten den Ausgangspunkt anderswo nutzbar
Ein zweiter Bericht vom 12. Januar betraf Rollenumfang. Regionale CloudWatch-Loggruppen und AgentCore-Namensmuster verrieten laut Zenity Laufzeit- und Speicherkennungen ohne vorheriges Inventar. Regionale ECR-Rechte und vorhersehbare Repositorynamen verbanden Laufzeiten mit Images und möglichen Code- oder Konfigurationsgeheimnissen.
Die getestete Wildcard-Aufrufberechtigung erreichte private Agenten desselben Kontos und derselben Region. Ein öffentlicher Supportbot konnte so zu einem sensibleren Rechnungsagenten gelangen. Zenity demonstrierte dessen Werkzeuge und billing.json über legitime APIs, nicht einen zweiten unabhängigen Softwarefehler.
Speicherrechte erlaubten dem Bericht zufolge Auflisten anderer Akteure und Sitzungen sowie Lesen ihrer Ereignisse. Gespräche könnten Personeninformationen, Code, Pläne, Kundendaten oder bei Fehlersuche eingefügte Zugangsdaten enthalten. Ob ein Geheimnis ins Gespräch gehörte, ist eine andere Frage als das Leserecht fremder Workloads.
Erstellen und Löschen veränderten zusätzlich Integrität. Falscher Kontext konnte in laufende Sitzungen gelangen und echte Werkzeugresultate verschwinden. Rechenisolation verhinderte keine Aufrufe und Änderungen anderer Ressourcen durch dieselbe Identität; Autorisierungsisolation ist eigenständig nötig.
AWS teilte am 25. Februar mit, am Grundproblem zu arbeiten. Am 22. Juni sei die Standardrolle noch unverändert gewesen, am 29. September jedoch deutlich beschränkt: Aufrufe fremder Laufzeiten, private Gespräche und Secrets-Manager-Abrufe waren entfernt und weitere Rechte enger.
Das begrenzt aktuelle Aussagen erheblich. Kundenrollen, kopierte Richtlinien und Altinstallationen bleiben prüfenswert, doch historische Demonstrationen beweisen keine identische heutige Standardrolle. Getestet wurde kontrolliert; zitierte öffentliche Belege zeigen keine breite Ausnutzung bei Kunden. Eine gesonderte AWS-Sicherheitsmeldung zur ganzen Kette lag damals nicht vor.
Speicher konnte Einfluss über abgelaufene Zugangsdaten hinaus bewahren
Kurzzeitspeicher hält Sitzungsereignisse, langfristige Strategien extrahieren Fakten, Vorlieben, Zusammenfassungen und Erfahrungen. Das hilft bei offenen Fällen und Formatwünschen, macht Historie aber zum künftigen Entscheidungseingang statt nur zum Beweismittel nach einem Vorfall.
Zenity berichtet über Speicherkennungen aus Logs, Auflisten von Akteuren, Sitzungen und Strategien und Hinzufügen feindlicher Ereignisse. Extraktion wandelte einige Inhalte in langfristige Datensätze um, die spätere Sitzungen als vertrauten Kontext abrufen konnten. Die ursprüngliche Injection musste daher nicht jedes Mal wiederholt werden.
„Dauerhafte Befehls- und Kontrollstruktur“ ist die Beschreibung der Forscher für ihren Test. Tatsächliches Verhalten hängt von Speicher, Retrieval, Modell, Werkzeugen und Rechten ab. Falsches Ziel, fingierte Zustimmung oder vergiftete Zusammenfassung illustrieren Integritätsrisiken, nicht sichere Kontrolle jedes Agenten durch jede Erinnerung.
Eingefügte Assistentenhistorie kann wie eine frühere Entscheidung wirken; gelöschte Resultate entfernen Gegenbelege. Ablauf oder Rotation gestohlener Zugangsdaten stoppt künftige API-Nutzung, löscht aber weder kopierten Code und Geheimnisse noch vergifteten Zustand. Wiederherstellung muss betroffene Sitzungen, Ereignisse, Zusammenfassungen und extrahierte Erinnerungen finden.
AWS empfiehlt Validierung, Schutz vor Speicherung, regelmäßige Injection-Tests und minimale Speicherrechte. Herkunft sollte Nutzer, Agent, Sitzung und Extraktion identifizieren und Quarantäne erlauben. Schreibstilpräferenzen haben andere Folgen als Zahlungsziele oder Zugriffserteilungen; letztere brauchen strengere Erstellung, Aufbewahrung und Prüfung.
Erinnerung darf eine riskante Aktion nicht autorisieren. Ein bevorzugtes Bankkonto ersetzt keine aktuelle unabhängige Freigabe. Neben Lesen sollten Schreiben und Löschen überwacht werden, besonders ungewöhnliche Mengen und agentenübergreifende Muster, mit CloudTrail, Anwendungslogs und AgentCore-Beobachtbarkeit.
Die Berechtigungsgrenze gehört außerhalb des Modellurteils
AWS warnt vor breiten CLI-generierten Entwicklungsrichtlinien in Produktion und empfiehlt konkrete Laufzeit-ARNs statt Wildcards. Rollenrechte sollen höchstens denen der aufrufberechtigten Principals entsprechen. Öffentliche Erreichbarkeit verlangt daher besonders geringe Befugnisse.
Nicht jeder öffentliche Agent ist automatisch unsicher. Doch Sprache bleibt unvertrauenswürdig, einschließlich feindlicher Prompts authentifizierter Kunden oder indirekter Anweisungen in Dokumenten und Webseiten. Authentifizierung identifiziert Aufrufer, macht nicht deren gesamte Bedeutung sicher.
Gateways, Guardrails und Interceptoren helfen bei Prüfung und Begrenzung, wenn kein anderer erlaubter Pfad sie umgeht. Ist das Gateway der vorgesehene Eingang, sollte direkter Laufzeitaufruf auf seine Ausführungsrolle beschränkt sein. Nutzeridentität muss aus geprüften Principals kommen, nicht aus Modelltext oder Selbstbehauptung.
Ressourcenbezogenes IAM kann fremde Agenten, Images, regionale Logs und Speicher sperren. Öffentliche und interne Workloads sollten nicht aus Bequemlichkeit Rollen teilen; getrennte Konten oder Regionen können sensible Grenzen klarer machen.
Werkzeuge sind privilegierte Schnittstellen, keine vom Modell verliehenen Rechte. Autorisierung muss Nutzer, Ressource und Operation unabhängig bewerten. Technische Wissensbestände können Eigentümer, Richtlinien, Bedrohungsmodelle und Vorfallverfahren verbinden, ersetzen aber keine erzwungene Ablehnung.
Die heutige Prüfung braucht Historie und bleibenden Zustand
Eine begrenzte Prüfung umfasst Rollen, Metadaten, öffentliche/IAM/JWT-Eingänge, Gateway-Umgehungen, fremde Laufzeiten, ECR und Logs, nutzerübergreifenden Speicher, Ereignisänderungen sowie Token- und Secrets-Manager-Zugriff. Ressourcen- und Identitätsrichtlinien sollten gemeinsam auf erwartete Ablehnung getestet werden, nicht nach erfolgreichem Prototyp bewertet.
Mögliche frühere Exposition braucht die damaligen CloudTrail- und Laufzeitereignisse, Metadatenaktivität, Imageabrufe, Speicher- und Geheimniszugriffe statt nur heutiger Richtlinienschnappschüsse. Temporäre Identitäten können dauerhafte Folgen hinterlassen; Rotation und Zustandsvalidierung ergänzen sich.
Nützlich wären ein formeller AWS-Hinweis oder Migrationsanleitung, stärkere Trennung agentengesteuerter Werkzeuge von Zugangsdatenendpunkten und sichtbare Speicherherkunft, begrenzte Schreibrechte, Alarme und Massenquarantäne. Das sind künftig zu prüfende Belege, keine als ausgeliefert angenommenen Funktionen.
AgentCorruption fragt grundsätzlich, was nach Befolgen einer bösartigen Anweisung möglich bleibt. Managed Infrastruktur reduziert Komplexität, kann aber Werkzeuge, Identität und dauerhaften Speicher nicht sicher in eine breit vertraute Rolle verschmelzen. Deterministische Grenzen sollten eine manipulierte Antwort auch bei Modellversagen vom kontoweiten Vorfall abhalten.
Quellen und weiterführende Informationen
Zenity zur Angriffskette · AWS zu Zugangsdaten · Zenity zur Ausführungsrolle · AWS-Laufzeitsicherheit · Weiterführend: technische Wissensbasen · Zenity zur Speichervergiftung · AWS-Speicherpraktiken · AgentCorruption-Bericht