AgentCorruption: Metadaten- und IAM-Risiken in AgentCore

Zenitys Untersuchung vom Oktober 2026 berichtet, dass modellbeeinflusste Tools die Metadaten der AgentCore-Laufzeit erreichen konnten und frühere Berechtigungen der Standardrolle den Zugriff ausweiteten. AWS bezeichnet den Zugriff auf die eigenen Rollen-Anmeldedaten der Laufzeit als erwartetes Verhalten und empfiehlt minimale Berechtigungen. Zenitys Untersuchung nennt keine CVE-Kennung und belegt keinen Angriff auf Kunden.^{[1], [4]}

💡 Einfache Erklärung (ELI5)

Stell dir einen Agenten in einer Werkstatt vor, der einen Ausweis für seine Aufgaben erhält. Laut Zenity konnte ein modellgesteuertes Tool diesen Ausweis am internen Schalter anfordern; die früheren Berechtigungen des Ausweises öffneten mehr Räume als nötig. AWS sagt, dass ein Agent in der Werkstatt erwartungsgemäß die Anmeldedaten seiner eigenen Rolle erhält. Die praktische Abwehr: Begrenze die Türen, die jeder Ausweis öffnet, und kontrolliere, welche Tools interne Anfragen stellen dürfen.^{[1], [4]}

Kernkonzepte & Begriffe

AgentCorruption: Name von Zenity Labs für die kontrollierte Forschungskette zu Amazon Bedrock AgentCore. Zenity nennt keine CVE-Kennung, und die Untersuchung belegt keinen Angriff auf Kunden.^{[1], [7]}
MMDS und Anmeldedaten der Ausführungsrolle: AWS dokumentiert, dass Code in einer AgentCore-MicroVM über MMDS temporäre Anmeldedaten der Ausführungsrolle dieser Laufzeit abrufen kann. Der Dienst betrachtet dies als erwartetes Verhalten; die Rollenberechtigungen bestimmen, was diese Anmeldedaten erlauben.^{[4], [5]}
Berechtigungsradius: Die Ausführungsrolle legt fest, auf welche AWS-Aktionen und Ressourcen Agentencode zugreifen kann. Zenity berichtet von früheren weitreichenden Berechtigungen innerhalb desselben Kontos und derselben Region. AWS empfiehlt minimale Berechtigungen; die Autorisierung richtet sich nach den für den Vorgang geltenden Identitäts- und Ressourcenrichtlinien. AWS sagt ausdrücklich, dass kontoübergreifender Zugriff Freigaben sowohl für die Rolle als auch für die Zielressource benötigt.^{[3], [1], [6]}
CWE-918 — redaktionelle Zuordnung: Diese Seite verwendet CWE-918 als redaktionelle Zuordnung für eine vom Agent-Tool ausgelöste Anfrage an einen internen Metadatendienst. AWS hat diese CWE nicht vergeben; der Metadatenzugriff ist dokumentiertes Verhalten.^{[8], [4], [1]}

Framework-Zuordnungen

Konzeptionelle Zuordnung von FlawOpen zu MITRE CWE; weder ein Anbieter noch ein CVE-Datensatz hat diese Schwachstellen-ID dieser Forschungsdemonstration zugewiesen. CWE-918

Schritt-für-Schritt Angriffsablauf

Schritt 1

Ein öffentlicher Agent verfügt über ein ausgehendes Tool

Zenity testete einen öffentlich erreichbaren AgentCore-Agenten mit einem Tool, das ausgehende Anfragen senden konnte. Das Szenario setzt einen erreichbaren Agenten und einen vom Modell beeinflussbaren Toolpfad voraus; es gilt nicht für jede Bereitstellung.^{[2], [1]}

Schritt 2

Modelleinfluss erreicht den Metadatendienst

Zenity berichtet, dass sich sein Testagent dazu bringen ließ, den lokalen Metadatendienst anzufragen. AWS dokumentiert, dass Code in der MicroVM auf MMDS-Anmeldedaten zugreifen kann. Strittig sind der Vertrauenspfad vom Modell zum Tool und die Berechtigungen dieser Anmeldedaten, nicht das Vorhandensein der eigenen Laufzeit-Anmeldedaten.^{[2], [1], [4]}

Schritt 3

Die Antwort steht für die Agentenrolle

AWS dokumentiert, dass MMDS temporäre Anmeldedaten für die konfigurierte Ausführungsrolle bereitstellt. Diese Anmeldedaten gewähren nicht automatisch Zugriff auf alle Ressourcen; IAM- und Ressourcenrichtlinien bestimmen die erlaubten Vorgänge. Für kontoübergreifenden Zugriff verlangt AWS ausdrücklich Freigaben sowohl auf der Rolle als auch auf der Zielressource.^{[4], [6], [1]}

Schritt 4

Frühere Berechtigungen vergrößerten die Auswirkungen

Zenity berichtet, dass die damalige Standardrolle Vorgänge an anderen AgentCore-Ressourcen im selben Konto und derselben Region erlaubte, darunter Aufrufe, Sitzungs-/Ereigniszugriff, Speicheroperationen und den Zugriff auf Geheimnisse. Laut Zenity schränkte AWS diese Standardrolle bis zum 29. September 2026 deutlich ein. Daraus folgt nicht, dass kundeneigene Rollen automatisch geändert wurden.^{[3], [1], [6]}

Schritt 5

Aktuelle Kontrollen schützen unterschiedliche Grenzen

Zenity sagt, dass neu bereitgestellte Agenten seit dem 14. Februar 2026 MMDSv2 verwendeten. Die aktuelle AWS-Dokumentation verlangt MMDSv2 für Laufzeitaufrufe seit dem 30. Juni 2026. AWS dokumentiert weiterhin, dass Code in der MicroVM auf Rollen-Anmeldedaten zugreifen kann. MMDSv2 ersetzt daher weder minimale IAM-Berechtigungen noch die Kontrolle modellbeeinflusster Tools. Diese Trennung ist eine defensive Schlussfolgerung aus den Quellen.^{[5], [4], [1]}

Belege und aktueller Umfang

Grenze	Beleg	Abwehrmaßnahme
Metadatenzugriff	Zenity berichtet vom Zugriff in seinem Test; AWS dokumentiert MMDS-Anmeldedaten für Code in der MicroVM.	Behandle Agentencode und modellbeeinflusste Tools als Träger der Ausführungsrolle.
Rollenberechtigungen	Zenity berichtet von früheren weitreichenden Standardberechtigungen. AWS verlangt für kontoübergreifenden Zugriff Freigaben auf Rolle und Zielressource; andere Vorgänge folgen ihren geltenden IAM- und Ressourcenrichtlinien.	Prüfe bereitgestellte Rollen und Ressourcenrichtlinien; kontrolliere die für jeden Vorgang geltenden Richtlinien und leite den Berechtigungsumfang nicht aus einem Prompt oder einem Dienststandard ab.
Änderung der Standardrolle	Zenity berichtet, AWS habe die Standardrolle am 29. September 2026 eingeschränkt. Die Untersuchung sagt nicht, dass kundeneigene Rollen automatisch geändert wurden; sie nennt keine CVE-Kennung und belegt keinen Angriff auf Kunden.	Prüfe die wirksamen Rollen in jedem Konto und jeder Region; unterstelle keine Änderung kundeneigener Rollen.
MMDSv2	Zenity datiert MMDSv2 für neue Agenten auf den 14. Februar 2026; die aktuelle AWS-Dokumentation verlangt die Aktivierung für Laufzeitaufrufe seit dem 30. Juni 2026. AWS dokumentiert weiterhin den Zugriff auf Anmeldedaten innerhalb der VM.	Aktiviere MMDSv2 und begrenze zusätzlich die Aktionen, Ressourcen und Aufrufer der Rolle.

Ursachenanalyse

Zwei Grenzen müssen getrennt bewertet werden: Modellbeeinflusste Tools können Anfragen aus der Laufzeit heraus senden, und die Ausführungsrolle bestimmt deren Berechtigungen. AWS betrachtet den Zugriff auf die eigenen Anmeldedaten der Laufzeit als erwartetes Verhalten; die von Zenity berichteten Auswirkungen auf andere Agenten hingen vom früheren Umfang der Rolle ab. MMDSv2 schränkt IAM nicht ein, und eine eingeschränkte Rolle verhindert keine modellgesteuerten internen Anfragen. Prüfe Tool-Ausgänge und IAM-Autorisierung getrennt; eingeschränkter Netzwerkverkehr beweist nicht, dass Code in der MicroVM keinen MMDS-Zugriff hat.^{[1], [3], [4], [5]}

Quellcode: Verwundbar vs. Sicher

Nur veranschaulichende IAM-Richtlinien; sie stellen weder die frühere AWS-Richtlinie noch die spätere Änderung der Standardrolle dar. AWS empfiehlt, Laufzeitberechtigungen auf konkrete Ressourcen-ARNs zu beschränken und Platzhalter zu vermeiden. Die erste Anweisung zeigt das breite Ressourcenmuster; die zweite beschränkt Aufrufe auf eine genehmigte Laufzeit, sofern diese Berechtigung nötig ist. Andernfalls entfällt sie. Prüfe die Unterstützung von Aktion/Ressource und ergänzende Ressourcenrichtlinien für die tatsächliche Bereitstellung; dies ist keine vollständige, einsatzbereite Richtlinie.^{[3], [6], [5]}

VERWUNDBARE IMPLEMENTIERUNG

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/*"
}

GEHÄRTETER SICHERHEITS-PATCH

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/APPROVED_RUNTIME_ID"
}

Checkliste für Engineering & Systemsicherheit

✓Inventarisiere jede Laufzeit-Ausführungsrolle in allen Konten und Regionen; vergleiche wirksame Berechtigungen mit aktuellen AWS- und kundeneigenen Richtlinien.^{[6], [5]}
✓Entferne laufzeitübergreifende Aufrufe, Gesprächszugriff, Geheimnisabrufe, Speicheränderungen und Bildzugriff, sofern jede Berechtigung nicht dokumentiert benötigt wird.^{[3], [6]}
✓Wenn eine Laufzeit eine andere aufrufen muss, beschränke Identitäts- und Ressourcenrichtlinien auf die genehmigte Laufzeit und den Endpunkt; teste, dass nicht zugehörige Laufzeiten abgewiesen werden.^[6]
✓Aktiviere MMDSv2 gemäß AWS-Vorgabe, behandle den Zugriff von Code in der MicroVM auf Rollen-Anmeldedaten aber als eigene Autorisierungsgrenze.^{[5], [4], [1]}
✓Begrenze die Ziele modellbeeinflusster Tools auf den Bedarf der Anwendung; dies verringert das Egress-Risiko und beweist nicht, dass Code in der VM MMDS nicht erreichen kann.^[5]
✓Weise öffentlichen Agenten Rollen mit höchstens den Berechtigungen ihrer aufrufenden Principals zu; prüfe die wirksamen Berechtigungen mit IAM Access Analyzer und negativen Autorisierungstests.^{[5], [6]}

Quellen

← AI Security Directory →