Eén prompt, één agent, een heel AWS-account: een blik in AgentCorruption op Amazon Bedrock AgentCore

Op 8 oktober 2026 Zenity Labsonthulde AgentCorruption: een keten van kwetsbaarheden in Amazon Bedrock AgentCore, het beheerde platform van AWS voor het uitrollen en draaien van AI-agenten, waardoor één enkele prompt in natuurlijke taal aan één publiek toegankelijke agent de controle kon krijgen over elke AgentCore-agent in dezelfde AWS-account en -regio. Het onderzoek werd gepubliceerd samen met een lezing op SecTor 2026 in Toronto, waar de directeur securityonderzoek van Zenity, Tamir Ishay Sharbat, het presenteerde (Dark Reading, 8 oktober 2026). Zenity's eigen verslag, toegeschreven aan Sharbat, Lana Salameh, Dmitry Lozovoy en João Donato, begint met het mechanisme: een AgentCore-agent die over een hulpmiddel beschikt dat een uitgaand verzoek kan doen, kan ertoe worden gebracht de AWS Instance Metadata Service (IMDS) aan te roepen op het link-local adres 169.254.169.254, dat tijdelijke inloggegevens retourneert voor de eigen uitvoeringsrol van de agent. Zenity verklaart dat het die inloggegevens naar zijn eigen machine heeft geëxporteerd en heeft bevestigd dat ze daar werkten. Er werd geen CVE-identificatie toegewezen.

Het archief registreert dit als een kwetsbaarheid — iets dat is gevonden, niet noodzakelijkerwijs misbruikt — met hoge ernst, betrouwbaarheid A, geen geregistreerde echte schade en bevestigde AI-betrokkenheid. De partijen zijn het oneens over de framing, ook al zijn ze het eens over het gedrag: AWS zei tegen Dark Reading dat het onderzoek "verwacht en gedocumenteerd gedrag onterecht als een kwetsbaarheid afschildert."

Wat de keten eigenlijk was

AgentCore verpakt elke agent als een container en draait deze in een per-sessie Firecracker MicroVM. Zenity's eerste bericht in de serie reproduceert het volledige foothold met een verzoek in gewone taal aan een testagent die is gebouwd met Strands SDK, het opensource-agentframework van AWS, dat een ingebouwde HTTP-verzoektool en een shell-tool meelevert. De microVM beperkte het verkeer naar de metadataservice niet, dus het verzoek kwam van binnen de instantie en IMDS beantwoordde het. De onderzoekers liepen daarna de endpoints af: de IAM-rolnaam, de tijdelijke STS-referenties zelf, het user-data-endpoint — dat het account-ID, volledige ARN's, de runtime-URL en de Amazon Elastic Container Registry (ECR) image-URI van de agent retourneerde — en instantietags, waaronder een mTLS-certificaatketen, een privésleutel en een presigned URL naar interne opslag. Zenity zegt dat hetzelfde resultaat via de shell-tool werd verkregen, omdat de isolatiefout op platformniveau zit en niet in één specifieke tool.

Twee details in die reeks zijn gemakkelijk om overheen te lezen. De inloggegevens bleven niet beperkt tot de sandbox: Zenity exporteerde ze buiten AgentCore en deed een AWS-identiteitsaanroep die terugkwam als de aangenomen rol van de agent. En de gestolen rol kon de containerimage ophalen, waardoor de broncode van de agents leesbaar werd — in Zenity's bericht staat dat images steevast hardgecodeerde sleutels, achtergebleven tokens en configuratie bevatten die er nooit in gebakken hadden mogen worden, en dat een opgehaalde image een kaart is van de onderliggende bedrijfslogica.

De standaardrol is waar een voet aan de grond een account werd

De tweede fout, afzonderlijk gemeld, is dat de uitvoeringsrol die AgentCore standaard aan agents koppelde, niet was beperkt tot één agent. Zenity beschrijft machtigingen die zich uitstrekken over elke AgentCore-resource in het account en de regio, waaronder bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, bedrock-agentcore:CreateEvent, bedrock-agentcore:DeleteEvent en, aan het einde van de keten wat betreft inloggegevens, bedrock-agentcore:GetResourceApiKey en secretsmanager:GetSecretValue.

Enumereerbaarheid veranderde die wildcards in een doellijst. Zenity gebruikte de aan de rol toegekende logs:DescribeLogGroups-permissie, want AgentCore noemt de CloudWatch-loggroep van elke agent /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME}, en uit die loggroepnamen leidde Zenity agent-ID's af. ECR-repositorynamen volgden een conventie die de onderzoekers observeerden — bedrock-agentcore-<agent_name> — zodat de image van elke agent in de regio kon worden opgehaald. Memory-resources werden op dezelfde manier gevonden, via het patroon van de loggroep /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}, en de aan de rol toegekende ListActors-, ListSessions- en ListEvents-permissies leverden de actor- en sessie-identificaties op die nodig waren om gespreksinhoud te lezen.

Zenity's artikel geeft een concrete demonstratie van laterale beweging: binnenkomen via een publiek toegankelijke agent, het ontdekken van de tools van een billing_agent in dezelfde regio, en het opmerken van een bestand met de naam billing.json en het exfiltreren ervan via een bestandslees-tool. Het persbericht beschrijft hetzelfde scenario in algemene bewoordingen — een aanvaller die binnenkomt via een internetgerichte klantenservice-agent zou zich kunnen verplaatsen naar een interne finance-agent die in dezelfde regio is geïmplementeerd, deze aanroepen en toegang krijgen tot de gegevens, tools, gerelateerde inloggegevens en privégesprekken.

Geheugen was het deel dat de prompt overleefde

AgentCore Memory houdt het gesprek zelf bij als kortetermijngeheugen en slaat geëxtraheerde records op als langetermijngeheugen, met behulp van strategieën genaamd SEMANTIC, USER_PREFERENCE, SUMMARIZATION en EPISODIC. Zenity gebruikte CreateEvent om gespreksgebeurtenissen naar de geheugenbronnen van andere agents te schrijven. In zijn post wordt zorgvuldig beschreven wat die primitieve functie wel en niet kan: CreateEvent stelt de aanroeper niet in staat om een langetermijnnaamruimte te kiezen of een record rechtstreeks te overschrijven — de geconfigureerde strategieën van het doelgeheugen bepalen wat er wordt geëxtraheerd en waar het terechtkomt. Zenity beschrijft ook dat DeleteEvent wordt gebruikt om gebeurtenissen met tool-resultaten te verwijderen, zodat een agent een verkeerde conclusie trekt uit ontbrekende gegevens, en om sporen uit te wissen door de gebeurtenis te verwijderen die een herinnering heeft geplant.

Wat de schrijfprimitieve opleverde, was persistentie. De demonstratie van Zenity injecteerde een verzoek dat de agent, voordat hij antwoordde, een pagina ophaalde die door de onderzoekers werd beheerd en de inhoud van die pagina opvolgde — een command-and-control-endpoint waarvan de instructies konden worden gewijzigd zonder een nieuw geheugen te planten. Via hetzelfde kanaal werd vervolgens gespreksinhoud naar buiten gebracht: het verslag beschrijft dat de agent de berichten van de gebruiker en zijn eigen antwoorden naar een verzamelendpoint stuurde, en stelt dat de geheugenmachtigingen voor de rol zich uitstrekten over het account en de regio, en niet alleen tot de gecompromitteerde agent. Een video die samen met het onderzoek is gepubliceerd, toont een gebruiker die een gesprek voortzet terwijl die inhoud bij de server van de onderzoekers aankomt.

Inloggegevens buiten AWS

De laatste post in de serie sluit de cirkel rond verbonden tools. AgentCore Identity en Outbound Auth slaan toolreferenties op als secrets in AWS Secrets Manager, onder namen die zijn opgebouwd uit een providernaam en een vast patroon zoals bedrock-agentcore-identity!default/apikey/{provider_name}. Zenity achterhaalde providernamen door de broncode van de agent te scrapen die het al uit ECR had gehaald, en achterhaalde andere namen via brute force: het meldt dat het standaard achtervoegsel van vijf tekens client-side wordt gegenereerd uit cijfers en kleine letters, wat 2 x (10+26)^5 = 120,932,352 combinaties oplevert over de twee providertypen. Bij de verzoekfrequentie die het tegenover Secrets Manager kon volhouden, zegt Zenity dat een volledige enumeratie enkele uren duurt — langer dan de STS-referenties meegaan — dus bouwde het een lus die opnieuw query's uitvoerde op het IMDS-eindpunt van de agent voor nieuwe referenties zodra de oude verliepen. Zenity voegt eraan toe dat omgevingsvariabelen leesbaar waren via het metadata-user-data-eindpunt, waarbij elke naam het voorvoegsel CONTAINER_ENV_ had, inclusief de sleutel die een agent gebruikt om zich te authenticeren bij zijn modelprovider, en dat het aanroepen van elke ontdekte agent met een geschikte prompt die waarden op grote schaal oogstte.

Vastgesteld, en betwist op een technisch detail

Wat vaststaat, is beperkt en specifiek. AgentCore-agenten konden IMDS bereiken en hun eigen tijdelijke inloggegevens van de uitvoeringsrol ontvangen — AWS betwist dit niet en omschrijft het in zijn verklaring als 'gedocumenteerd en verwacht'. De standaarduitvoeringsrol had machtigingen die waren beperkt tot het account en de regio in plaats van tot één agent; AWS heeft dit sindsdien gewijzigd, en Zenity zegt dat zijn eigen tests de inperking hebben bevestigd. Het onderzoek is een demonstratie, geen waargenomen campagne: Sharbat vertelde Dark Reading dat Zenity geen bewijs had gezien dat de kwetsbaarheid vóór de oplossing in het wild was misbruikt, wat hij deels toeschreef aan de moeilijkheid om te achterhalen welke organisaties agents op AgentCore draaien, en hij voegde eraan toe dat hij '100% zeker' was dat er manieren zijn om het te doen.

Betwist wordt of iets ervan een kwetsbaarheid genoemd zou moeten worden. De verklaring van AWS, zoals verstrekt aan Dark Reading en The Next Web, luidt: "AWS is op de hoogte van het gepubliceerde onderzoek naar Amazon Bedrock AgentCore, dat verwacht en gedocumenteerd gedrag onterecht als een kwetsbaarheid afschildert. Een agent kan alleen toegang krijgen tot resources in een andere AWS-account als de ontwikkelaar expliciet machtigingen verleent voor zowel de uitvoeringsrol van de agent als de doelresource." De AWS-verklaring die in Zenity's eigen berichten wordt weergegeven, behoudt de kern van de eerste zin — "het beschreven gedrag is gedocumenteerd en verwacht" — en voegt eraan toe dat klanten uitvoeringsrollen alleen de machtigingen mogen toekennen die hun agents nodig hebben. Twee dingen liggen ten grondslag aan het meningsverschil. AWS kadert de grens in termen van toegang tot resources in een andere AWS-account, terwijl de bevinding van Zenity agents binnen één enkele AWS-account en -regio betreft; en de rollen die Zenity beschrijft, kwamen uit de standaardinstellingen van het platform in plaats van dat een klant met de hand een beleid schreef.

De correctie van The Next Web op zijn eigen verhaal is het vermelden waard, omdat ze laat zien dat de bewering door iemand anders dan de onderzoekers wordt aangescherpt. The Next Web bracht eerst een kop uit met de bewering dat de onderzoekers elke AgentCore-agent in een regio hadden overgenomen, en corrigeerde die later; de gecorrigeerde versie stelt dat het onderzoek agents binnen één AWS-account en -regio betrof, en merkt op dat de eerdere kop de bewering van de onderzoekers als feit had gepresenteerd.

De openbaarmakingstijdlijn

Zenity diende twee rapporten in in plaats van één, en ze werden verschillend beantwoord. Het IMDS-toegangsrapport werd ingediend op 25 december 2025; AWS sloot het op 12 april 2026 af als "informatief", met de opmerking dat AgentCore IMDSv2 pas sinds 14 februari 2026 gebruikte, waarbij nieuw geïmplementeerde agents op die manier werden gestart. Die herziening is van belang voor de specifieke details van dit onderzoek, omdat IMDSv2 bij elk verzoek een sessietoken vereist en de gewone niet-geauthenticeerde fetch doorbreekt die de onderzoekers gebruikten om inloggegevens te verkrijgen. Het tweede rapport, over de standaardrol en de omvang van de impact ervan, werd ingediend op 12 januari 2026. AWS vertelde Zenity op 25 februari 2026 dat het team eraan werkte terwijl de rol bleef zoals die was; Zenity bekeek de rol opnieuw op 22 juni 2026 en constateerde dat de machtigingen ongewijzigd waren. Een laatste beoordeling op 29 september 2026 stelde vast dat de rol aanzienlijk was ingeperkt, en in Zenity's persbericht staat dat de verwijdering betrekking had op het aanroepen van andere agents, het lezen van privégesprekken en het benaderen van geheimen in AWS Secrets Manager, waarbij ook andere machtigingen aanzienlijk werden beperkt. In Zenity's eigen berichten staat dat AWS sindsdien IMDSv2 de standaard heeft gemaakt voor AgentCore-implementaties en dat beide partijen gedurende het proces hebben samengewerkt.

Wat is niet bekend

Zenity heeft niet gepubliceerd hoeveel agents of organisaties met de standaardrol draaiden in de periode tussen de IMDSv2-wijziging van februari en de beperking van eind september, en niets in de aangehaalde bronnen stelt dat er klantgegevens buiten de eigen omgeving van de onderzoekers zijn blootgesteld. De IMDSv2-wijziging geldt voor agents die na 14 februari 2026 zijn uitgerold, volgens AWS zoals gerapporteerd door Zenity; wat dit betekent voor agents die vóór die datum zijn uitgerold, wordt niet vermeld in de hier onderzochte bronnen. Het archief vermeldt geen werkelijke schade, en de bronnen ondersteunen die lezing door een demonstratie te beschrijven en doordat AWS het label 'kwetsbaarheid' betwist in plaats van een eigen incident te melden.

Sharbat vertelde Dark Reading dat Zenity nu andere cloudplatforms onderzoekt op vergelijkbare problemen met metadatatoegang, en dat het bedrijf ze nog niet bij naam noemt. Zijn belangrijkste conclusie gaat over machtigingen en niet alleen over de metadataservice: "Zelfs als iemand bij de IMDS komt, zal de impact een stuk kleiner zijn."

Waarom deze registratie wordt bewaard

AgentCorruption is niet noemenswaardig omdat metadata-eindpunten een nieuw idee zijn. Sharbat wees het SecTor-publiek op de inbreuk bij Capital One uit 2019, waarbij een SSRF IMDS bereikte en gestolen inloggegevens opleverde, en beschreef dat als een least-privilegefout van dezelfde soort. Wat nieuw is, is de actor die het ophalen doet. Het verzoek dat een AWS-identiteit opleverde, werd gedaan door een AI-agent die deed wat hem was gevraagd, in gewone taal, via een hulpmiddel dat hij had gekregen zodat hij nuttig kon zijn — en de agent gaf het antwoord terug door. De twee voorwaarden die dat tot een probleem voor het hele account maakten, waren een metadata-eindpunt dat de sandbox niet blokkeerde en een standaardrol die ruimer was dan de agent die hem bezat.

Het volledige onderzoek, inclusief de vijfdelige technische serie en de demonstratievideo, is te vinden via het persbericht van Zenity van 8 oktober 2026. Deze vermelding is één van de gedocumenteerde agentincidenten in het AI-incidentenarchief, waar elke vermelding zijn eigen bronnen, ernstgraad, betrouwbaarheidsgraad en betwistvlag bevat — de velden die het mogelijk maken om een leveranciersgeschil over framing, zoals hier, te onderscheiden van een betwiste vaststelling van schade.

Dit is één record, onderzocht en gerapporteerd door anderen en hier aan hen geciteerd. De andere gedocumenteerde agent-incidenten, elk met zijn eigen bronnen, ernst, betrouwbaarheidsgraad en betwiste markering, staan in het AI-incidentenarchief — dus een platformstandaard die van één prompt een accountbrede uitvalsbasis maakt, kan worden gelezen naast wat elders daadwerkelijk is gebeurd.