# AgentCorruption: one prompt takes over Bedrock AgentCore agents

> A single prompt to one exposed Bedrock AgentCore agent gave Zenity Labs the credentials to read, invoke and poison every agent in the region.

- **Severity:** High: A working attack on a widely used AI product or ecosystem. A fix may exist. Patch or mitigate this week.
- **Category:** Vulnerability, Attack
- **Published by:** Zenity Labs
- **Disclosed:** 2026-10-08
- **Affects:** Amazon Bedrock AgentCore
- **Research by:** Lana Salameh, Dmitry Lozovoy, João Donato, Tamir Ishay Sharbat
- **Primary source:** https://labs.zenity.io/post/agentcorruption-how-a-single-prompt-collapsed-the-entire-cloud-security-model
- **Page:** https://theinjection.dev/items/zenity-agentcorruption-bedrock-agentcore/

AgentCorruption is a chain Zenity Labs demonstrated against Amazon Bedrock AgentCore, where one prompt to an exposed agent yields IAM credentials and then control of every AgentCore agent in the same AWS account and region.

## What happened

Zenity Labs published AgentCorruption on October 8, 2026, a five-part study of Amazon Bedrock AgentCore, AWS's managed platform for running AI agents. The researchers reported the first flaw to AWS on December 25, 2025 and a second on January 12, 2026. AWS changed the platform over the months that followed, and the timeline sits in the table below.

## How it works

Bedrock AgentCore ran each agent in a Firecracker microVM that did not block traffic to the instance metadata service at 169.254.169.254. Any agent tool able to make outbound HTTP requests became an SSRF primitive, so a plain-language prompt could make the agent fetch its execution role's temporary STS credentials and hand them back. The default execution role carried wildcard permissions across AgentCore resources in the whole region, which turned one agent's credentials into reach over every agent in the account. Writing short-term memory events then let the researchers plant long-term memories that told an agent to fetch an attacker-controlled page before answering, giving a command and control channel that survived new sessions.

## Who is affected

Amazon Bedrock AgentCore deployments are the target, specifically agents reachable by an untrusted user that also hold a tool capable of outbound HTTP or shell access. Zenity Labs ran the chain in its own AWS account in us-west-2, and the blast radius it describes stops at the account and region boundary rather than crossing into other customers' accounts.

## What to do

Scope agent execution roles to specific resource ARNs instead of the region-wide wildcards AgentCore granted by default, and restrict memory actions such as CreateEvent and DeleteEvent to the agents that need them. Allowlist the destinations agent HTTP tools may reach, and confirm metadata access requires IMDSv2. Rotate any outbound provider secret an overprivileged role could have read.

## Quick facts

- **Affected:** Amazon Bedrock AgentCore agents in the same AWS account and region
- **Attack type:** Prompt injection to IMDS credential theft, then IAM abuse and memory poisoning
- **Found by:** Lana Salameh, Dmitry Lozovoy, João Donato and Tamir Ishay Sharbat, Zenity Labs
- **Reported:** December 25, 2025 and January 12, 2026
- **Status:** AWS moved AgentCore to IMDSv2 only on February 14, 2026, and Zenity Labs found the default role hardened by September 29, 2026
- **CVE:** None assigned

## Questions

### Is Amazon Bedrock AgentCore still vulnerable to AgentCorruption?

Amazon Bedrock AgentCore has changed substantially since Zenity Labs reported the chain. AWS moved the platform to IMDSv2 only on February 14, 2026, and Zenity Labs observed on September 29, 2026 that AWS had removed cross-region agent execution, private conversation reads and Secrets Manager access from the default execution role. Agents still running older custom roles need a manual review.

### How do I check whether my AgentCore execution role is overprivileged?

Review the IAM policy attached to each AgentCore execution role and look for wildcard resources, which Zenity Labs found on the default role. The researchers abused logs:DescribeLogGroups to enumerate agents, bedrock-agentcore:InvokeAgentRuntime to call private agents, ECR read permissions to pull agent images, and CreateEvent plus DeleteEvent on memory/* to write other agents' memory. Replace each wildcard with specific resource ARNs.

### Which secrets could an attacker reach through AgentCorruption?

Outbound provider credentials were exposed, because the default role held secretsmanager:GetSecretValue on wildcard paths covering every OAuth and API key secret in the region. Zenity Labs names GitHub, Slack and Salesforce as example connected services, and recovered an OpenAI API key from an agent's environment variables through the metadata service. Rotate any provider secret an affected role could read.

### Did AWS assign a CVE to the AgentCorruption findings?

No CVE appears in Zenity Labs' write-ups of AgentCorruption. AWS closed the first report, covering metadata service access, as informative on April 12, 2026, and told the researchers in February 2026 that it was working on the overprivileged default role. Zenity Labs rechecked the role on June 22, 2026 and found the permissions unchanged before AWS altered them later in the year.

## Sources

1. [Zenity Labs Overview](https://labs.zenity.io/post/agentcorruption-how-a-single-prompt-collapsed-the-entire-cloud-security-model)
2. [Initial IMDS Access](https://labs.zenity.io/post/agentcorruption-initial-imds-access)
3. [Overprivileged Role](https://labs.zenity.io/post/agentcorruption-one-role-to-rule-them-all)
4. [Agent Memory Hijacking](https://labs.zenity.io/post/agentcorruption-weaponizing-agent-memory-for-persistent-hijacking)
5. [Secrets Manager Theft](https://labs.zenity.io/post/agentcorruption-credential-theft-from-aws-secrets-manager-and-more)