Hvad forskerne gjorde
Zenity Labs offentliggjorde den 8. oktober første del af en kæde, de kalder AgentCorruption. Målet er Amazon Bedrock AgentCore Runtime, den administrerede tjeneste, virksomheder bruger til at køre AI-agenter på AWS.
Forskerne opsatte en eksempelagent bygget med Strands, AWS’ åbne agent-SDK, og brugte det indbyggede værktøj http_request. Derefter bad de agenten hente AWS’ metadata-endepunkt på 169.254.169.254 og sende svaret videre til en lytter, de selv styrede. Det gjorde den. De gentog resultatet med SDK’ens shell-værktøj.
Zenitys konklusion handler om platformen snarere end værktøjet: “Mikro-VM’en begrænsede ikke trafikken til metadatatjenesten”, og “Isolationssvigtet ligger på platformsniveau, ikke værktøjsniveau”.
Hvad metadataene gav fra sig
Metadatatjenesten returnerede navnet på agentens kørselsrolle og dens midlertidige STS-legitimation. Forskerne bekræftede, at legitimationen virkede helt uden for AgentCore: aws sts get-caller-identity returnerede den rolle, agenten havde påtaget sig.
Derfra blev metadataene ved med at give. Brugerdata afslørede URI’en til agentens containerbillede i Elastic Container Registry. Instansmærker eksponerede certifikat- og nøglemateriale til mTLS samt en forhåndssigneret S3-adresse.
Hvorfor én agent nåede dem alle
Kørselsrollen er den del, Zenity er hårdest ved: “Den rolle, AgentCore som standard knytter til agentens kørselsmiljø, har alt for høje privilegier”. Den havde læseadgang til ECR med jokertegn, og AgentCore navngiver billedregistre forudsigeligt som bedrock-agentcore-<agentnavn>.
Den kombination gjorde én kompromitteret agent til et katalog over alle andre agenter i samme konto og region. Med forskernes ord: “at køre vores automatiserede værktøj mod alle fundne agenter gav os al kildekode for alle agenter i regionen på få sekunder”. Zenity siger, at senere indlæg vil dække læse-, skrive- og sletterettigheder i AgentCore og andre AWS-tjenester i regionen.
Hvad AWS ændrede, og hvad selskabet siger nu
Zenitys tidslinje er ikke konsistent: teksten siger, at fundene gik til AWS den 17. december 2025, mens selskabets egen tabel daterer IMDS-indberetningen til den 25. december 2025. Datoerne derefter er tydeligere. Den 14. februar 2026 gik AgentCore over til kun IMDSv2, så nyudrullede agenter starter med det. Den 12. april 2026 svarede AWS og lukkede rapporten som “informativ”. Der blev ikke tildelt nogen CVE.
AWS’ holdning, i en udtalelse gengivet af The Decoder den 9. oktober, er, at forskningen “fremstiller forventet og dokumenteret adfærd unøjagtigt som en sårbarhed”. AWS sagde, at en agent kun kan nå en anden kontos ressourcer, hvor en udvikler udtrykkeligt har givet rettigheder både på kørselsrollen og på målressourcen, og henviser til sin egen dokumentation om rettigheder i kørselsmiljøet og til roller med mindst mulige privilegier. The Decoder beretter, at AWS siden også strammede standardrollen og fjernede rettigheder til at kalde andre agenter, læse private samtaler og hente legitimation fra Secrets Manager.
Uenigheden under overfladen
Begge sider er enige om mekanikken og uenige om, hvis opgave det var. AWS’ argument er, at en standardrolle er et udgangspunkt, og at dokumentationen siger, den skal strammes. Zenitys er, at et administreret agentkørselsmiljø, hvis sandkasse ikke blokerer metadatatjenesten, og hvis standardrolle kan optælle naboerne, leverer en standard, som de fleste kunder aldrig vil ændre.
Det er den samme diskussion, skybranchen havde om offentlige S3-spande, og den blev afgjort ved at ændre standarden, ikke dokumentationen.
Hvad man skal følge
Zenity siger, at dette er første del. De senere indlæg er dem, der betyder noget: første adgang til legitimation er et alvorligt fund, men det, der vakte opmærksomhed, er sidelæns bevægelse mellem alle agenter i en region, og den del er endnu ikke offentliggjort i detaljer.
For den, der kører agenter på AgentCore i dag, er handlingen ikke til diskussion. Både leverandøren og kritikerne siger det samme: gå ikke i produktion med standardrollen for kørsel.
