What the researchers did
Zenity Labs published the first part of a chain it calls AgentCorruption on 8 October. The target is Amazon Bedrock AgentCore Runtime, the managed service enterprises use to run AI agents on AWS.
The researchers deployed a sample agent built with Strands, AWS’s open-source agent SDK, using the SDK’s built-in http_request tool. They then prompted the agent to fetch the AWS instance metadata endpoint at 169.254.169.254 and relay the response to a listener they controlled. It did. They reproduced the same result through the SDK’s shell tool.
Zenity’s conclusion is about the platform rather than the tool: “The microVM did not restrict traffic to the metadata service”, and “The isolation failure is at the platform level, not the tool level”.
What the metadata gave up
The metadata service returned the agent’s execution role name and its temporary STS credentials. The researchers confirmed those credentials worked from outside AgentCore entirely, with aws sts get-caller-identity returning the agent’s assumed role.
From there the metadata kept giving. User-data revealed the agent’s container image URI in Elastic Container Registry. Instance tags exposed mTLS certificate and key material and a presigned S3 URL.
Why one agent reached all of them
The execution role is the part Zenity is hardest on: “The role AgentCore attaches to agent runtime by default is badly overprivileged”. It carried ECR read permissions with wildcards, and AgentCore names image repositories predictably, as bedrock-agentcore-<agent_name>.
That combination turned one compromised agent into a directory of every other agent in the same account and region. In the researchers’ words, “running our automated tool on all the discovered agents got us all source code of all agents in the region within a few seconds.” Zenity says subsequent posts will cover read, write and delete capabilities across AgentCore and other AWS services in the region.
What AWS changed, and what it says now
Zenity’s timeline is not internally consistent: the post’s text says the findings went to AWS on 17 December 2025, while its own timeline entry for the IMDS disclosure reads 25 December 2025. The dates after that are clearer. On 14 February 2026 AgentCore moved to IMDSv2 only, so newly deployed agents launch with it. On 12 April 2026 AWS responded and closed the report as “informative”. No CVE was assigned.
AWS’s position, given in a statement reported by The Decoder on 9 October, is that the research “inaccurately paints expected and documented behavior as a vulnerability”. AWS said an agent can reach another account’s resources only where a developer has explicitly granted permissions on both the execution role and the target resource, and it points developers to its own runtime permissions documentation and to least-privilege execution roles. The Decoder reports that AWS also narrowed the default execution role later, removing permissions to invoke other agents, read private conversations and retrieve Secrets Manager credentials.
The argument underneath
Both sides agree on the mechanics and disagree on whose job it was. AWS’s case is that a default role is a starting point and the documentation says to narrow it. Zenity’s case is that a managed agent runtime whose sandbox does not block the metadata service, and whose default role can enumerate its neighbours, is shipping a default that most customers will never change.
That is the same argument the cloud industry had about public S3 buckets, and it was settled by changing the default rather than the documentation.
What to watch
Zenity has said this is the first instalment. The later posts are the ones that matter: initial credential access is a serious finding, but the claim that drew attention is lateral movement across every agent in a region, and that part is still to be published in detail.
For anyone running agents on AgentCore today, the actionable item is not in dispute. Both the vendor and its critics say the same thing: do not ship on the default execution role.
