En prompt, en agent, ett helt AWS-konto: Inuti AgentCorruption på Amazon Bedrock AgentCore

Den 8 oktober 2026 Zenity Labs avslöjade AgentCorruption: en kedja av brister i Amazon Bedrock AgentCore, AWS:s hanterade plattform för att distribuera och köra AI-agenter, som gjorde att en enda prompt i naturligt språk till en publikt tillgänglig agent kunde ta kontroll över varje AgentCore-agent i samma AWS-konto och region. Forskningen publicerades i samband med ett föredrag på SecTor 2026 i Toronto, där Zenitys säkerhetsforskningschef, Tamir Ishay Sharbat, presenterade den (Dark Reading, 8 oktober 2026). Zenitys egen redogörelse, som tillskrivs Sharbat, Lana Salameh, Dmitry Lozovoy och João Donato, inleds med mekanismen: en AgentCore-agent som har något verktyg som kan göra en utgående begäran kan styras till att anropa AWS Instance Metadata Service (IMDS) på den link-local-adressen 169.254.169.254, vilket returnerar tillfälliga autentiseringsuppgifter för agentens egen körningsroll. Zenity uppger att man exporterade dessa autentiseringsuppgifter till sin egen maskin och bekräftade att de fungerade därifrån. Ingen CVE-identifierare tilldelades.

Arkivet registrerar detta som en sårbarhet — något som hittats, inte nödvändigtvis utnyttjat — med hög allvarlighetsgrad, konfidens A, ingen registrerad verklig skada och bekräftad AI-medverkan. Parterna är oeniga om inramningen även om de är överens om beteendet: AWS sade till Dark Reading att forskningen "felaktigt framställer förväntat och dokumenterat beteende som en sårbarhet."

Vad kedjan egentligen var

AgentCore paketerar varje agent som en container och kör den per session i en Firecracker MicroVM. Zenitys första inlägg i serien återskapar hela fotfästet med en begäran i klarspråk till en testagent byggd med Strands SDK, AWS:s ramverk för agenter med öppen källkod, som levereras med ett inbyggt HTTP-förfrågningsverktyg och ett shell-verktyg. MicroVM:en begränsade inte trafiken till metadatatjänsten, så begäran kom inifrån instansen och IMDS svarade på den. Forskarna gick igenom slutpunkterna efter det: IAM-rollnamnet, själva de tillfälliga STS-autentiseringsuppgifterna, användardata-slutpunkten — som returnerade konto-ID, fullständiga ARN, runtime-URL:en och agentens Amazon Elastic Container Registry (ECR) image-URI — och instanstaggar inklusive en mTLS-certifikatkedja, en privat nyckel och en försignerad URL till intern lagring. Zenity säger att samma resultat erhölls via shell-verktyget, eftersom isoleringsfelet ligger på plattformsnivå snarare än i något enskilt verktyg.

Två detaljer i den sekvensen är lätta att förbise. Autentiseringsuppgifterna var inte begränsade till sandlådan: Zenity exporterade dem utanför AgentCore och gjorde ett AWS-identitetsanrop som svarade med agentens antagna roll. Och den stulna rollen kunde hämta containeravbildningen, vilket är hur agenternas källkod blev läsbar — Zenitys inlägg påpekar att avbildningar rutinmässigt innehåller hårdkodade nycklar, kvarlämnade tokens och konfiguration som aldrig borde ha bakats in, och att en hämtad avbildning är en karta över den underliggande affärslogiken.

Standardrollen är där ett fotfäste blev ett konto

Den andra bristen, som rapporterades separat, är att den exekveringsroll som AgentCore som standard kopplade till agenter inte var begränsad till en enda agent. Zenity beskriver behörigheter som sträcker sig över varje AgentCore-resurs i kontot och regionen, inklusive bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, bedrock-agentcore:CreateEvent, bedrock-agentcore:DeleteEvent och, vid slutet av kedjan för autentiseringsuppgifter, bedrock-agentcore:GetResourceApiKey och secretsmanager:GetSecretValue.

Uppräkningsbarhet förvandlade de där jokertecknen till en mållista. Zenity använde rollens logs:DescribeLogGroups-behörigheten, eftersom AgentCore namnger varje agents CloudWatch-loggrupp /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME}, och härledde agent-ID:n från dessa logggruppsnamn. ECR-repositorienamn följde en konvention som forskarna observerade — bedrock-agentcore-<agent_name> — så att varje agents image i regionen kunde hämtas. Minnesresurser hittades på samma sätt, från logggruppsmönstret /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}, och rollens ListActors-, ListSessions- och ListEvents-behörigheter gav de aktörs- och sessionsidentifierare som behövdes för att läsa konversationsinnehållet.

Zenitys genomgång ger en konkret demonstration av lateral förflyttning: att ta sig in via en publikt exponerad agent, upptäcka verktygen hos en b_agent i samma region, hitta en fil med namnet billing och exfiltrera den via ett filläsningsverktyg. Pressmeddelandet beskriver samma scenario i allmänna ordalag – en angripare som tar sig in via en internetexponerad kundtjänstagent skulle kunna förflytta sig till en intern finansagent som är utplacerad i samma region, anropa den och nå dess data, verktyg, relaterade och privata konversationer.

Minnet var den del som överlevde prompten.

AgentCore Memory behåller själva konversationen som korttidsminne och lagrar extraherade poster som långtidsminne, med hjälp av strategier som heter SEMANTIC, USER_PREFERENCE, SUMMARIZATION och EPISODIC. Zenity använde CreateEvent för att skriva konversationshändelser till andra agenters minnesresurser. Dess inlägg är noga med vad den primitiva operationen kan och inte kan göra: CreateEvent låter inte anroparen välja en långtidsnamnrymd eller skriva över en post direkt — målminnets konfigurerade strategier avgör vad som extraheras och var det hamnar. Zenity beskriver också hur DeleteEvent används för att ta bort verktygsresultathändelser så att en agent drar en felaktig slutsats från saknade data, och för att täcka sina spår genom att ta bort händelsen som planterade ett minne.

Det som skrivningen åstadkom var persistens. Zenitys demonstration planterade ett minne som fick agenten att hämta en sida som forskarna kontrollerade innan agenten svarade och att följa sidans innehåll – en kommando- och kontrollslutpunkt vars instruktioner kunde ändras genom att plantera ett annat minne. Samma kanal förde sedan ut konversationsinnehåll: rapporten beskriver att agenten skickade användarens meddelanden och sina egna svar till en insamlingsslutpunkt, och anger att minnesbehörigheterna för rollen sträckte sig över kontot och regionen i stället för bara till den komprometterade agenten. En video som publicerats tillsammans med forskningen visar en användare som fortsätter en konversation medan innehållet anländer till forskarnas server.

Autentiseringsuppgifter utöver AWS

Det sista inlägget i serien sluter cirkeln kring anslutna verktyg. AgentCore Identity och Outbound Auth lagrar verktygsuppgifter som hemligheter i AWS Secrets Manager, under namn som byggs upp av ett leverantörsnamn och ett fast mönster som bedrock-agentcore-identity!default/apikey/{provider_name}. Zenity återfann leverantörsnamn genom att skrapa den agentkällkod som det redan hade hämtat från ECR, och återfann andra genom råstyrka: det rapporterar att det standardmässiga suffixet på fem tecken genereras på klientsidan utifrån siffror och gemena bokstäver, vilket ger 2 x (10+26)^5 = 120 932 352 kombinationer för de två leverantörstyperna. Vid den anropsfrekvens som det kunde hålla mot Secrets Manager uppger Zenity att en fullständig uppräkning tar flera timmar – längre än STS-uppgifterna varar – så det byggde en slinga som på nytt frågade agentens IMDS-endpoint efter färska uppgifter i takt med att de gamla löpte ut. Zenity tillägger att miljövariabler gick att läsa via metadata-endpointen för användardata, där varje namn hade prefixet CONTAINER_ENV_, inklusive den nyckel som en agent använder för att autentisera sig mot sin modellleverantör, och att anrop av varje upptäckt agent med en lämplig prompt skördade dessa värden i stor skala.

Fastställt, och ifrågasatt på en teknikalitet

Det som är fastställt är snävt och specifikt. AgentCore-agenter kunde nå IMDS och ta emot sina egna exekveringsrollers tillfälliga autentiseringsuppgifter — AWS bestrider inte detta och beskriver det i sitt uttalande som "dokumenterat och förväntat". Den förvalda exekveringsrollen hade behörigheter som var begränsade till kontot och regionen snarare än till en enskild agent; AWS har sedan dess ändrat den, och Zenity säger att deras egen testning bekräftade minskningen. Forskningen är en demonstration, inte en observerad kampanj: Sharbat sade till Dark Reading att Zenity inte hade sett några bevis på att sårbarheten utnyttjades i det vilda före rättningen, och tillskrev det delvis svårigheten att identifiera vilka organisationer som kör agenter på AgentCore, och tillade att han var "100 % säker på att det finns sätt att göra det."

Det som är omtvistat är huruvida något av detta bör kallas en sårbarhet. AWS:s uttalande, i den form det gavs till Dark Reading och The Next Web, lyder: "AWS känner till forskningen som publicerats om Amazon Bedrock AgentCore, vilken felaktigt framställer förväntat och dokumenterat beteende som en sårbarhet. En agent kan endast komma åt resurser i ett annat AWS-konto om utvecklaren uttryckligen beviljar behörigheter för både agentens exekvering och målresursen." Det AWS-uttalande som återges i Zenitys rapport behåller kärnan i det första – "beteendet som beskrivs är dokumenterat och förväntat" – och tillägger att kunder endast bör ge exekveringsroller de behörigheter som deras agenter behöver. Två saker ligger bakom meningsskiljaktigheten. AWS ramar in gränsen i termer av åtkomst till resurser i ett annat AWS-konto, medan Zenitys fynd gäller agenter inom ett enda AWS-konto och en enda region; rollerna som Zenity beskriver kom från plattformens standardinställningar snarare än från att en kund skrev en policy för hand.

The Next Webs rättelse av sin egen artikel är värd att notera, eftersom den visar att påståendet skärptes av någon annan än forskarna. Den rapporterade först, och rättade senare, en rubrik som sa att forskarna tog över varje AgentCore-agent i en region; den rättade versionen anger att forskningen omfattade agenter inom ett enda AWS-konto och en enda region, och noterar att den tidigare rubriken hade framställt forskarnas påstående som ett faktum.

Tidslinjen för avslöjandet

Zenity lämnade in två rapporter i stället för en, och de besvarades olika. Rapporten om IMDS-åtkomst lämnades in den 25 december 2025; AWS stängde den den 12 april 2026 som "informativ" och skrev att AgentCore endast hade använt IMDSv2 sedan 14 februari 2026, och att nyligen driftsatta agenter startade på det sättet. Den revideringen har betydelse för detaljerna i den här forskningen, eftersom IMDSv2 kräver en sessionstoken vid varje begäran och omintetgör den enkla oautentiserade hämtning som forskarna använde för att komma åt autentiseringsuppgifter. Den andra rapporten, om standardrollen och dess skadeomfång, lämnades in den 12 januari 2026. AWS meddelade Zenity den 25 februari 2026 att teamet arbetade med saken medan rollen förblev oförändrad; Zenity granskade rollen igen den 22 juni 2026 och fann att dess behörigheter var oförändrade. En slutlig granskning den 29 september 2026 visade att rollen hade begränsats betydligt, och i Zenitys pressmeddelande anges att borttagningen omfattade att anropa andra agenter, läsa privata konversationer och komma åt hemligheter i AWS Secrets Manager, samt att övriga behörigheter också begränsades avsevärt. I Zenitys egna inlägg noteras att AWS sedan dess har gjort IMDSv2 till standard för AgentCore-distributioner och att parterna samarbetade genom hela processen.

Vad som inte är känt

Zenity har inte publicerat hur många agenter eller organisationer som körde med standardrollen under perioden mellan IMDSv2-ändringen i februari och begränsningen i slutet av september, och inget i de citerade källorna anger att några kunddata exponerades utanför forskarnas egen miljö. IMDSv2-ändringen gäller agenter som distribuerats efter den 14 februari 2026, enligt AWS såsom rapporterat av Zenity; vad den innebär för agenter som distribuerats före det datumet anges inte i de källor som granskats här. Arkivet registrerar ingen verklig skada, och källorna stöder den tolkningen genom att beskriva en demonstration och genom att AWS bestrider sårbarhetsbeteckningen i stället för att rapportera en egen incident.

Sharbat berättade för Dark Reading att Zenity nu undersöker andra molnplattformar för liknande problem med metadataåtkomst, och att företaget ännu inte namnger dem. Hans uttalade slutsats handlar om behörigheter snarare än om metadatatjänsten i sig: "Även om någon kommer åt IMDS kommer skadeomfånget att vara mycket mindre."

Varför denna post sparas

AgentCorruption är inte anmärkningsvärt för att metadata-slutpunkter skulle vara en ny idé. Sharbat riktade SecTor-publikens uppmärksamhet mot Capital One-intrånget 2019, där en SSRF nådde IMDS och resulterade i stulna autentiseringsuppgifter, och beskrev det som ett misslyckande med minsta behörighet av samma slag. Det nya är aktören som utför hämtningen. Begäran som skapade en AWS-identitet gjordes av en AI-agent som gjorde det den blev ombedd att göra, i klarspråk, genom ett verktyg den hade fått för att kunna vara användbar – och agenten förmedlade svaret tillbaka. De två förutsättningarna som gjorde det till ett problem för hela kontot var en metadata-slutpunkt som sandlådan inte blockerade och en standardroll som var bredare än agenten som innehade den.

Den fullständiga forskningen, inklusive den femdelade tekniska serien och demonstrationsvideon, länkas från Zenitys pressmeddelande den 8 oktober 2026. Den här posten är en av de dokumenterade agentincidenterna i AI-incidentarkivet, där varje post har sina egna källor, allvarlighetsgrad, tillförlitlighetsgrad och markering för omstridd status — fälten som gör det möjligt att skilja en leverantörstvist om inramning, som här, från ett omstritt konstaterande av skada.

Detta är en post, undersökt och rapporterad av andra och här citerad med hänvisning till dem. De andra dokumenterade agentincidenterna, var och en med sina egna källor, allvarlighetsgrad, konfidensgrad och omstridd flagga, finns i AI-incidentarkivet — så en plattformsstandard som gör en prompt till ett kontoomfattande fotfäste kan läsas vid sidan av vad som faktiskt har hänt någon annanstans.