AIDEFEND in Action AIA-0092 Validated Research Published: Oct 1, 2026

AgentCore Starter-Toolkit IAM Exposes Other Agents' Memory

Unit 42 demonstrated that starter-toolkit-created AgentCore execution roles used broad resource wildcards for ECR, AgentCore Memory, runtime, and Code Interpreter actions. After an initial agent is compromised, its role can pull another agent's image, recover a MemoryID from the image, and read that agent's memory records; Unit 42 states the same permission shape would also allow poisoning, which the test did not demonstrate. AWS clarified that generated roles are for development and testing, not production.

Permission BypassIdentity & AccessCloud IAMAgentic AI

7 applicable AIDEFEND defenses

Source: Cracks in the Bedrock: Agent God Mode

Author: Ori Hadad

Original article: Apr 8, 2026

Threat Analysis

The starter toolkit gave an agent execution role broad resource patterns. Unit 42 showed how control of one agent could be converted into access to a different agent's ECR image, then to its MemoryID and memory records. The MemoryID is a locator; the real failure is cross-resource authorization.

The research assumes control of one AgentCore agent deployed with the toolkit's broad execution role; it does not claim to have discovered a particular initial intrusion.
Wildcard ECR permissions allow the compromised agent's role to authenticate and pull a target agent's container image in the account.
Static inspection of the pulled image exposes a BEDROCK_AGENTCORE_MEMORY_ID value for the target agent.
Wildcard AgentCore Memory permissions let the compromised agent use the recovered ID to read another agent's memory records. The quoted role grants read actions; Unit 42 describes poisoning as a possible extension that the test did not demonstrate.

This study assumes an initial compromised agent. It also identifies broad Code Interpreter and InvokeAgentRuntime permissions, but the SecureFlow follows the tested ECR-to-memory path. AWS says automatically created roles are for development and testing.

Applicable AIDEFEND Defenses (7)

AID-I-002.001

Internal AI Network Segmentation

High

Keep toolkit test deployments in separate non-production accounts containing no production images or memories. Deny non-production principals in production ECR/Memory resource policies and enforce signed, reviewed organizational policies covering direct cross-account API access, role assumption and network/relay paths. Memory supports direct cross-account reads with a full resource ARN when identity and resource policies allow them; a wildcard role is not inherently confined to its own account. Verify denial with both direct Memory/ECR probes and attempted production-role assumption. Separation works through effective policies, not the account label.

AID-M-005.001

Secure Configuration Template Development

Medium

Replace toolkit-created production roles with reviewed IaC templates that bind resource-scoped ECR image and AgentCore Memory/runtime/interpreter operations to the exact approved ARNs. MemoryID alone is not an IAM Resource ARN. Review actions separately: ecr:GetAuthorizationToken legitimately uses Resource *, while repository image access must remain scoped. Encode necessary non-resource-scoped exceptions explicitly rather than forbid all wildcards or grant wildcard data access. The template is design evidence; controlled provisioning, tested release gates and effective-policy readback enforce its use.

AID-H-003.005

Infrastructure as Code (IaC) Security Scanning for AI Systems

Medium

Define production execution roles in reviewed IaC, disable toolkit auto-creation, and scan the complete source and rendered policy population before merge. Add and test a custom Checkov policy for wildcard ECR and AgentCore resource patterns and each relevant action; do not assume built-in checks cover every ARN variation. Independently read back the deployed effective IAM policies. Scanning a template does not constrain a role created outside this path.

AID-M-005.002

Policy-as-Code Configuration Baselines & Posture Release Gates

Medium

Before deployment, run a tested policy-as-code gate over the complete role policy population, rejecting wildcard resource grants for ECR image access and AgentCore operations that support resource ARNs. Treat legitimate non-resource-scoped actions such as ecr:GetAuthorizationToken as explicitly reviewed exceptions, not a blanket wildcard pass. The published Rego example targets security groups; this IAM policy needs custom rules and is not that published example. Deny unmeasured policies, disable alternate role-creation paths, and independently probe the deployed role against other agents' resources.

AID-D-011.004

Non-Human Identity & Delegated Token Abuse Detection

Medium

Maintain an approved role-to-ECR-repository and role-to-MemoryID inventory, and correlate role sessions with the actual ECR and AgentCore Memory API events. Explicitly enable and verify CloudTrail data-event coverage for RetrieveMemoryRecords and any other Memory data-plane calls; management events alone do not establish that a cross-agent read was observed. Alert only when a recorded role/resource pair violates its approved binding.

AID-E-001.003

AI Agent & Workload Principal and Issuance Disablement

Medium

Disable the compromised runtime principal or its trusted issuance binding and verify it can obtain no fresh role credentials. This stops new issuance; it does not invalidate already-issued STS sessions. Handle those sessions separately with E-001.002 and provider-side explicit denial, then probe using the old credentials after IAM propagation. Redeployment or unlinking a role alone is not proof that cross-agent access ended.

AID-E-001.002

Issued Token, Authentication Session & Lease Revocation

Medium

For already-issued AWS role sessions, apply the provider-native session-permission revocation policy using aws:TokenIssueTime or a correctly scoped explicit deny, and verify that old credentials fail at every applicable ECR/Memory service boundary after propagation. This is AWS-native permission revocation, not G002's published JWT denylist implementation; it is a bounded alternative with the same pre-expiry denial purpose. Check resource-policy and role-assumption paths, prevent fresh issuance separately, and keep closure unresolved until independent old-session probes are rejected.

What Defenders Should Do Now

Replace starter-toolkit-generated production roles with workload-specific IAM policies scoped to exact ECR repositories, AgentCore Memory resources, runtimes and interpreters.
Test the negative case: compromise one test agent identity and confirm it cannot pull another agent's image, read its memory or invoke its runtime.
Keep MemoryID values out of unnecessary images, but treat that as exposure reduction; every memory read and write still needs independent resource authorization.

1 additional consideration

Evidence and deployment boundary

The initial agent compromise is a prerequisite, not a disclosed intrusion path. The control that decides this case is the resource scope of the AWS execution-role IAM policy itself; AIDEFEND places that control at authoring and CI time (a reviewed role template, IaC scanning and a policy-as-code release gate), so define the role there and restrict ECR and Memory calls to the agent's own resources rather than relying on an application-layer memory gate a direct API call never passes through.

Recommendation: Replace starter-toolkit-generated production roles with workload-specific IAM policies scoped to exact ECR repositories, AgentCore Memory resources, runtimes and interpreters.

Conclusion

AIDEFEND points teams to a reviewed role template, custom IAM policy checks and independent readback of the deployed role. Those controls keep one compromised AgentCore agent from using its execution role to read another agent's image or memory; hiding the MemoryID cannot substitute for resource-scoped AWS authorization.

Last updated: Oct 1, 2026