AgentCorruption: A Stolen Execution Role Turns Memory into Persistent C2
Zenity tested an AWS Bedrock AgentCore deployment, a managed environment for running AI agents, with a network-capable agent and a broad execution role. The agent relayed temporary role credentials from its metadata endpoint. Off-platform API calls then reached other memories and agents. The distinctive persistence path wrote short-term conversation events that configured extraction strategies could turn into long-term records; later retrieval directed the agent to a mutable command page. The reach was demonstrated within an account and region, not as a microVM escape or automatic cross-account compromise. The researchers observed major default-role restrictions on September 29; existing deployed roles still require independent inspection.
Threat Analysis
The initial test used Strands, an AWS SDK for constructing agents, with an explicitly enabled http_request tool. The agent fetched 169.254.169.254 and relayed temporary execution-role credentials. The researchers then used those credentials outside AgentCore. Once exported, the role could call AWS APIs directly; a model prompt filter or tool policy in the original agent was no longer on that path.
The role's broad account-and-region permissions exposed several distinct routes. CloudWatch log-group names disclosed runtime and memory identifiers. Memory listing APIs supplied actor and session identifiers, and ListEvents returned selected conversations. Other-agent invocation plus that target's file_read tool exposed billing.json in a controlled demonstration. ECR image access disclosed source-code credential-provider names, which could be used with broad Secrets Manager GetSecretValue permissions. These capabilities depend on the actual role and target tools; they are not universal AgentCore privileges.
The new persistence result is more specific than generic cross-agent access. CreateEvent wrote a short-term conversation event. The target memory's configured extraction strategies could preserve its instruction in long-term records. Only if extraction retained the text and later retrieval selected it did the instruction influence another interaction. The demonstrated directive asked the agent to consult a mutable researcher-controlled page before answering, enabling ongoing instructions and conversation exfiltration without rewriting memory each time.
The overview records an important remediation milestone: on September 29, researchers observed removal of broad cross-agent invocation, conversation-reading and Secrets Manager permissions from the default execution role. That improves the default template; it does not prove previously deployed customer roles were replaced. The graph describes the tested broad-role deployment, not an assertion that every current default remains vulnerable.
Zenity's introductory notes say issues were addressed, while the included AWS statement describes access to the workload's own credentials as expected and recommends least privilege. The disclosure timeline says new deployments used IMDSv2 after February 14. That is not proof that every old deployment was remediated, or that a shell/HTTP tool able to request metadata tokens is contained. AWS documentation likewise states that CLI-generated development/test roles are unsuitable for production, and that cross-account access requires both identity-side and target-resource permission. The evidence does not establish a microVM escape or unconditional cross-account compromise.
Applicable AIDEFEND Defenses (5)
What Defenders Should Do Now
- Replace broad development/test execution roles with reviewed permissions for exact runtime, memory, ECR and secret ARNs. From the actual workload role, test denial against another agent's memory, image, runtime and credential provider. Enforce backend session-to-user mappings separately.
- Remove arbitrary HTTP and shell capabilities where the task does not need them. If web access is necessary, make a validated safe-fetch adapter the only reachable route and test metadata addresses, redirects and alternate network tools.
- Keep raw conversation events separate from trusted memory. Build a controlled quarantine and promotion path, restrict the writer role, and prevent direct AWS API paths from bypassing the trusted reader. Recheck retained facts rather than trusting successful extraction.
- Restrict actual runtime egress to approved services where customer-controlled VPC routing supports enforcement. Test raw IP, redirect, proxy and DNS bypasses; do not mistake external network policy for local metadata isolation.
- After role-credential exposure, stop issuance from the compromised runtime, revoke or deny already issued sessions, investigate memory and secret reads/writes, remove poisoned records and their derived summaries, and verify clean retrieval before restoring service.
Conclusion
Last updated: