Zenity: én prompt til en AgentCore-agent ga tilgang til alle agentene i AWS-regionen

Amazon Bedrock AgentCore, AWS' plattform for å kjøre KI-agenter, starter hver agentøkt i en egen Firecracker-microVM. Zenity Labs publiserte 8. oktober en serie i tre deler, AgentCorruption, som viser hvor lite den isolasjonen holdt. Forskerne bygde en agent med AWS' Strands SDK, ba den i vanlig språk hente metadata-endepunktet på 169.254.169.254, og fikk tilbake midlertidige STS-nøkler til agentens execution-rolle.

Nøklene virket fra forskernes egen maskin, og alt videre skjedde med det vanlige AWS-API-et. Å fjerne HTTP-verktøyet hjelper ikke: Zenity fikk samme resultat med Strands' innebygde skall-verktøy, fordi feilen ligger i plattformen og ikke i verktøyet. Metadata-tjenesten ga også ut containerens konfigurasjon med konto-ID og ECR-adressen til agentens image.

«Vi snakket ikke lenger med agenten, vi var agenten.» — Zenity Labs, i første del av serien

Problemet ble stort på grunn av rollen. Med logs:DescribeLogGroups over hele regionen kunne Zenity lese ut navn og ID for alle agentene fra CloudWatch-loggruppene, og ECR-tilgang med jokertegn lot dem laste ned containerimaget, og dermed kildekoden, til hver eneste agent på noen sekunder. AWS' egen dokumentasjon for AgentCore Runtime har samme mønster: eksempelpolicyen for execution-rollen gir ecr:BatchGetImage på repository/ og logs:DescribeLogGroups på log-group:.

«Alt starter med den overprivilegerte execution-rollen som knyttes til agenten som standard.» — Zenity Labs, i andre del av serien

Med bedrock-agentcore:InvokeAgentRuntime kunne forskerne kalle interne agenter som aldri var ment å være eksponert, og i demoen hentet de ut billing.json via en billing_agent. Minnetillatelsene ListActors, ListSessions og ListEvents ga dem de private samtalene mellom brukere og agenter i hele regionen. CreateEvent lot dem plante falske hendelser med ASSISTANT-rolle i aktive økter, for eksempel en instruks om å refundere penger til angriperens bankkonto.

I tredje del gikk Zenity videre til langtidsminnet. En plantet samtalehendelse ble trukket ut av AgentCore Memory som en varig brukerinstruks om å hente instrukser fra en side forskerne kontrollerte før hvert svar. Dermed hadde de en kommando-og-kontroll-kanal de kunne endre uten å forgifte minnet på nytt, og den samme kanalen fikk agenten til å sende samtalene ut.

Zenity varslet AWS i desember 2025. AWS lukket saken som «informative» 12. april 2026, og viste til at AgentCore siden 14. februar har startet alle nye agenter med bare IMDSv2. Den endringen gjør ingenting med rettighetene i rollen, som er det som gjorde én lekket nøkkel til tilgang over hele regionen.

Hva bør du gjøre?

1. Begrens ECR-tilgangen i hver execution-rolle til agentens eget repository, som følger mønsteret bedrock-agentcore-agentnavn, i stedet for repository/*.
2. Fjern bedrock-agentcore:InvokeAgentRuntime og minnetillatelser som ListEvents, CreateEvent og DeleteEvent fra roller som ikke trenger dem, eller lås dem til agentens egen minneressurs.
3. Redeploy agenter som ble satt opp før 14. februar 2026, siden AWS bare oppgir at nye agenter starter med IMDSv2.