The AgentCorruption vulnerability hit AWS Bedrock AgentCore, Amazon’s managed platform for running AI agents, this month. Security researchers at Zenity Labs disclosed the flaw on October 8, 2026. A single prompt sent to one public-facing agent could expose every other agent in the same AWS account and region. The issue combined weak network isolation with an overprivileged default execution role. AWS has patched the specific issues Zenity reported. However, the case raises hard questions about how enterprises secure autonomous agents running in production today.
What Is the AgentCorruption Vulnerability
AWS Bedrock AgentCore launched in 2025 as Amazon’s managed runtime for deploying AI agents at scale. Enterprises use it to host chatbots, coding assistants, and other autonomous AI agents in production without managing the underlying infrastructure. Agents run inside isolated Firecracker microVMs, a sandboxing technology AWS also uses for Lambda.
Zenity Labs found that the sandboxing did not fully isolate the network layer. An agent with web-request access could reach the instance’s local metadata endpoint. That endpoint returned temporary AWS credentials tied to the agent’s execution role. From there, an overprivileged default role let those credentials reach far beyond one agent.
How the AgentCorruption Attack Chain Works
The attack needed only one crafted prompt. An attacker sent it to a public-facing agent, such as a support chatbot. The prompt told the agent to make an outbound web request. That request reached the link-local metadata address at 169.254.169.254. Because the request came from inside the instance, the metadata service returned valid temporary credentials. Zenity Labs’ research describes this as an SSRF primitive built into the platform’s default setup.
Those credentials unlocked far more than one agent. The default execution role could list log groups, which revealed every agent ID in the account’s region. It could also pull container images from Elastic Container Registry, where repository names matched agent IDs. With invoke permissions scoped to the whole region, the attacker could call any agent in the account. That access let the attacker read private conversation sessions and plant false memories in agents with long-term memory enabled.
What Data and Credentials Were at Risk
The exposure went beyond temporary credentials. Attackers could reach secrets stored in AWS Secrets Manager through connected tool integrations. They could also read other users’ conversations with unrelated agents in the same account. Perhaps most troubling, attackers could write fabricated memories into agents with persistent memory, quietly altering future behavior.
How AWS Responded to the Disclosure
Zenity reported the initial metadata issue to AWS in December 2025. AWS closed that report as informative four months later. By then, it had moved new agents to IMDSv2, a version of the metadata service that requires authentication. Zenity followed up in January 2026 with a second report about the overprivileged default role. Those permissions did not change until September 29, 2026, after Zenity confirmed the gap had stayed open for months.
AWS disputes calling this a vulnerability at all. A company spokesperson called the behavior an intended, documented part of the platform, and said cross-account access always requires explicit permissions. Still, AWS removed cross-agent invocation, conversation reading, and Secrets Manager access from the default role. Zenity says it found no evidence of in-the-wild exploitation before the fix.
Why This Matters for Enterprise AI Agents
AgentCorruption is not an isolated AWS problem. Zenity says the underlying metadata weakness is not specific to one cloud provider. The incident lands as the DevSecOps market keeps expanding to meet exactly this kind of risk. Spending in that market is projected to reach $45.93 billion.
That growth reflects a real gap. Teams often trust platform defaults instead of auditing permissions themselves. Default configurations rarely assume one compromised agent can reach every other agent in the account. Treating agent platforms like any other multi-tenant service, rather than a fully managed black box, closes that gap.
How to Protect Your AWS AgentCore Deployment
Security teams running AgentCore should start with least privilege. Scope each agent’s execution role to only the resources it actually needs, not every AgentCore resource in the region. Teams should also confirm their agents use IMDSv2, which AWS made the default for new deployments after the disclosure.
Older agents deployed before February 2026 may still run the earlier configuration. Audit existing deployments instead of assuming the platform-wide fix already covered everything running. Logging and alerting on unusual cross-agent invocation calls can also catch an attack chain like this one in progress.
Key Takeaways
- AgentCorruption let one prompt compromise every agent in an AWS AgentCore account and region.
- The chain combined a metadata service weakness with an overprivileged default execution role.
- Zenity Labs disclosed the issues between December 2025 and January 2026; AWS finished fixing them by September 29, 2026.
- AWS maintains the behavior was documented and expected, not a vulnerability.
- Teams should audit execution role permissions and confirm IMDSv2 is enforced on every agent.
Frequently Asked Questions About AgentCorruption
What Is AWS Bedrock AgentCore?
AWS Bedrock AgentCore is Amazon’s managed platform for deploying and running AI agents in production. It launched in 2025 and manages the infrastructure behind autonomous agents, including compute, memory, and identity.
What Is the Instance Metadata Service, and Why Did It Matter Here?
The Instance Metadata Service, or IMDS, lets a cloud instance query its own configuration and temporary credentials. Zenity found that agents could reach IMDS through ordinary web requests, exposing those credentials to a prompt injection attack.
Has AWS Fixed the AgentCorruption Vulnerability?
Yes. AWS moved new agents to IMDSv2 and tightened the default execution role’s permissions. Zenity confirmed the permission changes went live on September 29, 2026.
Is My Existing AgentCore Deployment Still at Risk?
Possibly, if it predates the fixes. Audit execution role permissions and confirm IMDSv2 enforcement rather than assuming the platform-wide patch reached every running agent.
Did Attackers Exploit AgentCorruption Before AWS Patched It?
Zenity says it found no evidence of in-the-wild exploitation before the fix. The company noted that most AgentCore deployments had relied on obscurity rather than hardened defaults.
How Is This Different From Typical Prompt Injection Attacks?
Most prompt injection attacks manipulate a single agent’s output. AgentCorruption used a prompt to trigger a request that escalated into full infrastructure access across an AWS account.
Final Thoughts
This flaw shows what happens when platform defaults outpace security review. AWS fixed the specific chain Zenity found, but the broader lesson stands. Autonomous agents need the same identity and network scrutiny as any other multi-tenant cloud service. Being new is not an exemption. Teams adopting AgentCore, or any agent platform, should audit execution roles now. Don’t wait for a researcher to find the gap first. Check your default permissions this week, not after the next disclosure.
Photo by Google DeepMind: Pexels
Priya Nandakumar covers enterprise technology and AI infrastructure for DevX, with a focus on the systems decisions that look fine until they don't. Caching layers, message queues, fault tolerance. She spent seven years as a backend engineer at two Series C startups before moving into technical journalism, and she still reads changelogs for fun.
