Category: AI Agent Security | Reading time: 4 min
What Happened
On 8 October 2026, Zenity Labs disclosed AgentCorruption, a chain of issues in Amazon Bedrock AgentCore, AWS's managed service for building and running AI agents. The research was presented at SecTor 2026 in Toronto.
Zenity says a single prompt sent to one public-facing AgentCore agent let its researchers take over every AgentCore agent in the same AWS account and region. From there they read private conversations and long-term memories, downloaded agent container images and source code, pulled API keys and OAuth tokens from AWS Secrets Manager and environment variables, and planted memories that redirected future conversations to an attacker-controlled destination.
AWS disputes the framing. "AWS is aware of the research published about Amazon Bedrock AgentCore, which inaccurately paints expected and documented behavior as a vulnerability," an AWS spokesperson told The Next Web, adding that an agent can reach resources in another AWS account only if the developer explicitly grants permissions on both sides, and recommending that customers grant execution roles only the permissions their agents need.
How the Chain Worked
According to Zenity's technical write-ups, the steps were ordinary cloud attack techniques applied through an agent:
- Metadata access. The target agent had a common built-in tool that can make outbound requests. The prompt told it to query the instance metadata endpoint, which returned temporary credentials for the agent's execution role, plus user-data exposing the account ID, ARNs, environment variables and the agent's container image reference. - An overbroad default role. Those credentials belonged to a default IAM execution role whose permissions, Zenity says, extended to all AgentCore agents in the account and region rather than the one agent it served. That let the researchers discover and invoke internal agents they were never meant to reach. - Secrets by wildcard. The default role included a `secretsmanager:GetSecretValue` permission scoped to AgentCore identity secrets with wildcard paths for OAuth and API key providers, which matched every provider in the region. By scraping agents' source code for provider names, the researchers mapped and retrieved the secret values, including credentials for services outside AWS. - Persistence through memory. Write access to agent memory let them plant instructions that kept working across future sessions. Users would keep talking to what looked like a trusted agent while it followed attacker instructions.
Zenity's example of the blast radius: an attacker entering through an internet-facing customer service agent could move to an internal finance agent in the same region, invoke it, and reach its data, tools and credentials.
The Disclosure Timeline
Zenity reported the metadata access issue to AWS on 25 December 2025 and the overprivileged default role on 12 January 2026. Zenity says AWS told it that, from 14 February 2026, newly deployed AgentCore agents launch with IMDSv2 only, and closed the first report as "informative" in April. AWS's AgentCore documentation now states that, starting 30 June 2026, AgentCore Runtime requires all agent runtimes to use MMDSv2.
On the role itself, Zenity says the default permissions were still unchanged when it checked on 22 June. During a final review on 29 September, it found AWS had removed the permissions that allowed agents to invoke other agents, read private conversations and access Secrets Manager, and had tightened others.
AWS's own credentials guidance already warns that any code or actor running inside the VM can obtain the execution role's credentials by calling the metadata endpoint, and that this matters most when an LLM can generate arbitrary code.
Why It Matters
The two sides are describing the same fact from different ends. AWS is right that the behavior was documented and that least privilege is the customer's job. Zenity is right that the default most teams start with was far broader than any one agent needed, and that an agent which follows instructions from the public will use whatever its role allows.
For regulated enterprises, the useful lesson is about where the boundary sits. A cloud role defines what a workload can reach. It does not decide, per agent and per action, whether a specific request from a specific session should be allowed. When an agent's identity is a shared role and its instructions can come from anyone who can chat with it, the cloud permission becomes the only control, and one prompt is enough to test it.
The Takeaway
Teams running agents on AgentCore should review execution roles created before AWS's late-September changes, confirm runtimes enforce MMDSv2, and check agent memory for planted instructions. More broadly, every agent needs its own scoped identity, and every action it takes on another system needs a decision and a record tied to that identity, so that a breach in one agent stays one agent's problem.
Source: Zenity press release, 8 October 2026 | Zenity Labs: How a single prompt collapsed the cloud security model | Zenity Labs: Initial IMDS access | Zenity Labs: Credential theft from Secrets Manager | The Next Web, with AWS statement | AWS: Credentials management in AgentCore | AWS: Troubleshoot AgentCore Runtime