system: OPERATIONAL
← back to all hacks
AGENTS MEDIUM NEW

AgentCorruption: one prompt, a default IAM role, and account-wide agent takeover on AWS AgentCore

Zenity Labs showed that a public-facing agent on Amazon Bedrock AgentCore could be prompted to leak its role credentials, and that the broad default role reached other agents, chats and secrets.

2026-10-12 // 6 min affects: amazon-bedrock-agentcore

What is this?

On October 8, 2026, Zenity Labs (authors Tamir Ishay Sharbat and Lana Salameh) published “AgentCorruption”, a research series on Amazon Bedrock AgentCore, AWS’s managed platform for deploying AI agents. The work was also presented at SecTor 2026 in Toronto, and Dark Reading and The Next Web covered it the same week.

The headline claim is that a single prompt sent to a public-facing agent could lead to access over other agents in the same AWS account and region. Two details matter for calibration: the research covered one account and region, and AWS disputes that this is a vulnerability, describing the behavior as documented and expected. No CVE was assigned.

How it works

Zenity describes a chain of three weaknesses, each ordinary on its own.

First, initial access. Agents run in Firecracker MicroVMs, and according to Zenity the network isolation did not stop an agent tool that makes HTTP requests from reaching the link-local instance metadata service (IMDS). An agent with a web-request or shell tool could therefore be asked, in plain language, to return its own temporary role credentials. This is a server-side request forgery pattern applied to an agent: the “request forger” is the model, steered by untrusted input.

Second, an over-broad default role. Zenity reports that the default execution role was not scoped to a single agent but covered AgentCore resources across the account and region. With those credentials the researchers could enumerate agents (via log-group listing), pull container images, invoke other agents, read conversation events across users and sessions, and retrieve API keys and Secrets Manager values meant to stay out of the agent’s reach.

Third, persistence through memory. Where long-term memory was enabled, permission to create memory events allowed the researchers to plant a fake event that persistently altered an agent’s behavior across sessions.

None of this required a model jailbreak in the classic sense. The prompt only needed to make the agent use a tool it already had.

Why it matters

The case illustrates a pattern that recurs across agent platforms: the agent’s tools run with the agent’s cloud identity, so any prompt-injection path becomes a cloud-credential path. When the identity is shared or over-scoped, one compromised customer-facing agent exposes co-located internal agents. Zenity’s own framing is that agents should be treated as potential entry points.

The disclosure history is also instructive for defenders reading vendor statements carefully (dates per Zenity): reported December 25, 2025 and January 12, 2026; IMDSv2-only for newly deployed agents from February 14, 2026; first report closed as “informative” on April 12, 2026; default role unchanged on June 22, 2026; and, on September 29, 2026, Zenity observed that cross-agent invocation, conversation-reading and Secrets Manager permissions had been removed from the default role. AWS has not described this as a patch, so treat that last point as Zenity’s observation. Dark Reading reports Zenity saw no evidence of in-the-wild exploitation.

Defenses

  • Least privilege per agent. Give each agent its own execution role limited to the resources it needs; do not rely on the default role. This is also AWS’s own recommendation.
  • Require IMDSv2 and restrict metadata access. Newly deployed agents use IMDSv2 only, but audit older deployments. Where possible, block or filter access to 169.254.169.254 from agent tools.
  • Constrain HTTP and shell tools. Use destination allowlists for web-request tools and avoid giving public-facing agents a generic shell.
  • Separate trust zones. Do not co-locate customer-facing and internal agents in the same account and role boundary.
  • Protect memory writes. Restrict who and what can create memory events, and review stored memories for instruction-like content.
  • Monitor. Alert on role credentials used from unexpected IP addresses and on unusual cross-agent invocations.

Status

ItemDetail
ComponentAmazon Bedrock AgentCore (runtime, default execution role, memory)
PublishedOctober 8, 2026 (Zenity Labs); Dark Reading updated October 9 with AWS statement
CVENone assigned
IMDSv2Enforced for newly deployed agents since February 14, 2026 (per Zenity and AWS)
Default roleNarrowed as observed by Zenity on September 29, 2026; AWS calls the original behavior documented and expected
In-the-wild exploitationNone reported by Zenity

Sources