AIDEFEND in Action AIA-0101 Validated Research Published: Oct 23, 2026

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.

Prompt InjectionCredential ExposureTool AuthorizationAI Infrastructure
5 applicable AIDEFEND defenses
Source: AgentCorruption: How A Single Prompt Collapsed The Entire Cloud Security Model 
Authors: Tamir Ishay Sharbat and Lana Salameh
Original article: Oct 8, 2026

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)

AID-I-001.004
Sandbox Network Egress Restrictions
High
Where the customer controls the effective AgentCore VPC egress path, enforce outbound denial outside the runtime and allow only task-required destinations. Verify all approved paths plus a live denied canary, redirects, raw IP, proxy bypass and DNS behavior. This can block the unapproved C2 page and later HTTP exfiltration, while it does not remove poisoned memory or necessarily block the local metadata service. The Kubernetes example requires a supported AWS network implementation, not merely a copied YAML policy.
AID-H-019.001
URL Normalization & Allowlist Filtering
Medium
Replace arbitrary model-directed HTTP with the guidance's sole safe-fetch path: validate resolved addresses and redirects, deny link-local/private metadata targets, and keep the policy and connector outside agent control. On AgentCore this requires a customer-owned HTTP adapter and removal or confinement of alternate shell/raw-network tools. The published example is not an AgentCore MMDS firewall, and IMDSv2 alone does not stop a tool able to issue token PUT requests with headers.
AID-I-004.004
Transactional Promotion Gates (Quarantine -> Trusted)
Medium
Stage untrusted conversation-derived memory in a separate quarantine store and permit only an independently authorized controlled promoter to populate the trusted retrieval store. Bind promotion to exact content, provenance and a validated write-eligibility decision, with readback and retry-safe state changes. The compromised runtime role must not directly write or retrieve trusted records via an alternate AWS API. AgentCore's built-in extraction is not this gate; a custom memory pipeline and restrictive IAM are prerequisites.
AID-D-003.006
Memory Write-Abuse & Drift Monitoring
Medium
Observe committed memory writes through a protected adapter that verifies tenant, authenticated actor, namespace, version and value digest from durable receipts. Alert on cross-namespace writes, bursts and repeated payloads, with persistent idempotent counters. Native CloudTrail events alone do not supply the complete signed commit receipt or semantic detector. Direct AWS API writes must be reconciled with the adapter ledger; otherwise monitoring coverage remains incomplete. This detects abuse patterns and does not prevent the first poisoned event.
AID-E-001.002
Issued Token, Authentication Session & Lease Revocation
Medium
Contain the exported STS session using AWS-native enforcement, such as a verified role-session revocation cutoff based on aws:TokenIssueTime, and probe the old session against each relevant API. Separately stop the compromised runtime from refreshing credentials and narrow its role permissions. The guidance's generic verifier protocol needs an AWS adapter; rotating an unrelated secret or editing memory does not invalidate a live STS session. Enforcement and propagation must be verified before declaring that session unusable.

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

AIDEFEND  points to safe fetch, quarantine before trusted memory promotion, memory-write abuse monitoring, independent egress enforcement and issued-session containment. The deployable foundation is exact IAM scope: the custom memory and fetch controls only work if the stolen role cannot bypass them through direct APIs. Persistent C2 additionally requires both memory extraction and later retrieval, which must be tested as separate boundaries.

Last updated: