AWS Bedrock ‘Agent God Mode’: When Default IAM Gives Every Agent Access to Every Other Agent’s Memory

Unit 42 found AWS Bedrock AgentCore's starter toolkit auto-generates IAM roles so broad that any agent can read — and poison — every other agent's memory. The fix isn't a patch; it's least-privilege identity.

Key Findings

  • Unit 42 (Palo Alto Networks) found that AWS Bedrock AgentCore’s starter toolkit auto-generates IAM roles that grant privileges broadly across the entire AWS account rather than being scoped to individual resources.
  • A wildcard memory policy lets any agent read and poison every other agent’s memory; wildcard policies also expose code interpreters, all ECR container images, and the ability to invoke any other agent.
  • AWS’s own response is that the auto-created roles “should never be used in a production system” — making this an authorization-design failure, not a single patchable bug.

On April 8, 2026, Unit 42 researcher Ori Hadad published findings under a title that captures the failure mode exactly: “Cracks in the Bedrock: Agent God Mode.” The subject is AWS Bedrock AgentCore — Amazon’s platform for building and running AI agents — and specifically its starter toolkit, the convenience layer meant to get developers from zero to a running agent quickly.

The convenience is the problem. To spare developers the friction of writing IAM policies by hand, the toolkit auto-creates them. The roles it generates are not scoped to the agent that needs them. They are scoped to the whole account.

The starter toolkit’s auto-create logic generates identity and access management (IAM) roles that grant privileges broadly across the AWS account, rather than being scoped to individual resources.

— Ori Hadad, Unit 42

What “god mode” actually grants

The damage lives in the wildcards. Each auto-generated policy uses * where a resource ARN should be, turning a per-agent permission into an account-wide one. Hadad walks through four of them, and each maps to a distinct way an agent can reach past its own boundary.

  • Wildcard memory (arn:aws:bedrock-agentcore:*:memory/*) — any agent can read and poison every other agent’s memory.
  • Wildcard code interpreter — an agent can invoke any code interpreter in the account.
  • Wildcard ECR (arn:aws:ecr:*:repository/*) — exfiltrate every container image, including source and proprietary algorithms.
  • Wildcard runtime invocation (arn:aws:bedrock-agentcore:*:runtime/*) — any agent can trigger any other agent.

Memory poisoning is the one that should keep teams up at night. An agent’s memory is the context it trusts — the place it stores what it has learned and what it has been told. If any agent in the account can write to any other agent’s memory, then compromising one low-value agent becomes a foothold to steer every agent that shares the account, silently, without touching a model or a prompt.

Not a bug — a default

There is no CVE to chase here, and that is the point. AWS’s own security team, through Unit 42’s coordinated disclosure, framed the behavior as working as designed but unfit for production.

The IAM roles generated by the auto-create feature provide a flat permission structure that does not align with the principle of least privilege, and should never be used in a production system.

— AWS Security Team, via Unit 42 coordinated disclosure

4
Wildcard policies behind the over-broad access
*:*
Account-wide scope instead of per-resource
0
Patches — the fix is least-privilege design

The SecureW2 read

Agent God Mode is an authorization failure: standing, over-broad privilege handed to every agent by default, instead of scoped, per-agent identity. It is the exact failure the IETF’s AIMS draft is written to prevent — AIMS prescribes one bound identifier per agent and authorization scoped to what that agent may do. Pair the two stories and the lesson is plain: the standard already describes the fix. AgentCore’s starter toolkit shipped the antipattern instead.

Quotes are drawn from Unit 42’s “Cracks in the Bedrock: Agent God Mode” (Ori Hadad, April 8, 2026) and AWS’s disclosure response cited therein. Used here in a design mockup.