The short answer
On AgentCore, the blast radius of one agent was the whole region. On October 8, 2026, Zenity Labs published AgentCorruption, a chain of weaknesses in Amazon Bedrock AgentCore. Researchers asked a public-facing agent with a web or shell tool to read the instance metadata service, received the temporary credentials of its execution role, and used them from their own machine. Because the default role covered the entire account and region, those credentials reached every other agent.
From there the researchers listed all agents, downloaded their container images and source code, invoked internal agents they were not authorized to use, read private conversations, pulled API keys and OAuth tokens from AWS Secrets Manager, and planted fake long-term memories that redirected future answers. No CVE was assigned.
How did one prompt take over every agent?
The entry point was ordinary agent functionality. Many AgentCore agents get a tool that can make web requests or run shell commands, because that is what makes them useful. According to Zenity’s write-up, the runtimes behind those agents did not block traffic to the metadata endpoint, so a plain-language request was enough to make the agent fetch the execution role’s temporary access key, secret key and session token.
The second weakness turned a single leaked credential into a fleet compromise. The default execution role was scoped to the whole account and region rather than to one agent. With it, the researchers could enumerate every agent, pull its code and images, call internal agents, read stored conversations and long-term memory, and query Secrets Manager. The final step was persistence: they wrote fake memory events so that agents would visit an attacker-controlled page before every answer. The Next Web and The Decoder both reported the chain on October 8, citing Zenity’s four-part technical series.
What did AWS change, and what did it say?
AWS did not treat the report as a vulnerability. In a statement quoted by The Next Web and The Decoder, it said an agent can access resources in another AWS account only if the developer explicitly grants permissions on both the execution role and the target resource, and it advised customers to give execution roles only the permissions their agents need. Zenity says AWS initially closed the metadata report as “informative”.
The defaults still moved. New agents have been deployed with IMDSv2 only since February 14, 2026, and during a final check on September 29, 2026 Zenity found that the default role had lost the permissions to invoke other agents, read private conversations and access Secrets Manager. The key point for customers: changing a default protects new deployments, not roles that already exist in your accounts.
What it means for US & EU software teams
First, an agent’s tools are an attack path to the cloud control plane. A web-fetch or shell tool on a public-facing agent is functionally the same risk as a server-side request forgery bug in a web app. Anyone who can chat with the agent can try to make it reach internal endpoints. Threat models for AI agents need to treat every prompt from an untrusted user as potentially hostile input, not as a conversation.
Second, “documented behavior” still leaves the risk with you. Under the shared responsibility model, AWS considers least-privilege roles the customer’s job. For SOC 2, ISO 27001 and NIS2 assessments, that means an agent with a region-wide role is your finding, not your provider’s. Teams that build production AI agents should design one role per agent, scoped to the exact resources it touches, and keep secrets outside the agent’s reach unless a specific tool needs them.
Third, agent memory is now part of your data-protection scope. Poisoned long-term memory survives restarts and can quietly redirect users. For EU teams, stored conversations often contain personal data under GDPR, and unauthorized reads would be a reportable breach. Memory stores need integrity checks, audit logs and retention rules, the same as any other database holding customer data.
What should AgentCore users check now?
- Inventory execution roles. List every AgentCore agent and the role it runs under. Flag any role shared by more than one agent and any role with wildcard resources across the account or region.
- Replace the old default role. Create a dedicated role per agent with only the actions and resource ARNs it needs. Remove permissions to invoke other agents, read other agents’ sessions and memory, and list or read secrets it does not use.
- Confirm IMDSv2 and block metadata access where possible. Check that older agents run with IMDSv2 only, and restrict tool egress so web and shell tools cannot reach link-local addresses such as 169.254.169.254.
- Review public-facing agents first. Agents reachable by customers or anonymous users carry the highest risk. Remove shell tools unless they are essential and constrain web tools to allowlisted domains.
- Audit memory and logs. Look for unexpected memory events, unusual agent-to-agent invocations and Secrets Manager reads from unfamiliar IP addresses in CloudTrail. Rotate any secret an over-privileged agent could read.
Frequently asked questions
What is AgentCorruption?
AgentCorruption is a chain of weaknesses in Amazon Bedrock AgentCore disclosed by Zenity Labs on October 8, 2026. A single prompt to one public-facing agent let researchers obtain its execution-role credentials from the instance metadata service and use them to control every AgentCore agent in the same AWS account and region.
Has AWS fixed the AgentCore issue?
AWS changed the defaults rather than issuing a patch. New agents have used IMDSv2 only since February 14, 2026, and by September 29, 2026 the default execution role no longer allowed invoking other agents, reading private conversations or accessing Secrets Manager. AWS describes the behavior as expected and documented, and no CVE was assigned.
Are agents created before the changes still at risk?
They can be. A new default protects new deployments, but existing roles keep the permissions they were created with. Teams should review every agent’s execution role and metadata settings rather than assume the update applied to them.
What could an attacker access?
In Zenity’s tests: other agents’ container images and source code, internal agents the attacker was not authorized to use, private conversations and long-term memories, and API keys, OAuth tokens and other secrets stored in AWS Secrets Manager. The researchers also planted fake memories to keep persistent control.
How do we reduce the risk for our AI agents?
Give each agent its own least-privilege execution role, block tool access to link-local metadata addresses, limit web and shell tools on public-facing agents, keep secrets out of reach unless a tool needs them, and monitor CloudTrail for unusual agent invocations and Secrets Manager reads.
Sources
Zenity — Zenity Labs discloses AgentCorruption, a chain of AWS AgentCore flaws
Zenity Labs — AgentCorruption: initial IMDS access
The Next Web — One prompt let researchers take over every AWS AgentCore agent in a region
The Decoder — A single prompt was enough to hijack every AI agent in an AWS account
Dark Reading — ‘AgentCorruption’ puts AWS environments at risk with a single prompt