The Register reports that AWS AgentCore security can be undone by a prompt requesting credentials, with tokens transmitted in metadata, weak VM isolation and expansive permissions.

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 the agent didn'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 such as region and availability zone, subnets, system images, security groups, and public keys injected during spawning, but also potentially more sensitive information like user data and security tokens. IMDSv2 addresses some of these risks, but when Bob was browsing late last year, Bedrock AgentCore still used IMDSv1. The metadata the helpful agent provided to Bob contained the agent's temporary credentials.

Bob loaded those credentials 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 one as root to inspect the source code. The stolen credentials also allowed Bob to discover the memory resources available in that AWS region, including those used by agents. From these, he was able to extract the users and their agent sessions, meaning 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. As a result, 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. Because the default AgentCore role was overpermissioned, scoped to all AgentCore resources in the region rather than a single agent, anyone holding those 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 that the report was "informative" and closed it, 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 again and found the issue had not been remediated. A final review by Zenity on September 29, 2026, found that AWS had addressed the remaining 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 is not the scenario Zenity has described.