Credentials came from inside the runtime
On 8 October, Zenity Labs published AgentCorruption, a set of technical write-ups describing a chain of weaknesses in Amazon Bedrock AgentCore.[1] In its test, a prompt to a public-facing agent led a network-capable tool to request the runtime's local metadata service.[2] The agent returned temporary credentials for its AWS execution role, which Zenity says the researchers then used through AWS APIs from outside the agent.[2][3] The disclosure documents a lab demonstration; it does not establish a customer breach.[1][2]
The distinction matters. AgentCore did not have to surrender control of the underlying cloud host for the chain to continue. The credential request reached the identity assigned to that workload; what that identity could do next depended on its permissions.[2][3]
The role made the incident cross-agent
Zenity's follow-up reports say the execution role used in its test had permissions extending beyond the first runtime. Researchers describe enumerating other agents through their log groups, retrieving container images, invoking other agents, reading conversation records, writing memories and reaching secrets in AWS Secrets Manager.[3][4][5] They place that activity within the same AWS account and region.[3][4][5] These are claims about the configuration they tested, not a finding that every AgentCore deployment had the same policy.[3][4][5]
The published sequence does not describe a microVM escape.[2][3] The published chain uses credentials for the agent's own execution role, then makes ordinary AWS API requests under that identity.[2][3] The first weakness exposed the role; the role's breadth supplied the reach. Prompt handling was the entry point, while IAM scope set the potential blast radius.
AWS defines the credential boundary
AWS's current AgentCore documentation says the MicroVM Metadata Service provides execution-role credentials to code in the VM.[6] It warns that any code or actor running there can call the metadata endpoint, and tells customers to limit the role to the actions and resources the agent needs.[6][7][8] AWS also says MMDSv2 must be enabled for AgentCore runtimes; the requirement took effect on 30 June 2026.[6][7]
The chronology points to two distinct changes. Zenity says AWS moved new deployments to IMDSv2-only behavior from 14 February.[1][2] The researchers reported the broad-role issue separately, say the default role remained unchanged when they checked on 22 June, and report that a 29 September review found broad cross-agent, conversation and Secrets Manager permissions removed or restricted.[1][3][5] Those final role changes are Zenity's observation; the article does not include an AWS policy diff.
AWS's stated position is also part of the record. In the disclosure, the company called access to an agent's own execution-role credentials documented and expected, and said cross-account access requires explicit permissions on both the role and target resource.[1] After publication, The Register reported that Amazon said Zenity's research misrepresented documented behavior as a vulnerability and suggested developer error was needed; the outlet said it asked Amazon for clarification.[9] The disagreement is over where the security boundary should sit, not whether credentials are available inside the runtime.
The evidence stops at Zenity's test
Zenity's write-ups document a staged test and the permissions it observed.[1][2][3][4][5] They do not establish that an attacker compromised a customer deployment, that every agent was reachable, or that every customer had the same default role and tool configuration. The reported reach across agents is bounded to the tested account and region and depended on permissions that Zenity says AWS later changed.
There is a small date inconsistency in Zenity's own record: its overview timeline lists 25 December 2025 for the first report, while a sentence in the technical post says 17 December.[1][2] The broader sequence is clearer: Zenity dates its separate role-scope report to 12 January 2026, says AWS described IMDSv2 changes in April, and says the role was still broad in June.[1][2][3] This account uses the dated timeline for the first report and does not treat the discrepancy as resolved.
Audit the identity, not just the prompt
Teams running AgentCore should inspect the execution role attached to each existing runtime, not assume that a safer new default changed an older deployment. Confirm MMDSv2 is enabled, then restrict each role to the actions and specific resources its agent needs. In particular, check whether a public-facing agent can invoke unrelated runtimes, read their sessions or memories, or access secrets outside its job. AWS's own guidance warns against wildcard resource policies and says credentials inside the microVM are reachable by code running there.[6][7][8]
The practical test is simple: if an agent follows a hostile instruction, what can its assigned identity do without asking the model for another decision? The answer should be bounded by IAM and service-side authorization, not by an expectation that prompt handling will contain the damage.[3][6][8]