AgentCorruption AWS research showed how one exposed Amazon Bedrock AgentCore agent could reveal temporary role credentials and open paths to neighboring agents in the same AWS account and Region. Published by Zenity Labs on October 8, 2026, the controlled attack relied on network-capable tools and excessive IAM permissions. It was not an AWS-wide breach, and no exploitation in the wild was confirmed by October 13, 2026.
What is the AgentCorruption AWS attack?
AgentCorruption AWS is a controlled attack chain that turns one network-capable Amazon Bedrock AgentCore runtime into a foothold for accessing AWS credentials, services, other agents and memory. Zenity Labs demonstrated the chain within one AWS account and Region in 2026; the research did not establish access across unrelated customer accounts.
The chain began with an externally reachable agent equipped with an HTTP, shell or comparable network tool. Researchers instructed that agent to contact the metadata address 169.254.169.254, according to Zenity Labs’ October 8, 2026 disclosure.
The metadata response exposed temporary AWS Security Token Service credentials assigned to the agent’s execution role: an access-key ID, secret access key and session token. Zenity exported those credentials and used them outside the runtime to call AWS APIs successfully.
That distinction matters. A prompt didn’t somehow break IAM. The prompt persuaded authorized runtime code to reach a credential source, after which the role’s permissions determined the blast radius. The case supports the broader shift from policy documents toward AI governance enforced through runtime controls.
How did one AWS agent expose other agents?
The AgentCorruption AWS chain reached other agents because the compromised execution role historically carried broad permissions for Amazon CloudWatch Logs, Amazon Elastic Container Registry and AgentCore Runtime. Those permissions let Zenity Labs identify neighboring agents, retrieve container images and source code, and invoke internal runtimes in the same account and Region during 2026 testing.
The discovery phase drew useful identifiers from logs and infrastructure resources. Broad Amazon ECR access then exposed container images belonging to other agents, potentially revealing application code, tool definitions and operational assumptions that weren’t intended for a public-facing runtime.
Zenity also found that bedrock-agentcore:InvokeAgentRuntime enabled lateral invocation of discovered internal agents. An internet-facing agent could therefore become a caller of agents that weren’t directly exposed to the internet, provided the shared or generated role authorized the action.
The comparison below separates each permission from its demonstrated consequence. It also shows why fixing metadata access alone doesn’t remove the architectural risk.
| Stage | AWS capability or permission | Observed result | Practical boundary |
|---|---|---|---|
| Initial access | Network-capable agent tool | Request to 169.254.169.254 |
Required a reachable agent able to make the request |
| Credential access | Runtime metadata service | Temporary STS credentials for the execution role | Credentials inherited only that role’s permissions |
| Discovery | Broad CloudWatch Logs and ECR access | Agent identifiers, images and source code | Demonstrated within the same account and Region |
| Lateral movement | bedrock-agentcore:InvokeAgentRuntime |
Invocation of internal agents | Required permission on the target runtime |
| Conversation access | ListActors, ListSessions and ListEvents |
User, session and short-term history enumeration | Limited by AgentCore Memory authorization |
| Persistence | AgentCore Memory write access | Planted instructions and later conversation redirection | Required memory modification rights |
A useful risk calculation follows directly from that model: one exposed agent plus one shared role can create as many lateral paths as the role is allowed to invoke. If a role can invoke 12 runtimes, compromise of one public agent can create up to 11 neighboring runtime targets, before counting logs, images, memories or secrets. The number isn’t an AWS default; it’s a way to quantify your own IAM exposure.
Could AgentCorruption read conversations or persist?
AgentCorruption AWS testing showed that AgentCore Memory permissions could expose users, sessions and short-term conversation histories, while memory write access could create persistence. Zenity Labs used authorized memory operations in 2026 to plant instructions, alter later agent behavior and establish a channel that redirected subsequent conversation data outward.
Permissions including ListActors, ListSessions and ListEvents supported enumeration. In a role with access to multiple memory resources, that converts a single-agent compromise into a privacy problem involving conversations handled elsewhere.
Write access is more dangerous than read access because the effect can survive the original malicious prompt. A planted instruction may influence later sessions after the initial interaction ends, turning memory into a control surface rather than passive storage. Similar concerns appear in reports of agents being redirected toward phishing behavior.
Honestly, broad memory write permission only makes sense when the agent’s design explicitly requires it. Read and write access should be separated wherever AWS resource and action controls permit, with memory resources scoped to a single agent or trust zone.
Was AgentCorruption an AWS vulnerability or a configuration failure?
AWS disputed the description of AgentCorruption AWS as a vulnerability in October 2026 and said execution-role credential access was documented behavior. Zenity Labs framed the combined metadata, default-role and memory pathways as security issues. The evidence supports an architectural postmortem: expected credential delivery became dangerous when paired with powerful tools and excessive authorization.
AWS documentation dated June 30, 2026 says AgentCore Runtime invocations are rejected unless MMDSv2 is enabled through metadataConfiguration.requireMMDSV2=true. The same documentation explains that code inside the microVM can still receive the runtime execution role’s credentials. MMDSv2 raises the access bar, but it isn’t an IAM boundary.
Zenity reported that all newly deployed AgentCore agents had used IMDSv2-only behavior since February 14, 2026. The Next Web reported that Zenity’s September 29, 2026 validation found a narrower default execution role, with permissions used for cross-agent invocation, conversation access and AWS Secrets Manager access removed.
No CVE was reported. Zenity said on October 8, 2026 that AWS had addressed or patched the reported issues, while AWS maintained that the underlying credential behavior was expected. Treating the episode as an unpatched zero-day would therefore be misleading, just as calling it harmless configuration would ignore how defaults and shared roles shape real deployments.
There is also a disclosure-date wrinkle that many summaries omit. Zenity’s narrative gives December 17 and December 25, 2025 for the initial metadata report, while The Next Web says the broad default-role issue was reported on January 12, 2026. Those dates may describe separate findings, but the published sources don’t fully reconcile them.
How should you defend Amazon Bedrock AgentCore?
Defending Amazon Bedrock AgentCore requires MMDSv2, one least-privilege execution role per agent, restricted outbound networking and separation between public and internal runtimes. AWS security guidance available on October 13, 2026 recommends VPC deployment, VPC endpoints or AWS PrivateLink where possible, narrowly scoped resource ARNs and regular permission audits.
Start with identity. Replace generated or shared roles with custom execution roles that authorize only the model, image, log group, memory, secret and downstream service each agent requires. Wildcard resources deserve scrutiny even when the allowed action appears harmless.
Then constrain communication. A public-facing agent should not be able to enumerate or invoke internal agents merely because both run in one account and Region. Separate trust zones, security groups and roles reduce the chance that a prompt-injection event becomes lateral movement. Hardware-backed containment takes the same premise further, as seen in Nvidia’s approach to AI agent isolation.
The AgentCorruption AWS review checklist should cover these controls:
- Confirm every runtime requires MMDSv2 and identify older deployments that may predate the 2026 enforcement change.
- Search IAM policies for wildcard resources, shared execution roles and permission to invoke neighboring AgentCore runtimes.
- Limit CloudWatch Logs and Amazon ECR access to the log groups and images assigned to one agent.
- Review AgentCore Memory actions, especially actor, session and event listing plus all write permissions.
- Check AWS Secrets Manager access and remove secrets that the runtime doesn’t need for its defined task.
- Restrict outbound security-group rules and deny access to destinations that no approved tool requires.
- Separate public and internal agents by role, network path, memory resource and session boundary.
Don’t rely on prompt instructions such as “never access metadata.” Prompts govern model behavior probabilistically; IAM and network policy enforce authorization. The same security lesson appears when agent data-leak incidents force runtime restrictions rather than another layer of polite instructions.
AgentCorruption AWS FAQ
Was AgentCorruption exploited in the wild?
No confirmed AgentCorruption exploitation in the wild was identified in the reviewed Zenity disclosures, AWS documentation or independent coverage as of October 13, 2026. The published evidence describes controlled security research rather than an active customer breach.
Did AgentCorruption affect every AWS account?
AgentCorruption did not demonstrate access to every AWS customer or unrelated account. Zenity Labs showed lateral access to resources permitted by an execution role within the same AWS account and Region.
Does MMDSv2 stop the whole attack chain?
MMDSv2 does not replace least-privilege IAM because AWS documentation says runtime code can receive its execution-role credentials. MMDSv2 is one defensive layer; narrow roles, egress controls and agent isolation limit what exposed credentials can do.
Should you rotate AgentCore execution-role credentials?
AgentCore uses temporary STS credentials, but suspected exposure still warrants incident-response steps in 2026: stop or isolate the runtime, review CloudTrail and service logs, remove excessive permissions, rotate any separately exposed secrets and redeploy with a scoped role.
Can a prompt alone secure an AWS agent?
A prompt cannot enforce AWS authorization or network boundaries. Amazon Bedrock AgentCore security depends on IAM policies, runtime metadata controls, security groups, VPC architecture, resource isolation and monitoring.