security
Tokens transmitted in metadata, weak VM isolation, and expansive permissions make hacking a lot easier
Bob, possibly the same Bob whose conversations with Alice draw so much interest from eavesdropping Eve, was browsing a site we’ll call TechHub. The site hosts an AI agent served by Amazon Bedrock AgentCore. Bob asked the agent for help understanding the content of a URL, a credential endpoint – in raw JSON, if you don’t mind.
The endpoint returned data from the Instance Metadata Service (IMDS), which provides metadata about cloud instances and VMs at providers like AWS, Azure, and Google Cloud Platform. The metadata includes details like region and availability zone, subnets, system images, security groups, public keys injected during spawning, but also potentially more sensitive details like user data and security tokens.
IMDSv2 addresses some of these risks, but back when Bob was browsing late last year, Bedrock AgentCore still used IMDSv1.
The metadata provided to Bob by the helpful agent contained the agent’s temporary credentials. So Bob loaded them onto his local machine, and remotely enumerated the company’s other agents in that AWS region. He then logged into the Amazon Elastic Container Registry (ECR), pulled the agent container images, and ran each as root to inspect the source code.
The stolen credentials also allowed Bob to discover the memory resources available in that AWS region, including the ones used by agents. From these, he’s able to extract the users and their agent sessions – their conversations.
Researchers at Zenity Labs disclosed their findings to AWS in December 2025.
“We discovered that agents deployed through AgentCore could access their instance’s IMDS endpoints,” said Tamir Ishay Sharbat and Lana Salameh in a blog post. “This meant that an external attacker with nothing more than chat access to a single exposed agent could send a single prompt, extract its IMDS credentials, and use them to take over all AgentCore agents in the same AWS account and region.”
The basic problem, they explain, is that the Firecracker MicroVM used by AgentCore failed to provide sufficient network isolation. So an attacker – I know you’re thinking it was Mallory, but it was really Bob – could direct the agent to carry out a server-side request forgery (SSRF) attack by fetching temporary AWS credentials for the IAM role assigned to the workload.
And because the default AgentCore role was overpermissioned – it was scoped to all AgentCore resources in the region rather than a single agent – anyone in possession of the temporary IAM credentials could launch other agents, read sessions, write agent memories, and fetch secrets from AWS Secrets Manager.
“By leveraging the IMDS credentials we could send direct API requests to create new memories across different agents and users,” said Sharbat and Salameh. “These in turn would persistently alter agent behaviour and hijack the agents’ goals across future sessions.”
The Zenity researchers told Bob’s tale, or something like it, to AWS last December, then followed up in January 2026 with details about AgentCore being overprivileged. On April 12, 2026, AWS responded to the security biz that its report was “informative” and closed the report, noting that as of February 14, 2026, AgentCore had been updated to use IMDSv2 exclusively.
AgentCore’s excessive permissions remained in place at least until June 22, 2026, when Zenity checked in and found the issue hadn’t been remediated. A final review by Zenity occurred on September 29, 2026, at which point the biz observed that AWS had addressed the extant problems, clearing the way for Bob’s hypothetical adventure to finally be told.
Following publication, Amazon wrote in to say that Zenity’s research misrepresents documented behavior as a vulnerability, suggesting that developer error would be required to enable the attack. We’ve asked for clarification since that’s not the scenario Zenity has described. ®
