Zenity Labs has published research, which it calls AgentCorruption, showing that a single prompt to an Amazon Bedrock AgentCore Runtime agent could make it fetch its own AWS credentials from the metadata service and send them to an attacker. The impact depended on the execution role, and the one Zenity tested reached across every agent in the account and region.
What happened
In the first post of a series, Zenity researchers Lana Salameh and Dmitry Lozovoy describe how AgentCore Runtime agents, each running in a Firecracker microVM, could reach a metadata endpoint at 169.254.169.254 similar to EC2's IMDS. Any agent with a tool that makes HTTP requests or runs shell commands could be told to query that endpoint and post the results to an external listener. Zenity calls this SSRF and a platform-level isolation failure, not a tool problem.
The response contained temporary STS credentials (access key ID, secret access key and session token) for the agent's execution role. They still worked when used from outside the sandbox. The tested role, named with an AmazonBedrockAgentCoreSDKRuntime-us-west-2- prefix in the write-up, included ecr:BatchGetImage and ecr:GetDownloadUrlForLayer on every ECR repository in the region, plus logs:DescribeLogGroups, which revealed every agent's ID and name. Zenity says the role allowed pulling other agents' container images (source code, hardcoded secrets), invoking other agents, reading private user conversations, and changing agent memory for persistence. The Next Web, reporting on the research, adds access to API keys in AWS Secrets Manager.
Timeline, per Zenity and The Next Web:
- December 25, 2025: Zenity reported the metadata access to AWS.
- January 12, 2026: Zenity reported the over-privileged default role (per The Next Web).
- February 14, 2026: AWS moved AgentCore to IMDSv2 only, with all newly deployed agents launching with IMDSv2.
- April 12, 2026: AWS closed the metadata report as "informative".
- September 29, 2026: Zenity found AWS had narrowed the default role, removing agent invocation, conversation reading and Secrets Manager access (per The Next Web).
No CVE was assigned. AWS's position is that this is expected behavior:
The behavior described is documented and expected. AgentCore agents can access the credentials for their own execution role through the metadata service. — AWS, via Zenity Labs
AWS told customers to grant execution roles only the permissions their agents need.
Why it matters
This is a workload identity problem. An agent's execution role is a non-human identity, and in this chain prompt injection gives an outside attacker that identity's credentials. With a broad role, one public-facing agent becomes the way into every agent in the region, including their code, their users' conversations and the secrets they hold.
AWS's answer puts the job on customers. If the agent can read its own credentials by design, the role is the only real boundary, and a role scoped to the region rather than the agent defeats the per-agent isolation the microVM is supposed to provide. The IMDSv2 change and the narrower default role cover new deployments. Neither source says whether existing agents' roles were changed, so assume older agents keep whatever they were given.
It is the opposite of the on-behalf-of pattern AWS itself described for identity-aware Lake Formation data agents, and it shows the cost of the standing agent access problem.
What to check in your environment
- Inventory AgentCore Runtime agents in every region and record each agent's execution role and when it was deployed. Agents launched before February 14, 2026 are the ones to look at first.
- Review execution role policies, especially roles created by AgentCore tooling (the tested role used the
AmazonBedrockAgentCoreSDKRuntime-name prefix). Look for wildcard ECR repository resources, account-wide log group discovery, permission to invoke other agents or read their memory and sessions, and Secrets Manager access. - Scope one role per agent. Limit ECR read to the agent's own repository and Secrets Manager to the secrets that agent needs.
- Confirm IMDSv2 for older agents. If you cannot verify it, redeploy them so they pick up the current platform behavior.
- Restrict outbound network access for agents that have HTTP or shell tools, and find out which public-facing agents have them.
- Remove hardcoded secrets from agent container images. Zenity showed images could be pulled, so treat any secret baked into one as exposed and rotate it.
- Hunt in CloudTrail for execution-role credentials used from IP addresses outside AWS, and for ECR image pulls or agent invocations that don't match the agent's normal behavior.