All posts
Supply Chain Compromise

AgentCorruption: One Prompt, Region-Wide Agent Takeover

Zenity Labs showed an AgentCore agent's execution role, exfiltrated via one IMDS prompt, becomes a region-wide skeleton key over every agent

Securityv0 Intelligence Team OWASP: ASI06 sv0 finding: nhi_compromise
aws-agentcore nhi imds cross-agent prompt-injection zenity

The Incident

On October 8, 2026, Zenity Labs publicly disclosed “AgentCorruption,” a chain of flaws in AWS Bedrock AgentCore, timed to a talk at SecTor 2026 in Toronto. A single prompt to a public-facing AgentCore agent — any agent whose default tool set could issue outbound HTTP requests — coerced it to call the EC2-style instance metadata service at 169.254.169.254 from inside its sandbox virtual machine, which returned the agent’s execution-role STS credentials. Those credentials, used by the researcher from an unrelated laptop, authorized access to every other AgentCore agent in the same AWS account and region: private conversations, deployed agent source and container images, Secrets Manager contents, and long-term memory stores. The AgentCore starter toolkit’s auto-created default role carried account- and region-wide read, write, and delete rights across AgentCore resources rather than scoping to a single agent — Palo Alto Unit 42 independently described the same role shape as “IAM God Mode,” and Mitigant characterized the resulting pattern as “cross-agent privilege escalation.” Zenity reports no observed in-the-wild exploitation prior to AWS’s fixes.

Zenity disclosed the metadata-exposure half of the chain to AWS on December 25, 2025, and the role-scope half on January 12, 2026. In February 2026, AWS made IMDSv2 the default on AgentCore deployments, forcing a session-token handshake on any future metadata call. Per Zenity’s account to The Next Web, AWS also narrowed the AgentCore starter toolkit’s default execution role in late September 2026, ahead of publication; AWS has not published a dated advisory confirming that change independently of Zenity’s disclosure. No CVE has been assigned to this specific chain by either researcher or vendor; a third-party aggregator conflated it with the unrelated AgentCore CoreBreak CVE, which concerns InvokeHarness tool-use-block forgery, not cross-agent IAM.

MITRE ATT&CK coverage: T1552.005 (Unsecured Credentials: Cloud Instance Metadata API — the IMDS leak that mints the STS bundle) and T1550.001 (Use Alternate Authentication Material: Application Access Token — the stolen role used from the attacker’s own machine against sibling agents).

The Authority Path That Failed

The identity carrying execution authority at the moment of failure was the AgentCore agent’s AWS execution role — a workload NHI minted by the AgentCore starter toolkit when the operator stood the agent up. The scope that role held was account- and region-wide authority across AgentCore resources: invoke other agents, read any session, read any Secrets Manager entry reachable in the account, mutate long-term memory. The scope it exercised, under a single prompt that coerced the agent into fetching http://169.254.169.254/latest/meta-data/iam/security-credentials/, was: emit its own STS bundle inside a chat response. From AWS’s point of view nothing out of the ordinary happened — a workload with legitimate IAM credentials made a legitimate metadata call. The agent’s own tool manifest advertised HTTP as a capability.

The trust anchor that failed first was the implicit assumption that an agent’s execution role would only ever act from inside the sandbox the role was bound to. The toolkit’s auto-generated role was never a per-agent credential; it was a shared one, broadly scoped across every AgentCore resource in the account and region. Once the STS bundle crossed the sandbox boundary — as the body of a chat message, served over the agent’s public endpoint — it stopped being a workload credential and became a region-wide skeleton key. The gap between held and exercised was auditable before the first prompt landed: a role that grants bedrock-agentcore:InvokeAgent and session-read rights across every resource in an account is a cross-tenant primitive by construction.

SecurityV0 Perspective

This is nhi_compromise at the managed-runtime layer. The LiteLLM/TeamPCP case fit the same class because every hop in that chain consumed one machine identity to produce access to the next; AgentCorruption generalizes the pattern inside a single cloud account — one agent’s execution role, lifted via prompt injection, becomes the authority that compromises every other agent sharing that role shape. The AgentCore product family has now produced three orthogonal unproven-authority failure modes in under two months — CoreBreak’s tool-call forgery, Unit 42’s heap-view credential read, and AgentCorruption’s cross-agent IAM collapse — and SecurityV0’s thesis is unchanged across all three: operators need an evidence pack describing what authority each agent’s identity actually holds against its siblings, not what the “starter toolkit” quietly provisioned at creation.

The evidence pack for this finding would enumerate, per AgentCore agent in the environment: the exact IAM role attached to the agent at invocation, the full action-and-resource closure of that role (every sibling agent it can invoke, every secret it can read, every memory store it can mutate), the metadata-service posture of its sandbox (IMDSv2-only or legacy IMDSv1), and the egress policy at 169.254.169.254 on the per-agent runtime. Before exfiltration, the pack answers: which agent executions hold authority they do not need over sibling agents? After the fact, it answers the forensic question: which agent sessions saw an IMDS fetch during the exposure window, which STS bundles were minted, and where were those credentials used next?

What To Do

  • Scope every AgentCore execution role per-agent, not per-account. The starter toolkit’s auto-created role is account- and region-wide across AgentCore resources — the AWS runtime-permissions documentation now carries a security warning that the auto-generated roles are “designed for development and testing” and are not recommended for production. Replace it with a role whose Resource ARNs name the specific agent, session store, and secret paths that one agent is authorized to touch. A role that can invoke sibling agents is a cross-tenant credential; treat it that way.
  • Enforce IMDSv2-only on every agent runtime, even on managed platforms. AWS made IMDSv2 the default on AgentCore in February 2026, but existing deployments stood up before that date may still answer IMDSv1 GETs. Verify MetadataOptions.HttpTokens=required on every AgentCore workload and block IMDSv1 at the network layer where possible. IMDSv2’s session-token handshake turns the leaked GET into an exchange the attacker cannot complete through a passthrough prompt.
  • Block egress to 169.254.169.254 from every agent sandbox that does not legitimately need it. The metadata address is reachable from inside AgentCore sandboxes by default and is indistinguishable from any other HTTP destination in the agent’s tool manifest. Add a deny rule at the sandbox network boundary and require an explicit allowlist entry per agent whose role genuinely needs instance-identity material at runtime.
  • Treat every execution-role STS bundle that leaves the sandbox as a confirmed credential leak. The exfiltration primitive here is not file I/O — it is a model emitting a role credential inside a chat response. Scan outbound agent responses for AWS short-term credential patterns (ASIA[A-Z0-9]{16} and session-token prefixes) and rotate the underlying role on any hit. CloudTrail GetCallerIdentity and AssumeRole calls from unexpected principals are the lagging signal; the model’s own output is the leading one.
  • Enumerate your AgentCore execution-role closure before every deploy. For each agent, resolve its role to the complete set of sibling agents it can invoke, sessions it can read, secrets it can list, and memory stores it can mutate — then diff that set against the agent’s operator-attested purpose. Any gap is an unproven authority grant that a single prompt turns into cross-agent access.

Sources

All posts