Vad forskarna gjorde
Zenity Labs publicerade den 8 oktober första delen av en kedja de kallar AgentCorruption. Målet är Amazon Bedrock AgentCore Runtime, den hanterade tjänst som företag använder för att köra AI-agenter på AWS.
Forskarna driftsatte en exempelagent byggd med Strands, AWS egen agent-SDK med öppen källkod, och använde dess inbyggda verktyg http_request. Sedan bad de agenten hämta AWS metadataändpunkt på 169.254.169.254 och skicka svaret vidare till en lyssnare de själva kontrollerade. Den gjorde det. De upprepade resultatet via SDK:ns shell-verktyg.
Zenitys slutsats handlar om plattformen snarare än verktyget: “Mikro-VM:en begränsade inte trafiken till metadatatjänsten”, och “Isoleringsbristen ligger på plattformsnivå, inte verktygsnivå”.
Vad metadatan lämnade ifrån sig
Metadatatjänsten returnerade namnet på agentens körningsroll och dess tillfälliga STS-uppgifter. Forskarna bekräftade att uppgifterna fungerade helt utanför AgentCore: aws sts get-caller-identity returnerade agentens antagna roll.
Därifrån fortsatte metadatan att ge. Användardata avslöjade URI:n till agentens containeravbild i Elastic Container Registry. Instanstaggar exponerade certifikat- och nyckelmaterial för mTLS samt en förhandssignerad S3-adress.
Varför en agent nådde alla
Körningsrollen är den del Zenity är hårdast mot: “Rollen som AgentCore som standard kopplar till agentens körmiljö har alldeles för höga privilegier”. Den bar läsbehörighet till ECR med jokertecken, och AgentCore namnger avbildsregister förutsägbart, som bedrock-agentcore-<agentnamn>.
Den kombinationen förvandlade en komprometterad agent till en katalog över alla andra agenter i samma konto och region. Med forskarnas ord: “att köra vårt automatiserade verktyg mot alla upptäckta agenter gav oss all källkod för alla agenter i regionen på några sekunder”. Zenity säger att kommande inlägg tar upp läs-, skriv- och raderingsmöjligheter i AgentCore och andra AWS-tjänster i regionen.
Vad AWS ändrade, och vad företaget säger nu
Zenitys tidslinje är inte enhetlig: texten säger att fynden gick till AWS den 17 december 2025, medan tabellen daterar IMDS-rapporten till den 25 december 2025. Datumen därefter är tydligare. Den 14 februari 2026 gick AgentCore över till enbart IMDSv2, så nydriftsatta agenter startar med det. Den 12 april 2026 svarade AWS och stängde rapporten som “informativ”. Ingen CVE tilldelades.
AWS hållning, i ett uttalande som återges av The Decoder den 9 oktober, är att forskningen “felaktigt framställer förväntat och dokumenterat beteende som en sårbarhet”. AWS sa att en agent kan nå ett annat kontos resurser endast där en utvecklare uttryckligen gett behörighet både på körningsrollen och på målresursen, och hänvisar till sin egen dokumentation om behörigheter i körmiljön och till roller med minsta möjliga privilegium. The Decoder rapporterar att AWS därefter också snävade in standardrollen och tog bort behörigheter att anropa andra agenter, läsa privata konversationer och hämta uppgifter ur Secrets Manager.
Tvisten under ytan
Båda sidor är överens om mekaniken och oense om vems uppgift det var. AWS argument är att en standardroll är en utgångspunkt och att dokumentationen säger att den ska snävas in. Zenitys är att en hanterad agentkörmiljö vars sandlåda inte blockerar metadatatjänsten, och vars standardroll kan räkna upp sina grannar, levererar ett standardläge som de flesta kunder aldrig kommer att ändra.
Det är samma diskussion som molnbranschen förde om öppna S3-hinkar, och den avgjordes genom att ändra standardläget, inte dokumentationen.
Vad man ska bevaka
Zenity säger att detta är första delen. De senare inläggen är de som betyder något: initial åtkomst till uppgifter är ett allvarligt fynd, men det som fick uppmärksamhet är sidledes förflyttning mellan alla agenter i en region, och den delen är ännu inte publicerad i detalj.
För den som kör agenter på AgentCore i dag är åtgärden inte omstridd. Både leverantören och kritikerna säger samma sak: gå inte i drift med standardrollen för körning.
