Zenity AgentCorruption legte einen kontoübergreifenden Übernahmepfad in AWS AgentCore offen
Forscher von Zenity AgentCorruption fanden heraus, dass ein einzelner bösartiger Prompt temporäre AWS-Anmeldedaten eines öffentlich erreichbaren Amazon Bedrock AgentCore-Agenten offenlegen konnte. Diese Anmeldedaten eröffneten Berichten zufolge Zugriffswege auf jede AgentCore-Runtime, die dasselbe anfällige Konto, dieselbe Region und dieselbe weitreichend berechtigte Standardrolle nutzte. Die Erkenntnis machte aus einem bekannten Prompt-Injection-Problem einen kontoübergreifenden Cloud-Sicherheitsvorfall.
Der Angriff erforderte weder das Knacken eines Foundation Models noch einen Ausbruch in einen fremden AWS-Kunden oder den Diebstahl eines Administratorpassworts. Er kombinierte die Fähigkeit eines Agenten, HTTP-Anfragen zu stellen, mit Metadaten-Anmeldedaten und übermäßigen Berechtigungen in Identity and Access Management. Zenity zufolge erreichte die Angriffskette private Agenten, Quellcode, Gesprächsverläufe, gespeicherte Geheimnisse und Langzeitspeicher.
Diese Kombination ist wichtiger als die Schlagzeilenzahl eines einzelnen Prompts. AWS vermarktete AgentCore als verwaltete Infrastruktur für den sicheren Betrieb von Produktionsagenten, einschließlich Identität, Speicher, Tools, Observability und isolierten Runtimes. AgentCorruption zeigte, wie diese verknüpften Dienste einen kompromittierten Agenten verstärken können, wenn ihre Autorisierungsgrenzen zu weit gefasst sind.
Es gibt jedoch eine wichtige Einschränkung. Zenity legte die Probleme Monate vor der Veröffentlichung seiner Forschung am 8. Oktober 2026 offen. Die Forscher berichteten, AWS habe die Standard-Ausführungsrolle vor der Veröffentlichung eingeschränkt, während die AWS-Dokumentation inzwischen stärkere Metadatenkontrollen vorschreibt und vor dem Produktionseinsatz weitreichender, per CLI erzeugter Richtlinien warnt.
Das Ergebnis ist kein Beleg dafür, dass jede aktuelle AgentCore-Bereitstellung weiterhin für die vollständige Angriffskette offensteht. Es ist ein Beleg dafür, dass Teams verwaltete Agenteninfrastruktur nicht als Ersatz für das Prinzip der minimalen Berechtigungen behandeln dürfen. Agentensicherheit muss nun das Verhalten von Sprachmodellen, Runtime-Anmeldedaten, Cloud-Berechtigungen, Speicherintegrität und laterale Bewegungen gemeinsam abdecken.
Wie Zenity AgentCorruption einen Prompt in AWS-Anmeldedaten verwandelte
Der erste Fehler überschritt die Grenze zwischen nicht vertrauenswürdiger Spracheingabe und einer vertrauenswürdigen Cloud-Identität.
Laut Zenitys AgentCorruption research akzeptierte ein exponierter AgentCore-Agent einen Prompt, der ihn anwies, einen lokalen Metadaten-Endpunkt abzufragen. Die Anfrage zielte auf 169.254.169.254, eine Link-Local-Adresse, die AWS-Compute-Umgebungen zur Bereitstellung von Workload-Metadaten und temporären Rollen-Anmeldedaten verwenden.
Der betreffende Dienst ist der Instance Metadata Service, meist als IMDS abgekürzt. Die Firecracker-microVM-Umgebung von AgentCore nutzt einen verwandten MicroVM Metadata Service, kurz MMDS, um Anmeldedaten der Ausführungsrolle innerhalb der Workload verfügbar zu machen.
Dieser Mechanismus zur Bereitstellung von Anmeldedaten hat einen legitimen Zweck. Ein Agent kann eine temporäre Autorisierung benötigen, um ein freigegebenes S3-Objekt zu lesen, einen anderen AWS-Dienst aufzurufen oder eine geschäftliche Aufgabe auszuführen. Temporäre Anmeldedaten vermeiden zudem, permanente Zugriffsschlüssel in Code oder Container-Images einzubetten.
Das Problem entsteht, wenn ein nicht vertrauenswürdiger Prompt ein Tool dazu veranlassen kann, den Metadaten-Endpunkt zu kontaktieren. Zenity zufolge sendete ein HTTP-fähiges Tool die Anfrage aus der microVM, sodass der Metadatendienst sie als Anfrage einer lokalen Workload behandelte. Die Antwort legte den temporären Zugriffsschlüssel, geheimen Schlüssel und Session-Token der Agent-Runtime offen.
Dabei handelt es sich um ein Server-Side Request Forgery-Muster, üblicherweise SSRF genannt. Ein Angreifer veranlasst eine serverseitige Komponente, ein Ziel anzufragen, das der Angreifer nicht direkt erreichen kann. Hier wurde der Agent Berichten zufolge zur anfragenden Komponente, weil seine Tools ausgehende HTTP-Aufrufe durchführen konnten.
Die Prompt Injection lieferte die Absicht, das HTTP-Tool die Fähigkeit. Der Metadatendienst lieferte anschließend eine Cloud-Identität. Keines dieser Elemente allein hätte die berichtete Reichweite ermöglicht.
Ein Modell, das lediglich unsicheren Text erzeugte, hätte keine Anmeldedaten gestohlen. Ein vor den Tools des Agenten geschützter Metadaten-Endpunkt hätte den Pfad unterbrochen. Eine eng begrenzte Ausführungsrolle hätte die Folgen selbst nach einem Diebstahl von Anmeldedaten eingedämmt.
AWS dokumentiert diese Eigenschaft der Preisgabe von Anmeldedaten inzwischen ausdrücklich. Seine credential guidance besagt, dass Code oder Akteure innerhalb einer microVM den Metadaten-Endpunkt aufrufen und auf die verfügbaren Anmeldedaten zugreifen können. AWS weist Kunden daher an, Ausführungsrollen auf die Berechtigungen zu beschränken, die ihre Workloads tatsächlich benötigen.
Zenity meldete AWS das Metadatenproblem erstmals am 25. Dezember 2025. Die Forscher sagen, AWS habe den Bericht am 12. April 2026 als informativ geschlossen. AWS teilte ihnen mit, dass neu bereitgestellte Agenten seit dem 14. Februar IMDSv2 nutzten.
IMDSv2 verlangt einen Session-Token, bevor ein Client Metadaten abrufen kann. Dieses Design blockiert viele herkömmliche SSRF-Angriffe, weil der Angreifer die vorbereitende Token-Anfrage und ihre Header nicht immer kontrollieren kann.
Ein autonomer Agent verändert diese Annahme. Wenn der Agent ausreichend flexible Anfragen stellen kann, könnte er den Token erhalten und anschließend Anmeldedaten abrufen. Zenity argumentiert, dass die Anforderung von IMDSv2 die Hürden erhöhte, das zugrunde liegende Vertrauensproblem aber nicht beseitigte.
AWS ging später über eine optionale Einführung hinaus. Aktuelle Runtime-Leitlinien besagen, dass AgentCore-Runtimes ohne aktiviertes MMDSv2 seit dem 30. Juni 2026 abgelehnt werden. Diese Kontrolle verbessert die Ausgangslage, entschuldigt jedoch keine übermäßigen Berechtigungen, die mit Anmeldedaten verknüpft sind, auf die legitimer Runtime-Code weiterhin zugreifen kann.
Die wesentliche Lehre ist architektonischer Natur. Prompt Injection wird zum Cloud-Kompromittierungsfall, wenn ein Agent natürlichsprachliche Anweisungen in privilegierte Netzwerk- und Identitätsoperationen übersetzen kann. Das Filtern des bösartigen Satzes adressiert nur eine Ebene dieses Pfads.
Die Standardrolle machte aus einem Agenten das Problem aller
Gestohlene Anmeldedaten wurden zu kontoübergreifendem Zugriff, weil die getestete Ausführungsrolle einem Agenten regionsweiten Zugriff auf andere Agenten anvertraute.
Zenity reichte am 12. Januar 2026 einen zweiten Bericht ein, der sich auf die Berechtigungen hinter der ursprünglichen Kompromittierung konzentrierte. Die Forscher erklärten, die Standardrolle sei nicht auf die Runtime beschränkt gewesen, die sie annahm. Mehrere Berechtigungen galten für AgentCore-Ressourcen im gesamten AWS-Konto und in derselben Region.
Der erste Schritt der Ausweitung nutzte CloudWatch Logs. Zenity zufolge ermöglichte logs:DescribeLogGroups der kompromittierten Identität, Namen regionaler Log-Gruppen aufzulisten. Die AgentCore-Namenskonventionen legten in diesen Namen Kennungen für Runtimes und Speicherressourcen offen.
Die Angreifer benötigten kein bestehendes Inventar privater Agenten. Sie konnten Runtime-Kennungen Berichten zufolge aus den für die Rolle bereits sichtbaren Betriebsmetadaten ableiten. Die Erkundung verwandelte eine gestohlene Identität von einem lokalen Einstiegspunkt in eine Karte benachbarter Ressourcen.
Die Rolle enthielt zudem regionale Berechtigungen für Amazon Elastic Container Registry. Zenity zufolge ermöglichte eine vorhersehbare Repository-Benennung den Forschern, AgentCore-Runtimes mit Container-Images zu verknüpfen. Das Abrufen dieser Images legte Anwendungscode und potenziell sensible, in den bereitgestellten Artefakten eingebettete Konfiguration offen.
Diese Erkenntnis stellt eine verbreitete Annahme über verwaltete Runtimes infrage. Eine microVM kann eine laufende Sitzung von einer anderen isolieren, während IAM die Sitzung weiterhin zum Abrufen nicht zusammenhängender Ressourcen autorisiert. Compute-Isolation und Autorisierungsisolation lösen unterschiedliche Probleme.
Als Nächstes folgte bedrock-agentcore:InvokeAgentRuntime. Zenitys role analysis zeigt, dass die getestete Richtlinie Wildcard-Runtime-Ressourcen in der Region abdeckte. Die gestohlenen Anmeldedaten konnten daher private Agenten aufrufen, die ein externer Nutzer niemals hätte erreichen sollen.
Ein öffentlicher Support-Bot könnte nur begrenzte Tools und sorgfältig gefilterte Daten haben. Ein privater Abrechnungsagent könnte Zugriff auf Finanzdateien, interne APIs oder Transaktionssysteme besitzen. Der regionsweite Aufruf verband den exponierten Einstiegspunkt mit dem sensibleren Agenten.
Zenity demonstrierte diesen Pfad gegen einen Test-Abrechnungsagenten. Die Forscher ermittelten dessen Tools, identifizierten eine Datei namens billing.json und wiesen den Agenten an, ihren Inhalt zurückzugeben. Dieses Szenario veranschaulichte laterale Bewegung über legitime AgentCore-APIs statt über einen zweiten Software-Exploit.
Der Gesprächsspeicher vergrößerte den Schaden erneut. AgentCore Memory speichert kurzfristige Ereignisse nach Speicherressource, Akteur und Sitzung. Langfristige Strategien können extrahierte Fakten, Präferenzen, Zusammenfassungen und Erkenntnisse für künftige Interaktionen bewahren.
Zenity zufolge konnte die kompromittierte Rolle Akteure und Sitzungen auflisten und anschließend ListEvents aufrufen, um Gesprächsinhalte abzurufen. Da diese Berechtigungen Wildcard-Speicherressourcen abdeckten, griffen die Forscher Berichten zufolge auf Unterhaltungen anderer Agenten und Nutzer zu.
Das offengelegte Material konnte personenbezogene Informationen, Quellcode, interne Pläne, Kundendaten oder während der Fehlerbehebung eingefügte Anmeldedaten enthalten. Die Plattform kann nicht feststellen, ob ein in eine Unterhaltung eingegebenes Geheimnis dort hätte stehen sollen. Die Autorisierung muss verhindern, dass nicht zugehörige Workloads die Sitzung überhaupt lesen können.
Schreibberechtigungen schufen eine separate Bedrohung für die Integrität. Zenity stellte fest, dass die Rolle Speicherereignisse erstellen und löschen konnte. Ein Angreifer könnte falschen Kontext in eine aktive Sitzung einschleusen, Tool-Ergebnisse entfernen oder beeinflussen, was der Agent für geschehen hielt.
Dieses Risiko unterscheidet sich von gewöhnlichem Datendiebstahl. Ein manipulierter Agent kann sich weiterhin als vertrauenswürdiger Unternehmensdienst präsentieren, während er auf Basis vom Angreifer gelieferter Kontexte handelt. Nutzer sehen die feindliche Anweisung möglicherweise nicht, weil sie im gespeicherten Sitzungsstatus statt in ihrem sichtbaren Prompt liegt.
AWS teilte Zenity am 25. Februar mit, dass sein Team das zugrunde liegende Problem bearbeite. Die Forscher prüften am 22. Juni erneut und berichteten, dass die Standardrolle unverändert geblieben sei. Diese Zeitspanne ließ die weitreichende Rolle mehrere Monate lang im Zentrum der ungelösten Angriffskette.
Bei einer abschließenden Prüfung am 29. September stellte Zenity erhebliche Einschränkungen fest. Die Forscher erklärten, AWS habe Berechtigungen entfernt, die Runtime-übergreifende Aufrufe, den Zugriff auf private Unterhaltungen und den Abruf über Secrets Manager ermöglichten. Weitere Berechtigungen seien ebenfalls eingeschränkt worden.
Diese Behebung verändert die aktuelle Risikobewertung erheblich. Die veröffentlichte Angriffskette dokumentiert, was die Forscher unter früheren Standardeinstellungen erreichten, nicht den Beweis, dass die identischen Berechtigungen heute noch angehängt sind. Bestehende, von Kunden erstellte Rollen, kopierte Richtlinien und ältere Bereitstellungen verdienen weiterhin eine direkte Prüfung.
Verwaltete Isolation traf auf eine überberechtigte Realität
AgentCorruption legte einen Konflikt zwischen AgentCores Isolierungsversprechen und den gemeinsamen Autorisierungspfaden rund um jede isolierte Runtime offen.
AWS veröffentlichte AgentCore im Oktober 2025 für die allgemeine Verfügbarkeit und beschrieb es als Infrastruktur, um Agenten sicher und im großen Maßstab auszuführen. Die Plattform kombinierte Runtime-Isolation mit Identität, Speicher, Gateways, Browserautomatisierung, Codeausführung und Observability.
Jede Fähigkeit löst ein reales Bereitstellungsproblem. Agenten benötigen zustandsbehaftete Informationen über Unterhaltungen hinweg, Anmeldedaten für verbundene Dienste, gesteuerten Tool-Zugriff und Tracing für unvorhersehbare Aktionen. Der unabhängige Aufbau all dieser Komponenten erhöht Kosten und Komplexität.
Integration schafft jedoch auch Sicherheitsabhängigkeiten. Eine Runtime kann rechnerisch isoliert sein, während ihre Ausführungsrolle eine andere Runtime aufrufen kann. Ein Token Vault kann Secrets aus dem Anwendungscode heraushalten, während eine zu weit gefasste Identität diese Secrets anfordern kann.
Das ist die zentrale Umkehrung bei Zenity AgentCorruption. Die vernetzten Kontrollen der verwalteten Plattform sollten den sicheren Produktionseinsatz unterstützen. Unter den getesteten Standardeinstellungen übertrugen eben diese Verbindungen den Kompromittierungszustand Berichten zufolge über Servicegrenzen hinweg.
Die aktuellen Runtime-Sicherheitspraktiken von AWS erkennen diese Unterscheidung direkter an. Die Dokumentation warnt Kunden davor, per CLI erzeugte Entwicklungsrichtlinien in der Produktion einzusetzen. Sie empfiehlt spezifische Runtime-ARNs statt Ressourcenanweisungen mit Platzhaltern.
Die Leitlinie besagt zudem, dass eine Ausführungsrolle über gleich viele oder weniger Berechtigungen verfügen sollte als die Principals, die sie aufrufen dürfen. Diese Regel bietet eine hilfreiche Möglichkeit, öffentliche Agents zu bewerten. Wenn ein anonymer Nutzer eine Runtime aufrufen kann, sollte die Runtime keine Berechtigungen erben, die anonymen Nutzern nicht zur Verfügung stehen.
Öffentliche Erreichbarkeit macht einen Agent nicht automatisch unsicher. Sie verändert das Vertrauensniveau jeder Anweisung, die das Modell erreicht. Die Ausführungsrolle muss davon ausgehen, dass einige akzeptierte Eingaben bösartig, irreführend oder darauf ausgelegt sein werden, Tools zu manipulieren.
Authentifizierung hilft bei der Identifizierung von Aufrufern, beseitigt Prompt Injection jedoch nicht. Ein legitimes Kundenkonto kann feindselige Anweisungen übermitteln. Kompromittierte Dokumente und Webseiten können zudem indirekte Prompt Injection ausliefern, nachdem ein Nutzer einen Agent gebeten hat, sie zusammenzufassen.
Gateway-Kontrollen können die Angriffsfläche verringern, indem sie Anfragen validieren, bevor diese eine Runtime erreichen. Guardrails können bekannte Angriffsmuster erkennen, während Interceptors Vorgänge anhand von Identität und Kontext beschränken können. Diese Kontrollen funktionieren nur, wenn Aufrufer das Gateway nicht umgehen und die Runtime direkt aufrufen können.
Die Sicherheitsleitlinien von AgentCore empfehlen nun, Runtime-Aufrufe auf die Ausführungsrolle des Gateways zu beschränken, wenn ein Gateway als vorgesehener Einstiegspunkt dient. Dieser Ansatz verlagert die Autorisierung aus dem Entscheidungszyklus des Modells heraus. Der Agent kann sich nicht durch eine IAM-Ablehnung hindurchargumentieren.
Die Eingrenzung von IAM-Ressourcen bleibt die stärkere Eindämmungsgrenze. Ein Kundensupport-Agent sollte keine Wildcard-Berechtigung erhalten, jede Runtime aufzurufen. Eine Berechtigung zum Schreiben in den Speicher sollte die konkrete Speicherressource, den Akteursbereich und den geschäftlichen Bedarf benennen, wo immer der Service diese Präzision unterstützt.
Dieselbe Überlegung gilt für Container-Repositorys und Logs. Operative Metadaten wirken oft weniger sensibel als Anwendungsdaten. Dennoch können Namen, Kennungen, Endpunkte und Repository-Muster zu einem Erkennungssystem für laterale Bewegungen werden.
Organisationen benötigen zudem eine Trennung nach Vertrauensniveau. Öffentliche und interne Agents sollten nicht dieselben Ausführungsrollen nutzen, nur weil ein Einrichtungstool diese Konfiguration bequem macht. Sensible Funktionen können über AWS-Konten oder Regionen hinweg aufgeteilt werden, wenn Kontrollen auf Kontoebene eine klarere Isolation bieten.
Kein Prompt-Filter kann garantieren, dass ein Modell jede bösartige Variante zurückweist. Modelle interpretieren Bedeutung, statt eine endliche Befehlsgrammatik durchzusetzen. Angreifer können Anfragen umformulieren, Anweisungen in abgerufenen Daten verstecken oder Konflikte zwischen System- und Nutzerkontext ausnutzen.
Diese Einschränkung macht den Einsatz von Agents nicht unpraktikabel. Sie verändert, worauf Verteidiger ihr Vertrauen stützen sollten. Abwehrmaßnahmen auf Modellebene können erfolgreiche Manipulation verringern, während deterministische Cloud-Kontrollen begrenzen, was ein manipuliertes Modell tun kann.
Teams sollten Prompts als nicht vertrauenswürdige Eingaben und Tools als privilegierte Schnittstellen behandeln. Jeder Tool-Aufruf benötigt eine Autorisierungsentscheidung auf Grundlage des authentifizierten Nutzers, der angeforderten Ressource und der erlaubten Operation. Die Entscheidung des Modells, ein Tool aufzurufen, darf niemals selbst als Autorisierung dienen.
Für Organisationen, die diese Entscheidungen dokumentieren, kann eine durchsuchbare Sammlung von Engineering-Wissensdatenbanken dabei helfen, Runtime-Verantwortlichkeiten, IAM-Richtlinien, Bedrohungsmodelle und Incident-Verfahren zu verknüpfen. Diese Dokumentation wird wichtig, wenn mehrere Teams Agents über gemeinsame Cloud-Konten bereitstellen.
Memory Poisoning verwandelte einen Einbruch in dauerhafte Kontrolle
Der folgenreichste Teil der Kette war nicht der Diebstahl von Zugangsdaten, sondern die Fähigkeit, zu korrumpieren, woran sich vertrauenswürdige Agents später erinnerten.
AgentCore Memory unterstützt kurz- und langfristigen Zustand. Der Kurzzeitspeicher zeichnet Ereignisse Zug um Zug in einer Sitzung auf. Der Langzeitspeicher extrahiert wiederverwendbare Informationen, sodass ein Agent Präferenzen, Fakten, Zusammenfassungen oder frühere Erkenntnisse abrufen kann.
Diese Persistenz verbessert die Nutzbarkeit. Ein Support-Agent kann sich an einen ungelösten Fall erinnern, während ein Arbeitsplatzassistent Formatierungspräferenzen bewahren kann. Sie schafft jedoch auch einen dauerhaften Eingabekanal, der künftige Entscheidungen beeinflussen kann.
Zenitys Studie zu Memory Poisoning besagt, dass die gestohlene Rolle Speicherkennungen über CloudWatch-Logs ermitteln konnte. Anschließend konnte sie Akteure, Sitzungen und konfigurierte Speicherstrategien auflisten.
Die Forscher verwendeten CreateEvent, um feindselige Inhalte zu Gesprächen anderer Agents hinzuzufügen. Die Speicherextraktion verarbeitete diese Ereignisse und wandelte ihre Inhalte in Langzeiteinträge um. Künftige Sitzungen konnten diese Einträge als vertrauenswürdigen Kontext abrufen.
Ein Angreifer musste die ursprüngliche Prompt Injection daher nicht für jede Interaktion wiederholen. Eine platzierte Anweisung konnte die kompromittierte Sitzung überdauern und spätere Gespräche beeinflussen. Die sichtbare Oberfläche würde weiterhin wie der offizielle Agent der Organisation wirken.
Zenity bezeichnet dies als persistentes Command and Control. Diese Formulierung sollte als Charakterisierung ihrer Testumgebung durch die Forscher verstanden werden. Das genaue Verhalten hängt von Speicherkonfiguration, Abruflogik, Modellverhalten, Tools und Autorisierungskontrollen ab.
Das demonstrierte Primitive ist dennoch schwerwiegend. Eine falsche Präferenz könnte einem Agent mitteilen, Daten an eine vom Angreifer kontrollierte Adresse zu senden. Eine erfundene Tatsache könnte einen Workflow umleiten, während eine vergiftete Zusammenfassung die vorherige Zustimmung eines Kunden falsch darstellen könnte.
Die Manipulation des Kurzzeitverlaufs schafft unmittelbare Risiken. Ein eingefügtes Assistant-Ereignis kann dem Modell als etwas erscheinen, das es zuvor entschieden hat. Ein gelöschtes Tool-Ergebnis kann Belege entfernen, die eine unsichere Aktion andernfalls verhindert hätten.
Traditionelle Anwendungssicherheit behandelt Logs und Verlauf oft als Beweismittel nach einem Incident. Agent-Systeme können gespeicherten Verlauf aktiv in künftige Entscheidungen zurückführen. Integritätsverletzungen in diesen Daten können daher die Ausführung verändern und nicht nur die Untersuchung erschweren.
Memory erschwert auch die Wiederherstellung. Das Rotieren gestohlener Zugangsdaten stoppt fortgesetzten API-Zugriff, entfernt jedoch nicht automatisch jeden vergifteten Eintrag. Incident-Responder müssen ermitteln, welche Sitzungen, Ereignisse, Zusammenfassungen und extrahierten Erinnerungen die kompromittierte Identität berührt hat.
Die aktuellen Memory-Leitlinien von AWS empfehlen Eingabevalidierung, Guardrails vor der Persistierung und regelmäßige Tests auf Prompt Injection. Sie betonen außerdem Least-Privilege-Richtlinien für Speicherressourcen.
Diese Kontrollen sollten mit Herkunftsnachweisen kombiniert werden. Ein Langzeiteintrag sollte genügend Metadaten enthalten, um zu zeigen, welcher Nutzer, Agent, welche Sitzung und welcher Extraktionsprozess ihn erstellt hat. Sicherheitsteams benötigen eine effiziente Möglichkeit, Erinnerungen zu quarantänisieren, die mit einer kompromittierten Identität verknüpft sind.
Aktionen mit hohem Risiko sollten sich nicht auf abgerufenen Kontext als Nachweis einer Autorisierung stützen. Ein Agent könnte sich daran erinnern, dass ein Nutzer ein bestimmtes Bankkonto bevorzugt, doch eine Überweisung erfordert weiterhin eine aktuelle, unabhängig verifizierte Freigabe. Memory kann einen Workflow leiten, ihn aber nicht autorisieren.
Organisationen sollten Datentypen zudem nach ihren Folgen trennen. Präferenzen zum Schreibstil bergen weniger Risiko als Zahlungsanweisungen, Zugriffsgewährungen oder Zieladressen. Sensible Erinnerungen benötigen strengere Regeln zur Erstellung, kürzere Aufbewahrungsfristen und eine intensivere Prüfung.
Das Monitoring muss sowohl Schreib- als auch Lesezugriffe abdecken. Ungewöhnliche Häufungen von CreateEvent, speicherübergreifende Zugriffe zwischen Agents oder Änderungen, die viele Akteure betreffen, können auf Missbrauch hindeuten. CloudTrail, Anwendungslogs und AgentCore-Observability-Daten sollten Warnmeldungen speisen, die an das erwartete Workload-Verhalten gekoppelt sind.
Hier reicht der Incident über AWS hinaus. Jede Agent-Plattform, die persistenten Speicher mit Tools kombiniert, steht vor einem ähnlichen Integritätsproblem. Die Implementierungsdetails unterscheiden sich, doch die Vertrauensfrage bleibt gleich.
Welche Informationen darf der Agent speichern, wer darf sie schreiben und von welchen Entscheidungen dürfen sie später abhängen? AgentCorruption zeigt, dass unvollständige Antworten einen vorübergehenden Zugangspunkt in anhaltenden Einfluss verwandeln können.
Was AgentCore-Kunden jetzt überprüfen sollten
Die vollständige historische Angriffskette wurde vor der Veröffentlichung eingegrenzt, doch kundendefinierte Berechtigungen und ältere Konfigurationen bestimmen die verbleibende Gefährdung jeder Bereitstellung.
Die erste Prüfung betrifft die Ausführungsrolle, die an jede AgentCore-Runtime angehängt ist. Teams sollten erlaubte Aktionen und Ressourcen auflisten und dann Berechtigungen entfernen, die nicht mit der dokumentierten Funktion der Runtime zusammenhängen. Wildcards verdienen eine konkrete Begründung statt routinemäßiger Akzeptanz.
Produktionsrollen sollten keine für Prototypen erzeugten Richtlinien erben. AWS bezeichnet per CLI erzeugte Berechtigungen inzwischen als Entwicklungserleichterungen und rät Kunden, eng abgegrenzte Alternativen zu erstellen. Eine erfolgreiche Testbereitstellung ist kein Beleg dafür, dass ihre Rolle in die Produktion gehört.
Die zweite Prüfung ist die Durchsetzung von MMDSv2. Aktuelle Runtimes sollten requireMMDSV2 in ihrer Metadatenkonfiguration auf true setzen. Teams sollten die bereitgestellte Konfiguration überprüfen, statt anzunehmen, dass ein Plattform-Update jede historische Runtime korrekt verändert hat.
MMDSv2 sollte weiterhin nur als eine Schutzschicht betrachtet werden. Wenn ein Agent legitim einen flexiblen HTTP-Client, eine Shell oder einen Code-Interpreter steuert, kann er Anfragen ausführen, von denen vereinfachte SSRF-Schutzmaßnahmen annahmen, dass Angreifer sie nicht konstruieren könnten. Netzwerkregeln sollten unnötigen Zugriff auf Metadatenendpunkte blockieren.
Die dritte Prüfung betrifft die eingehende Erreichbarkeit. Teams sollten ermitteln, welche Runtimes direkte öffentliche, IAM- oder JWT-basierte Aufrufe akzeptieren. Öffentliche Agents benötigen die kleinsten Rollen, da ihre Eingaben von der am wenigsten vertrauenswürdigen Zielgruppe stammen.
Wenn AgentCore Gateway die Durchsetzung von Richtlinien übernimmt, sollten direkte Runtime-Aufrufe eingeschränkt werden. Andernfalls kann ein Angreifer Gateway-Guardrails umgehen und den Runtime-Endpunkt über einen anderen autorisierten Pfad aufrufen. Authentifizierung und Nutzerkennungen müssen aus verifizierten Principals abgeleitet werden.
Die vierte Prüfung umfasst laterale Bewegungen. Eine Runtime sollte keine nicht zusammenhängenden Agents aufrufen, keine regionalen Log-Gruppen auflisten, keine nicht zusammenhängenden ECR-Images abrufen und keine Speicherressourcen enumerieren. Diese Berechtigungen sollten nach Runtime-ARN und Geschäftsfunktion isoliert werden.
Die fünfte Prüfung betrifft die Vertraulichkeit von Gesprächen. Sicherheitsteams sollten testen, ob eine Runtime-Identität Akteure, Sitzungen oder Ereignisse auflisten kann, die zu einem anderen Workload gehören. Sie sollten außerdem überprüfen, ob Ressourcenrichtlinien und Identitätsrichtlinien gemeinsam die beabsichtigte Ablehnung erzeugen.
Die sechste Prüfung betrifft die Memory-Integrität. Teams sollten Principals mit CreateEvent, DeleteEvent und Zugriff auf Langzeitspeicher inventarisieren. Warnmeldungen sollten normale Schreibvorgänge in Nutzersitzungen von agentübergreifenden oder hochvolumigen Änderungen unterscheiden.
Die siebte Prüfung betrifft gespeicherte Zugangsdaten. AgentCore Identity kann Tokens von Drittanbietern außerhalb des Anwendungscodes halten, doch IAM kontrolliert weiterhin, wer sie abrufen darf. Runtime-Rollen sollten keinen breit gefassten Zugriff auf API-Schlüssel oder Secrets-Manager-Werte haben.
Ermittler, die mögliche historische Expositionen prüfen, benötigen mehr als aktuelle Richtlinien-Snapshots. Sie sollten CloudTrail-Ereignisse, Laufzeit-Aufrufprotokolle, metadatenbezogene Aktivitäten, ECR-Image-Abrufe, Memory-API-Aufrufe und Secrets-Manager-Zugriffe im relevanten Zeitraum untersuchen.
Temporäre Anmeldedaten laufen ab, ihre Auswirkungen können jedoch fortbestehen. Ein Angreifer könnte Quellcode kopieren, ein abgerufenes Geheimnis behalten, den Sitzungsverlauf verändern oder vor dem Ablauf einen langfristigen Speicher manipulieren. Reaktionspläne sollten die Rotation von Anmeldedaten und die Validierung des Zustands umfassen.
Zwei Unsicherheiten bleiben zentral. Zenitys Erkenntnisse stammen aus von Forschern kontrollierten Bereitstellungen, und die hier angeführten öffentlichen Belege bestätigen keine weitverbreitete Ausnutzung in Kundenumgebungen. AWS hat kein eigenes Sicherheitsbulletin veröffentlicht, das die vollständige AgentCorruption-Kette beschreibt.
Dieses Fehlen sollte überzogene Behauptungen verhindern, nicht die Forschung abtun. Zenity veröffentlichte detaillierte Berechtigungsbeispiele, Ausnutzungspfade und Offenlegungsdaten. Die aktualisierte AWS-Dokumentation bestätigt unabhängig, dass Laufzeitcode auf Metadaten-Anmeldedaten zugreifen kann und breit gefasste Entwicklungsrichtlinien für Produktionsumgebungen ungeeignet sind.
Das erste Signal, auf das es zu achten gilt, ist, ob AWS eine formelle Empfehlung, einen Rückblick oder zusätzliche Hinweise zur Richtlinienmigration veröffentlicht. Eine solche Dokumentation würde betroffene Konfigurationen klären und zeigen, ob Kunden ältere Rollen manuell beheben müssen.
Das zweite Signal sind weitere Einschränkungen des Metadatenzugriffs durch vom Agenten gesteuerte Tools. Eine Kontrolle, die Laufzeit-Workloads den Zugriff auf Anmeldedaten-Endpunkte verwehrt, würde die Abhängigkeit vom Modellverhalten verringern. Granulare Egress-Richtlinien könnten zudem andere SSRF-Pfade eindämmen.
Das dritte Signal ist ein für Kunden sichtbarer Schutz des Speichers. Bessere Herkunftsnachweise, begrenzte Schreibberechtigungen, Integritätswarnungen und Werkzeuge zur Quarantäne großer Datenmengen würden Memory Poisoning leichter erkennbar und rückgängig machen. Diese Fähigkeiten sind wichtig, da langfristiger Speicher in geschäftskritische Arbeitsabläufe übergeht.
Zenity AgentCorruption stellt letztlich eine umfassendere Annahme hinter Unternehmensagenten auf die Probe. Verwaltete Infrastruktur kann die operative Komplexität verringern, doch sie kann Identität, Speicher und Tool-Zugriff nicht sicher in einer einzigen, weitreichend vertrauenswürdigen Rolle zusammenführen.
Entwickler sollten nun für jeden bereitgestellten Agenten eine konkrete Frage stellen: Was geschieht, nachdem das Modell der schlimmstmöglichen Anweisung folgt, die es erhalten kann? Verfolgen Sie die daraus resultierenden Tool-Aufrufe, Anmeldedaten, Berechtigungen, erreichbaren Agenten und beschreibbaren Speicher.
Wenn die Antwort über die eng gefasste Aufgabe dieses Agenten hinausgeht, behandeln Sie den Umfang als aktiven Sicherheitsmangel. Überprüfen Sie die Rolle, isolieren Sie öffentliche Laufzeiten, testen Sie Speichergrenzen und bestätigen Sie die aktuellen AWS-Standardeinstellungen direkt. Der sicherste Agent ist nicht derjenige, der Manipulation stets zurückweist. Es ist derjenige, dessen Cloud-Berechtigungen verhindern, dass eine manipulierte Antwort zu einem kontoweiten Vorfall wird.
