Summary
- Researchers found access paths involving the AWS instance metadata service and temporary credentials.
- Permissions allowed cross-agent activity in the same account and region during testing.
- AWS made changes before the research was published; active customer compromise is not established.
Security researchers have documented a chain of weaknesses that could allow an attacker with access to a publicly exposed AI agent to reach other agents and sensitive cloud resources in the same AWS account, highlighting the importance of workload identities and permission boundaries.
Zenity Labs published the AgentCorruption investigation on 8 October 2026. It examines AWS Bedrock AgentCore, a managed platform used to deploy and operate AI agents, and describes a sequence involving prompt injection, instance metadata access and default execution permissions.
At the time of the researchers’ tests, an agent running inside a Firecracker microVM could be induced to make a request to an instance metadata service endpoint. The service made temporary AWS role credentials available to the workload. A prompt supplied through an exposed agent interface could cause the agent to invoke a tool that accessed the local metadata address.
The next stage depended on the permissions attached to that identity. Zenity says the default role initially permitted broad operations across AgentCore resources in an AWS account and region. Its testing included discovering and invoking other agents, accessing conversations and interacting with resources outside the original agent’s intended task.
The mechanism combines two distinct problems. Prompt injection attempts to redirect an agent’s behaviour through content it processes. A permission boundary failure determines how much damage that redirection can cause. The prompt itself does not confer AWS privileges; it becomes consequential when the agent already has access to a tool and credentials that can act beyond its intended scope.
Zenity disclosed its initial instance metadata findings to AWS in December 2025 and separately reported the permissions-related blast radius in January 2026. According to the researchers, AWS changed AgentCore’s instance metadata behaviour to require IMDSv2 for newly deployed agents in February, then revised default execution permissions more substantially by late September.
Zenity says its 29 September verification found that AWS had removed permissions enabling broad cross-agent invocation, private conversation access and Secrets Manager access, while restricting other privileges. That timing means the published October research describes findings disclosed and addressed over several months rather than proof that the same complete attack chain remained available on publication day.
AWS did not accept every part of the researchers’ framing as a platform vulnerability. The company’s characterisation of the architecture and remediation must be kept separate from Zenity’s demonstration. Nothing in the published report establishes that criminal attackers used this chain against real AWS customers.
The shared-cloud configuration examined in the research resembles the way organisations may deploy multiple agents. A single public-facing assistant may be intended to answer a narrow set of questions, but its workload credentials can still expose other applications if permissions are inherited too broadly.
Independent least-privilege reviews, isolation of agent tools and oversight of access to secrets and conversation histories can limit such blast radius. The research illustrates a remediated design risk, not an ongoing confirmed platform-wide breach, and its chronology is essential to judging present exposure.
The disclosure timeline helps explain why a demonstration of a serious earlier failure is not necessarily evidence of a current live exposure. Zenity says AWS changed metadata behaviour for newly deployed agents in February and narrowed default execution permissions by September. A system using custom roles may nonetheless have a different permission configuration from the defaults studied. Present-day exposure cannot be inferred from the original proof of concept without examining that deployment’s credentials and controls.
A security boundary around an agent is partly behavioural and partly infrastructural. The agent may be trained not to reveal secrets, but the cloud role attached to its tools determines whether it can reach them in the first place. Conversely, narrower cloud permissions limit what an incorrectly followed instruction can accomplish. Zenity’s analysis demonstrates the relationship between those mechanisms, while the report’s remediation chronology constrains any claim about continuing platform-wide vulnerability.
