Hva forskerne gjorde
Zenity Labs publiserte 8. oktober første del av en kjede de kaller AgentCorruption. Målet er Amazon Bedrock AgentCore Runtime, den forvaltede tjenesten bedrifter bruker til å kjøre KI-agenter på AWS.
Forskerne satte opp en eksempelagent bygget med Strands, AWS sin åpne agent-SDK, og brukte det innebygde verktøyet http_request. Så ba de agenten hente AWS sitt metadata-endepunkt på 169.254.169.254 og sende svaret videre til en lytter de selv styrte. Den gjorde det. De gjentok resultatet med SDK-ens shell-verktøy.
Zenitys konklusjon handler om plattformen, ikke verktøyet: “Mikro-VM-en begrenset ikke trafikken til metadatatjenesten”, og “Isolasjonssvikten ligger på plattformnivå, ikke verktøynivå”.
Hva metadataene ga fra seg
Metadatatjenesten returnerte navnet på agentens kjørerolle og dens midlertidige STS-legitimasjon. Forskerne bekreftet at legitimasjonen virket helt utenfor AgentCore: aws sts get-caller-identity returnerte rollen agenten hadde påtatt seg.
Derfra fortsatte metadataene å gi. Brukerdata avslørte URI-en til agentens containerbilde i Elastic Container Registry. Instansmerker eksponerte sertifikat- og nøkkelmateriale for mTLS samt en forhåndssignert S3-adresse.
Hvorfor én agent nådde alle
Kjørerollen er den delen Zenity er hardest mot: “Rollen AgentCore som standard knytter til agentens kjøremiljø, har altfor høye privilegier”. Den hadde lesetilgang til ECR med jokertegn, og AgentCore navngir bilderegistre forutsigbart, som bedrock-agentcore-<agentnavn>.
Den kombinasjonen gjorde én kompromittert agent til en katalog over alle andre agenter i samme konto og region. Med forskernes ord: “å kjøre det automatiserte verktøyet vårt mot alle oppdagede agenter ga oss all kildekode for alle agenter i regionen på noen sekunder”. Zenity sier at senere innlegg tar for seg lese-, skrive- og slettemuligheter i AgentCore og andre AWS-tjenester i regionen.
Hva AWS endret, og hva selskapet sier nå
Zenitys tidslinje er ikke konsistent: teksten sier at funnene gikk til AWS 17. desember 2025, mens selskapets egen tabell daterer IMDS-varslingen til 25. desember 2025. Datoene etter det er tydeligere. 14. februar 2026 gikk AgentCore over til bare IMDSv2, slik at nyutrullede agenter starter med det. 12. april 2026 svarte AWS og lukket rapporten som “informativ”. Ingen CVE ble tildelt.
AWS sin holdning, i en uttalelse gjengitt av The Decoder 9. oktober, er at forskningen “fremstiller forventet og dokumentert atferd feilaktig som en sårbarhet”. AWS sa at en agent bare kan nå ressurser i en annen konto der en utvikler uttrykkelig har gitt rettigheter både på kjørerollen og på målressursen, og viser til sin egen dokumentasjon om rettigheter i kjøremiljøet og til roller med minst mulig privilegium. The Decoder melder at AWS siden også strammet inn standardrollen og fjernet rettigheter til å kalle andre agenter, lese private samtaler og hente legitimasjon fra Secrets Manager.
Uenigheten under overflaten
Begge sider er enige om mekanikken og uenige om hvem sin oppgave det var. AWS sitt argument er at en standardrolle er et utgangspunkt, og at dokumentasjonen sier at den skal strammes inn. Zenitys er at et forvaltet agentkjøremiljø der sandkassen ikke blokkerer metadatatjenesten, og der standardrollen kan telle opp naboene, leverer en standard de fleste kunder aldri kommer til å endre.
Det er den samme diskusjonen skybransjen hadde om åpne S3-bøtter, og den ble avgjort ved å endre standarden, ikke dokumentasjonen.
Hva man bør følge
Zenity sier dette er første del. De senere innleggene er de som betyr noe: førstegangstilgang til legitimasjon er et alvorlig funn, men det som vakte oppsikt, er sideveis bevegelse mellom alle agenter i en region, og den delen er ennå ikke publisert i detalj.
For den som kjører agenter på AgentCore i dag, er tiltaket ikke omstridt. Både leverandøren og kritikerne sier det samme: ikke gå i produksjon med standardrollen for kjøring.
