Executive Summary
A single prompt to one customer-facing agent can hand an attacker the credentials to every agent in the same AWS account and region. Zenity Labs published the chain on October 8 and named it AgentCorruption. It works because an AWS Bedrock AgentCore agent runs in a Firecracker MicroVM that does not block traffic to the instance metadata service. A tool that can fetch a URL can fetch its own temporary credentials. Chat access to one exposed agent is enough.
The damage came from the default permissions, not only the microVM. The role AWS attached to AgentCore workloads by default spanned every agent in the region. With those credentials the researchers listed every agent, pulled their container images, read private conversations, wrote long-term memories to hijack later runs, and read secrets. AWS narrowed the role on September 29. AWS calls the behavior documented and expected, not a vulnerability. Read both positions before you decide what your own agent roles allow.
Most teams treat agent risk as a model problem. Prompt injection gets framed as a content issue, a filter on the way in and the way out. Zenity Labs just showed the sharper risk sits one layer down, in what the agent’s cloud identity is allowed to touch.
An AWS Bedrock AgentCore agent is a program that runs tools. One common tool makes HTTP requests, which is how an agent reads a page or calls an API. The researchers asked an agent to fetch a URL. The agent complied, and the URL pointed at the instance metadata service, the local endpoint at 169.254.169.254 that hands a workload its temporary cloud credentials. Because the request came from inside the instance, the metadata service answered it. That is the AgentCore vulnerability in one move.
The tool that fetches a URL is the vulnerability
AgentCore runs each agent inside a Firecracker MicroVM. The microVM was supposed to be the isolation boundary. It did not filter traffic to the metadata endpoint, so any agent tool capable of an HTTP request became a server-side request forgery primitive. No exploit code, no memory corruption, no account in the target environment. A prompt is the payload.
The metadata service returned the temporary credentials for the agent’s own execution role. The researchers moved them to their own machine and ran a standard identity call. It answered as the agent. From there they were not talking to the agent, they were acting as it through the ordinary AWS APIs.
The default role is where it got bad
Credentials are only as dangerous as the role behind them. The default role AgentCore attached to workloads was not scoped to a single agent. It covered every AgentCore resource in the region. It could invoke other agents, read their event logs, create memories, pull container images from the account registry, and read secrets from AWS Secrets Manager.
That turned one compromised agent into a region-wide foothold. The registry names matched the agent names, so the researchers pulled source code for every agent in seconds. The read permission on events exposed private conversations across users and agents. The create permission on memory let them write long-term memories that would steer future runs, a persistent hijack that survives the original fix. The secrets permission exposed the API keys agents use to reach systems outside AWS.
The disclosure ran long. Zenity Labs reported the metadata access on December 25, 2025. AWS closed that report as informative in April, noting the service moved to the token-based metadata service in February. The overprivileged role sat unchanged for months. On September 29, days before publication, the researchers found AWS had cut the region-wide permissions and hardened the default role.
What to check on your own agents this week
AWS disputes the finding. In a statement reported by The Register, the company said the behavior is documented and expected, that an agent can reach its own execution role through the metadata service, and that an agent reaches another account only when a developer grants permissions on both sides. It points customers to its own least-privilege guidance. The rebuttal is reasonable and it is also the point. A default is a decision you did not make, and this default was broad.
The fix AWS shipped is the fix you should verify on your own fleet. Scope each agent role to its own resources. Keep secrets out of the agent’s reach and route tool authentication through a gateway. Assume any agent with an HTTP tool can reach a link-local address, and block egress to the metadata endpoint at the network layer.
Ask three questions of your own environment. What does your agent execution role actually allow, read it rather than assume it. Can one agent’s credentials reach another agent, another user’s data, or a secret store. And if an attacker had those credentials tomorrow, what would the blast radius be.
Related reading. Our October 8 piece on the agent sandbox moving into the operating system covers the other end of this problem, where the boundary is drawn by the operating system rather than the cloud platform.
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.
[…] the full analysis of the AgentCore prompt injection chain, and what to check on your own agents this […]
[…] problem is the one our own coverage keeps finding in software supply and runtime layers, where one prompt was enough to walk out of an agent sandbox with credentials, and where thousands of GPU fleets still publish their own telemetry endpoints. AI infrastructure […]