TL;DR
AWS Bedrock AgentCore is AWS’s managed platform for deploying and operating AI agents. It’s a one stop shop allowing developers to easily deploy their agents, add tools, prompts, proper monitoring, and whatever it is they need to build a production-ready agent.
But AgentCore came with an age old security problem that has been haunting cloud environments for years: IMDS.
We discovered that agents deployed through AgentCore could access their instance’s IMDS endpoints. This meant that an external attacker with nothing more than chat access to a single exposed agent could send a single prompt, extract its IMDS credentials, and use them to take over all AgentCore agents in the same AWS account and region. This includes reading full private conversations, planting memories to persistently alter agent behaviour, extracting credentials from AWS Secrets Manager, and more.
In the following blogs we dive into the flaw, the underlying issues, and the enormous blast radius. Strap yourselves in, you’re in for a ride.
This is an overview blog covering the findings at a high level. To make sure we could also share the full technical details, we’ve broken the research into a five-part blog series.
You can find the 4 more detailed blogs here:
- AgentCorruption: Initial IMDS Access
- AgentCorruption: One Role to Rule Them All
- AgentCorruption: Weaponizing Agent Memory for Persistent Hijacking
- AgentCorruption: Credential Theft from AWS's Secrets Manager and More
Time to dive in.
SSRF in AgentCore and IMDS Access
IMDS, or the Instance Metadata Service, is a special local service available from within AWS compute instances. It exposes metadata about the instance and, most importantly for us, can also provide temporary AWS credentials for the IAM role assigned to the workload. To access it, the instance simply sends a request to the link-local address 169.254.169.254.
A deployed AWS AgentCore agent runs inside a Firecracker MicroVM. Unfortunately, these MicroVMs do not provide sufficient network isolation. As a result, any agent tool capable of making HTTP requests would send those requests directly from within the instance itself. Effectively creating an SSRF primitive.
Leveraging this SSRF vulnerability an attacker could abuse an exposed agent and direct it to issue a request to the instance’s IMDS endpoint. Because the request originated from within the instance itself, IMDS would return the temporary IAM credentials available to the AgentCore agent. All it took was a simple prompt injection.
Ok, so we got credentials, now what?
The Overprivileged Role And Blast Radius
Now that we have the credentials the next question is what we can do with them. The answer is a lot. Because the Role that is attached to AgentCore workloads by default is overprivileged. And when we say overprivileged we mean it.
The default AgentCore role wasn’t scoped to the specific agent. Instead, it included broad permissions across all AgentCore resources in the entire region. This includes the permissions to invoke agents, read sessions, create memories, and even retrieve secrets from AWS’s secrets manager.
Pulling docker images, activating other agents and reading conversations
The fact that the role is overprivileged is one thing, but in order to make requests to other agents we needed their IDs. Lucky for us the AgentCore’s IAM role included the permission to DescribeLogGroups which could be easily used to discover all agents and their IDs throughout the region (more details here).
Now that we had the agents’ IDs, it was time to see what else we could do with them. One of the first things we noticed was that the role had permission to pull any ECR image across the entire region. To do that, however, we first needed the name of each ECR repository. Fortunately, for AgentCore resources this was easy: the ECR repository names matched the agents’ IDs we had just discovered.
But that was just the beginning. The role also included the bedrock-agentcore:InvokeAgentRuntime permission, scoped to the entire region. Meaning we could now invoke any AgentCore agent in the same AWS account and region. This opened the door to wide lateral movement - compromising a single exposed agent could give us access to the organization’s other internal and potentially sensitive agents we were never authorized or meant to reach.
Then things got even worse. The role also included the bedrock-agentcore:InvokeAgentRuntime and bedrock-agentcore:ListEvents permissions, again scoped to the entire region. With these permissions, we could read all private conversations across all AgentCore agents, users and sessions. Breaking down AgentCore’s privacy boundaries completely. Whatever it is your users are talking about with your agents, we could now see everything.
Memory Poisoning and Persistent Manipulation
Read permissions weren’t the only permissions available to AgentCore’s default IAM role. The role was also equipped with the bedrock-agentcore:CreateEvent permission for BedrockAgentCoreMemory. This enabled us to establish persistence across any agent in the region which had long-term memories enabled.
By leveraging the IMDS credentials we could send direct API requests to create new memories across different agents and users. These in turn would persistently alter agent behaviour and hijack the agents’ goals across future sessions. Users could have continued talking to what appeared to be a trusted enterprise agent while behind the scenes it operated under attacker-controlled instructions. Essentially allowing attackers to take complete control of official enterprise agents without anyone noticing.
Connected Tools Credential Theft
AgentCore provides a full framework for building AI agents, and you can’t build agents without tools. Those tools often require some form of authentication. Now, instead of giving the agent direct access to those credentials, AgentCore recommends storing them securely through AgentCore Identity and AWS Secrets Manager.
Then, when the agent needs to call an external tool (whether an MCP server, an official connector or an API), the request goes through AgentCore Gateway. The Gateway handles the authentication for the agent, adding the required credentials to the request before sending it to the external service.
This all incredibly secure, until you learn that AgentCore’s default IAM role also included access to 2 very sensitive permissions: bedrock-agentcore:GetResourceApiKey and secretsmanager:GetSecretValue enabling an attacker to access all credentials AgentCore has meant to keep away from the agent.
Responsible Disclosure
Given the severity of our findings we went ahead and disclosed them to AWS. We reported our findings in 2 separate submissions:
Report #1: AWS Bedrock AgentCore - Initial IMDS Access
- 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.
Report #2: AWS Bedrock AgentCore - IMDS Access Blast Radius
- Jan 12th, 2026: Zenity Labs discloses a report detailing AgentCore’s overprivileged default role and the resulting blast radius of the initial report’s IMDS access.
- February 25th, 2026: AWS reaches to update that the team is actively working on addressing the underlying issue. However, AgentCore’s default IAM role stays the same.
- June 22nd, 2026: Zenity Labs reviews AgentCore’s default execution role again and confirms that its permissions remain unchanged.
- September 29th, 2026: During a final review before publication, Zenity Labs observes substantial changes to AgentCore’s default execution role. AWS has removed the permissions that allowed cross-region agent execution, reading private conversations, and accessing secrets stored in AWS Secrets Manager, as well as significantly restricting other permissions and hardening AgentCore’s default execution role.
We would like to thank AWS for their collaboration throughout this process.
Summary and Takeaways
In this blog we’ve laid an overview of how a simple prompt to a single agent could allow the compromise of an entire AWS AgentCore region. But there’s a bigger takeaway here.
As enterprises rapidly adopt AI agents, cloud platforms are becoming the default deployment environment. This creates a fundamental security challenge: agents need their creative space to be useful, while cloud security is built around limiting access as much as possible.
AgentCorruption shows what can happen when this balance breaks. A single agent can become an entry point to a much larger environment allowing attackers to access resources far beyond the agent they initially compromised.
This matters not only for AgentCore. Organizations routinely run customer-facing and internal agents side by side in the same cloud environments. These agents often handle sensitive employee and customer data, are connected to powerful tools, business applications, and more. As agents gain more autonomy and more access, a single unexpected weakness in one agent could collapse the boundaries of an entire environment, and open paths to data and resources that were never meant to be exposed.
When deploying agents to the cloud, tread carefully. Hitting this balance is no easy task, and AgentCorruption is one prime example.