Amazon Bedrock AgentCore is AWS's managed platform for building, deploying, and running AI agents. Each agent is packaged as a container and runs on a serverless runtime inside its own Firecracker microVM, with built-in memory, tools, gateways, and identity to build on.That's a lot of moving parts behind a benign simple agent and this research is about how much of it we can reach.
AgentCorruption is a chain of flaws in AgentCore that let us turn a simple prompt to a single exposed agent into control over every agent in the same AWS account and region. It all starts with the find in this post: tricking an agent into handing over the credentials to its own cloud identity.
IMDS access through SSRF
Agents are useful because they can do things: executing code, invoking tools and of course reaching out over the network. A weather agent makes HTTP calls. A research agent browses the web. A DevOps agent runs shell commands. Any of these capabilities means the agent can be steered into making a request of the attacker's choice - this can become a server-side request forgery (SSRF) if the underlying infrastructure is not configured carefully. This was exactly the case here.
Let’s understand what happened.
AgentCore Runtime is a managed service that runs AI agents in an isolated environment. On each agent run, AgentCore starts a new ephemeral Filecracker microVM instance.
These instances are lightweight, hardened virtualization units created per session to ensure isolation of network and resources between tasks. To keep instance data, this architecture uses microVM Metadata Service (MMDS) - very similar to the typical EC2 Instance Metadata Service (IMDS).
IMDS sits at 169.254.169.254 and exposes different endpoints potentially holding sensitive data and internals of the same instance.This includes, most importantly, temporary credentials to authenticate the instance’s workload identity.This makes it the first place worth checking if you can run a successful SSRF attack on a cloud server. Reaching IMDS from a compromised workload is cloud hacking 101. It means stealing the workload identity and acting as if you were it - in this case the agent.
An instance hosting AI agent is exactly the kind of place you'd expect that path to be blocked. Or is it? Let's check.
So we deployed a simple agent using Strands SDK - an open source from AWS for building AI agents. It ships with many built-in tools, such as shell and http_request, out of the box. To enable built-in tools, the builder has to simply import and add it to the agent’s available tools list.
For example:
Then we asked it, in plain language, to fetch the metadata endpoint:
Simplified Prompt:
Response:
It worked. The microVM did not restrict traffic to the metadata service, and the agent happily relayed the response back to us. The sandbox boundary we were supposed to be fighting simply wasn't there.
Stealing the agent's identity
An open metadata endpoint is only as interesting as what it exposes, so we walked it. The prize was found under the IAM path.
First the role name:
Response:
Then the credentials themselves:
which returned a full set of temporary STS credentials: an access key ID, a secret access key, and a session token, belonging to the agent's execution role.
These credentials aren't scoped to the sandbox. We exported them onto our own machine, outside AgentCore entirely, and confirmed they were live:
The call came back as the agent's assumed role. At this point we were no longer talking to the agent, we were the agent, holding its AWS identity from our own terminal. Everything from here happens with the official AWS API, no further interaction with the agent required.
Walking the rest of the metadata surface
Stealing the execution role was the fastest win, but it was not the only thing the metadata service was willing to hand over. Using the same trivial `GET` requests, we walked the rest of the surface, and it kept giving.
User-data. The `/latest/user-data` endpoint returned the container's full configuration: the account ID, full ARNs, the runtime URL, and, most usefully, the reference to its own container image:
That is the full Elastic Container Registry (ECR) URI for the agent's image, handed over without authentication.
Instance tags. IMDS exposes the instance's tags at `/latest/meta-data/tags/instance`, and the list read less like agent configuration and more like the host's secrets drawer:
Each one is readable at `/latest/meta-data/tags/instance/<tag-name>`, and a few of them stood out immediately.
For example, `cert-chain-pem` and `private-key-prem` expose mTLS authentication credentials issued for AWS internal service that we could verify using OpenSSL modulus comparison.
`presigned-log-url` exposed a presigned url to an internal S3 that is not part of our AWS account.
Pulling the agent image
So far we’ve got the credentials, execution role and agent’s container image URI - Let's use them smartly.
In theory, a container image is a private build artifact. But for an attacker it’s one of the richest targets in a breach, because of how teams actually build them. Source code goes in by definition. But so, very often, do things that shouldn't: hardcoded API keys, tokens left during an early build, .env files, internal endpoints, credentials in config and what else. Once you pull an image, you can read all of it, run it locally and map the underlying business logic.
The agent's execution role let us do exactly that. Its policy included ECR read permissions, so we authenticated to the registry and pulled the image.
Login to ECR:
Pull docker image:
Run container as root:
From there the agent's source code, its dependencies, and whatever its developers baked in were ours to inspect, as root.
We wrapped this up with an automated process to make it efficient and scalable to run for all agents in the region. (More on that below)
It's not just the HTTP tool
At this point a reasonable reaction is "so don't give agents a raw HTTP tool." That doesn't help.
The isolation failure is at the platform level, not the tool level, so anything that can generate outbound traffic reaches IMDS just the same. We reproduced the identical result through several tools including Strands’ built-in shell tool.
Now that we got the credentials
A stolen credential is only as useful as the role behind it, so once we had the execution role, the real question was what that role can actually do - and it turned out to be a lot.
The role AgentCore attaches to agent runtime by default is badly overprivileged - it holds permissions stretching much more beyond our compromised agent.
Once we got the role in hand, we could extract all agent IDs and names in the region using the permission logs:DescribeLogGroups. Now what?
We noticed a lot of permissions contained wildcard access.
For example the ECRImageAccess permission :
which basically allows you to pull any image in the AWS account and region.
Having both agent names and permissions in hand, the interesting question becomes can we pull other agents' images?
The answer is yes - the repository names, it turns out, aren't random: AgentCore names each repository after its agent (`bedrock-agentcore-<agent_name>`). So running our automated tool on all the discovered agents got us all source code of all agents in the region within a few seconds.
That’s not everything. The more we dug into the role's permissions, the more gold we found.
We discovered that the role held permissions with READ, WRITE and DELETE access to various AgentCore and AWS services across the AWS region. This allowed us to invoke other agents and move laterally within the region, read all private conversations for all users and agents, poison memory and keep persistence, harvest credentials and API keys that can unlock access beyond AWS and run destructive actions within the same region.
And the list is long.
What’s Next
In the upcoming blogs we break down exactly how each of these worked, deep dive into each capability and show how far we could take them, turning a single compromised agent into control over an entire AgentCore region.
Next up: Abusing the over-privileged role, where that region-wide IAM role stops being a curiosity and starts being the master key.
Responsible disclosure
We reported these findings to AWS on December 17th, 2025. Below is the disclosure timeline:
- December 25th, 2025: Zenity Labs discloses the IMDS access vulnerability to AWS.
- April 12th, 2026: AWS responded to the disclosure and closed the report as “informative.” AWS noted that it had made improvements to AgentCore’s IMDS behavior. Specifically, as of February 14, 2026, AgentCore had been updated to use IMDSv2 only, with all newly deployed agents launching with IMDSv2.