AgentCorruption: AgentCore Metadata and IAM Risk

Zenity’s October 2026 research reports that model-influenced tools could reach AgentCore runtime metadata and that historical default-role permissions widened access. AWS says access to a runtime’s own role credentials is expected and recommends least-privilege roles. Zenity’s research cites no CVE identifier and does not establish a customer breach.^{[1], [4]}

💡 Plain English Explainer (ELI5)

An agent in a workshop has a badge for the tasks its owner assigned. Zenity says a model-guided tool could ask the workshop’s internal badge desk for that badge; the badge’s old permissions then opened more rooms than the agent needed. AWS says agents are expected to receive their own role credentials inside the workshop. The useful defense is to narrow what each badge opens and to govern which tools can make internal requests.^{[1], [4]}

Core Concepts & Subsystem Terms

AgentCorruption: Zenity Labs’ name for its controlled research chain against Amazon Bedrock AgentCore. Zenity does not cite a CVE identifier, and its research does not establish a customer breach.^{[1], [7]}
MMDS and execution-role credentials: AWS documents that code inside an AgentCore microVM can access temporary credentials for that runtime’s execution role through MMDS. The service describes this as expected behavior; the role’s permissions determine what those credentials authorize.^{[4], [5]}
Permission blast radius: The execution role defines which AWS actions and resources agent code can access. Zenity reports broad historical same-account, same-Region permissions. AWS recommends least privilege; authorization depends on the operation’s applicable identity and resource policies. AWS specifically says cross-account access requires grants on both the role and target resource.^{[3], [1], [6]}
CWE-918 — editorial mapping: This page uses CWE-918 as an editorial mapping for an agent tool making a server-side request to an internal metadata service. AWS did not assign this CWE; metadata access is documented behavior.^{[8], [4], [1]}

Framework mappings

FlawOpen’s conceptual mapping to MITRE CWE; no vendor or CVE record assigned this weakness ID to this research demonstration. CWE-918

Step-by-Step Attack Flow

Step 1

A public agent has an outbound tool

Zenity tested a public-facing AgentCore agent with a tool that could send outbound requests. The scenario requires a reachable agent and a tool path the model can influence; it does not describe every deployment.^{[2], [1]}

Step 2

Model influence reaches metadata

Zenity reports that its test agent could be induced to request its local metadata service. AWS documentation says code inside the microVM can access MMDS credentials; the disputed security question is the model-to-tool path and the authority granted to those credentials, not whether the runtime exposes its own role.^{[2], [1], [4]}

Step 3

The response represents the agent role

AWS documents that MMDS provides temporary credentials for the configured execution role. Those credentials do not inherently grant access to every resource; IAM and applicable resource policies determine the operations they authorize. AWS specifically describes explicit grants on both the role and target resource for cross-account access.^{[4], [6], [1]}

Step 4

Historical permissions widened impact

Zenity reports that the then-default role allowed operations across other AgentCore resources in the same account and Region, including invocation, session/event access, memory operations, and secrets access. Zenity says AWS substantially narrowed the default role by September 29, 2026. This does not establish changes to customer-managed roles.^{[3], [1], [6]}

Step 5

Current controls address separate boundaries

Zenity says AWS had moved newly deployed agents to MMDSv2 on February 14, 2026. Current AWS guidance states MMDSv2 must be enabled for runtime invocation from June 30, 2026. AWS still documents in-VM access to execution-role credentials, so MMDSv2 does not replace least-privilege IAM or control of model-influenced tools. The separation of these controls is a defensive inference from the sources.^{[5], [4], [1]}

Evidence and current scope

Boundary	Evidence	Defender action
Metadata access	Zenity reports access in its test; AWS documents MMDS credentials for code inside the microVM.	Treat agent code and model-influenced tools as holders of the execution role.
Role permissions	Zenity reports broad historical defaults. AWS says cross-account access requires explicit grants on both the role and target resource; other operations follow their applicable IAM and resource-policy rules.	Inspect deployed roles and resource policies; verify the policies applicable to each operation and do not infer authorization scope from a prompt or service default.
Default-role change	Zenity says it observed AWS narrow the default role on September 29, 2026. It does not say customer-managed roles changed automatically; Zenity cites no CVE identifier, and its research does not establish a customer breach.	Verify effective roles in each account and Region; do not assume customer roles were changed.
MMDSv2	Zenity dates rollout of MMDSv2 for newly deployed agents to February 14, 2026; current AWS docs require it for runtime invocation from June 30, 2026. AWS still documents in-VM credential access.	Enable MMDSv2, then separately scope role actions, resources, and callers.

Root Cause Analysis

Two boundaries must be evaluated separately: model-influenced tools can make requests from inside a runtime, and the execution role defines the authority of those requests. AWS considers access to the runtime’s own credentials expected; Zenity’s reported cross-agent impact depended on historical role scope. Enabling MMDSv2 does not narrow IAM, while narrowing the role does not prevent model-directed internal requests. Review tool egress and IAM authorization independently; network egress restrictions alone do not establish that MMDS is inaccessible from code inside the microVM.^{[1], [3], [4], [5]}

Source Code: Flaw vs. Secure Implementation

Illustrative IAM policy statements only; they are not AWS’s historical policy or its later default-role change. AWS recommends scoping runtime permissions to specific resource ARNs and avoiding wildcards. The first statement demonstrates the broad resource pattern; the second scopes invocation to one approved runtime, if this permission is needed. Omit the permission if it is not needed. Validate action/resource support and companion resource policies against the deployment; this is not a complete deployable policy.^{[3], [6], [5]}

UNPATCHED FLAW

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/*"
}

HARDENED SECURE PATCH

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/APPROVED_RUNTIME_ID"
}

Engineering & System Hardening Checklist

✓Inventory each runtime execution role in every account and Region; compare effective permissions with current AWS and customer-managed policies.^{[6], [5]}
✓Remove cross-runtime invocation, conversation access, secret retrieval, memory writes, and image access unless each has a documented need.^{[3], [6]}
✓If one runtime must invoke another, scope identity and resource policies to the approved runtime and endpoint; test that unrelated runtimes are denied.^[6]
✓Enable MMDSv2 as required by AWS, while treating role-credential access from code inside the microVM as a separate authorization boundary.^{[5], [4], [1]}
✓Reduce the set of destinations model-influenced tools may contact to what the workload requires; treat this as egress-risk reduction, not as proof that in-VM code cannot access MMDS.^[5]
✓Give public agents roles with no more privilege than their callers; test effective permissions with IAM Access Analyzer and negative authorization cases.^{[5], [6]}

Sources

← AI Security Hub Directory →