One prompt, every agent in the region: Zenity's AgentCore research, and why AWS disputes it

Zenity Labs published research on 8 October 2026 saying that, before AWS made changes, a single prompt to one exposed agent on Amazon Bedrock AgentCore could hand an attacker that agent's temporary AWS credentials, and through a broadly scoped default role, reach other AgentCore agents in the same account and region. AWS says the behaviour is "documented and expected". Zenity says the issues it reported have since been patched.

What Zenity says it found

AgentCore is AWS's managed platform for running AI agents. Each agent runs in a Firecracker microVM, which Zenity says did "not provide sufficient network isolation". So, it says, any agent tool that makes HTTP requests sent them from inside the instance, within reach of its metadata service.

• The entry point. Zenity's test agent was built with AWS's open-source Strands SDK, with its built-in http_request tool added by the builder. Asking that agent to fetch the metadata endpoint returned the temporary credentials for its IAM role. In Zenity's words: "All it took was a simple prompt injection."
• The blast radius. Zenity says the role attached to AgentCore workloads by default "wasn't scoped to the specific agent" and instead "included broad permissions across all AgentCore resources in the entire AWS account's region".
• What that allowed, per Zenity. Finding other agents, pulling their container images, invoking them, reading private conversations, planting long-term memories that would "persistently alter agent behaviour", and retrieving tool credentials kept in AgentCore Identity and AWS Secrets Manager.

The timeline, from Zenity's post

• December 2025: Zenity reports the metadata-service access to AWS (its post says it reported the findings on 17 December; its timeline lists 25 December).
• 12 January 2026: a second report, on the default role.
• 14 February 2026: according to AWS, as relayed by Zenity, AgentCore was updated to use IMDSv2 only, with all newly deployed agents launching with IMDSv2.
• 25 February 2026: AWS says the team is "actively working on addressing the underlying issue"; Zenity says the default role stayed the same.
• 12 April 2026: AWS closes the first report as "informative".
• 22 June 2026: Zenity says the default execution role's permissions "remain unchanged".
• 29 September 2026: Zenity observes "substantial changes": AWS had removed the permissions for wide agent execution, reading private conversations and accessing Secrets Manager across a region.

AWS's position

AWS's statement, published in full in Zenity's post, says: "The behavior described is documented and expected. AgentCore agents can access the credentials for their own execution role through the metadata service." It adds: "As a best practice, we recommend that customers grant their execution roles only the permissions their agents need." It also says an agent can reach resources in another AWS account "only if the developer explicitly grants permissions on both the agent's execution role and the target resource". On our reading, Zenity's findings concern the same account and region, a different case.

The Register reported on 9 October that, following publication, Amazon wrote in to say Zenity's research misrepresents documented behaviour as a vulnerability, suggesting developer error would be needed for the attack. The Register said it had asked for clarification, "since that's not the scenario Zenity has described."

AWS's AgentCore documentation, read on 12 October, warns about this. Its credentials page says "any code or actor running inside the VM can access these credentials by calling the metadata endpoint", and that with LLMs "that can generate arbitrary code, it's crucial to limit permissions to only what you intend." Of the nine bulletins AWS's security bulletins page lists as of 12 October, none is about this research; its only AgentCore item, dated 6 October, covers a separate issue in the deprecated AgentCore Starter Toolkit.

What builders should check

From AWS's AgentCore guidance unless labelled:

• Assume the execution role is exposed. AWS says any code in the microVM can get the role's credentials. On our reading, that includes anything the model can be talked into fetching.
• One narrow role per agent. AWS advises scoping permissions "to specific runtime ARNs" and to "Avoid wildcard resource statements".
• Don't ship the CLI's policies. AWS says the IAM policies its AgentCore CLI creates are "designed for development and testing purposes" and "not suitable for production environments".
• Keep the role no stronger than its callers. AWS recommends the execution role has "equal or fewer privileges than the principals who can invoke it".
• Check MMDSv2. AgentCore's microVM Metadata Service (MMDS) is, in AWS's words, "similar to how EC2 instances use the Instance Metadata Service (IMDS)". AWS says: "Starting June 30, 2026, your agent runtimes must have MMDSv2 enabled."
• Review older roles. On our reading, neither Zenity nor AWS says whether roles created before the September changes were altered, so check what yours grant; AWS recommends IAM Access Analyzer.
• Be deliberate with tools that reach the network. Zenity's test agent used an HTTP tool, but Zenity says removing it alone "doesn't help": "The isolation failure is at the platform level, not the tool level", and it says it reproduced the result through several tools, including Strands' built-in shell tool.

Why it matters

On our reading, AWS and Zenity agree an agent can read its own role's credentials. They differ on whether the broad permissions came with AgentCore by default, as Zenity says, or required developer error, as The Register reports Amazon suggested, and so on whether this amounted to a vulnerability. Either way, the role is the real security boundary for an agent, not the prompt. Zenity's conclusion is that "a single unexpected weakness in one agent could collapse the boundaries of an entire environment".