AWS Bedrock Agent IAM Role Scoping and Least Privilege

AWS Bedrock agent IAM role scoping limits what an autonomous system can do. Because agents exercise permissions at machine speed along paths shaped by prompts, least privilege requires continuous work, including isolated roles, layered policy controls, and ongoing permission review.

Why Bedrock agents are a different kind of IAM principal

A Bedrock agent does not follow a fixed code path the way a conventional Lambda function does. A prompt shapes its execution path at runtime, making the range of IAM actions it may invoke in a session non-deterministic. The agent still acts through permissions granted to its role, but the developer has not prescribed every step it will take. That distinction makes the role a boundary around possible behavior.

A person must deliberately perform actions and may never exercise a stale permission, while an agent can exercise its available permissions autonomously and at machine speed. The absence of manual effort changes the risk of excess access. For an agent, an unused permission is not safely dormant simply because no production workflow has needed it yet.

The four IAM role layers a Bedrock agent deployment actually involves

AWS describes four permission layers that work together in a Bedrock agent deployment, starting with the application role. This role needs bedrock:InvokeAgent, scoped for least privilege to a specific agent-alias ARN. A broader scope can still work while giving more access than intended, but a wrong scope can block invocation altogether.

The Bedrock Agent service role governs the next layer, including which foundation models the agent may invoke and which Knowledge Bases it may query. Its bedrock:InvokeModel permission belongs on approved model ARNs, and bedrock:Retrieve belongs on specific Knowledge Base ARNs. The separate Knowledge Base service role grants read access to the S3 data source bucket and the vector store, such as OpenSearch Serverless. It does not need general authority over the services that hold the data.

The fourth layer has both the Lambda execution role and the Lambda resource-based policy. The execution role controls which downstream services an action group function can reach, while the resource-based policy controls who may invoke it. Each role also needs a trust policy limiting who can assume it, because an overly permissive trust relationship widens access to everything downstream. Administration adds another route through iam:PassRole, which can let an operator or attacker assign an agent a more permissive role than intended. Least privilege is therefore a property of the whole chain.

How testing-era permissions fossilize into production authority

That chain is often assembled while teams are trying to make an agent work. Testing adds access to models, functions, services, and Knowledge Bases, but the move into production does not automatically subtract what the final workflow no longer needs. Standing roles can keep permissions added during development even when no verified production call needs them. Build-time convenience hardens into permanent authority through identity fossilization.

The signs are concrete, including managed policies copied wholesale from development, wildcard resources where specific ARNs are available, and permissions no one can connect to an observed production invocation. These are what a process leaves behind when it rewards getting access to work but does not require that access to be removed later. The corrective rule is equally concrete. An action that cannot be tied to a confirmed runtime call should be treated as excess capability and removed before live traffic reaches the agent.

Infrastructure-as-code drift can also leave permissions behind. Environment cloning, manual cleanup, or a failed IaC apply can leave a role attached to a non-existent agent resource. No one owns that orphaned permission set, and no work calls for it. If the resulting outage prompts a rushed replacement role, incident response can recreate the same problem with broader permissions. Speed solves the immediate interruption while leaving the next boundary less precise.

What over-permissioned defaults look like in practice — the AgentCore disclosures

Unit 42 documented a concrete version of this risk in the AgentCore starter toolkit. Its research found that automatically generated IAM roles gave broad privileges across the AWS account, beyond the access needed for individual agent resources. Unit 42 named the resulting attack vector “Agent God Mode”. An adversary who compromised one agent with those roles could escalate privileges and compromise every other AgentCore agent within the account. The reported capabilities included exfiltrating proprietary ECR images, accessing other agents’ memories, invoking all code interpreters, and extracting sensitive data.

AWS characterized the behavior as documented and expected. AWS also recommended that customers grant execution roles only the permissions their agents need. The researchers countered that documentation is not a sufficient control when default tooling makes over-permissioning the easiest path. These positions differ over responsibility and classification, but both leave the customer with a configuration that requires deliberate narrowing. A warning can explain a boundary without actually building one.

Defaults optimized for getting started can grant more authority than a production agent requires. If that authority survives deployment, compromising one agent can become an account-wide problem. Avoiding that outcome requires operational work on the generated roles.

Six administrative permissions that let an attacker rewrite agent behavior without touching code

Runtime permissions define what an agent can reach, but administrative permissions define what it can become. Six actions deserve particular attention because they can change behavior without a new code deployment. UpdateAgent modifies the agent’s core configuration. UpdatePrompt modifies a prompt in the prompt management library that an agent may use.

The remaining actions reach other parts of the same control surface. UpdateGuardrail can weaken or remove content filtering, while DeleteGuardrail eliminates a guardrail entirely. CreateAgentActionGroup adds new capabilities during the agent’s lifecycle. UpdateFlow changes a Bedrock Flow’s node graph and connections, which can include agents as nodes. These are not merely maintenance conveniences when held by the wrong identity.

This is also why Bedrock Guardrails cannot substitute for IAM scoping. Guardrails govern conversational behavior, while IAM controls which AWS resources the execution role can actually reach. If an attacker holds bedrock:UpdateGuardrail or bedrock:DeleteGuardrail, the guardrail layer can collapse regardless of how carefully it was configured. Administrative IAM permissions therefore protect the controls themselves. They belong with a tightly bounded set of platform administrators, with any inclusion in agent-assumed roles or developer-held production roles requiring justification.

The confused deputy problem in multi-agent architectures

Even a narrowly scoped role can be part of an unsafe trust relationship. A less-privileged actor can manipulate a more-privileged entity into acting on its behalf as a confused deputy. In AWS cross-service calls, an unauthorized actor can exploit that relationship to reach another customer’s resources through a service that has access.

AWS documents condition-key binding as the mitigation for this cross-service risk. Resource policies should use aws:SourceArn and aws:SourceAccount to bind permission to the specific Bedrock resource making the call. Multi-agent designs add a related concern because a supervisor can reach sub-agents through its trust chain. A prompt injection into the supervisor can direct sub-agents to exercise their own permissions in unintended ways. Scoping each role cannot, on its own, show whether an instruction sent through that chain is legitimate.

When an agent calls a downstream API under its own service identity rather than the user’s delegated credentials, downstream systems must trust the agent, and the audit trail attributes the call to the agent. Forwarding the user’s token unchanged creates a different confused deputy problem for downstream tools. Amazon Bedrock AgentCore’s integration guide addresses this through non-static, per-user delegated credentials and RFC 8693 on-behalf-of token exchange via AgentCore Identity. This keeps the agent’s identity distinct from the user’s identity at each downstream call.

The logging gap that makes policy violations invisible after the fact

A sound permission design still needs evidence of how it behaves. Model invocation logging is disabled by default in Bedrock, and there is no single organization-wide switch to enable it. Each AWS account must be configured in each region where Bedrock is used. The control exists on paper, but part of its evidence trail does not.

LLMjacking makes that gap more than an administrative inconvenience. These attacks use stolen AWS credentials to invoke foundation models at the victim’s expense. Attackers often check whether logging is enabled before they carry out model-related operations and take disabled logging as a sign to go ahead. The missing record thus serves the attacker both before and after the activity. It helps identify a quieter target and limits later reconstruction.

A new Lambda attachment, modified action group, or guardrail change alters the context in which its permissions operate, and missing invocation logs limit visibility into the resulting behavior. An investigation into human access may use unusual login times or unfamiliar source IPs as clues, but an agent can misuse the authority of a role it legitimately holds. Machine-speed activity does not have to look like an unfamiliar person signing in. Logging must therefore be turned on and checked in every active account-region pair during deployment, before it is needed for an investigation.

Building least privilege as an operational practice, not a launch checklist

The foundation is one dedicated IAM role per agent. When agents share a role, a permission added for one workflow silently gives every agent with that role the same access. Isolation makes it possible to tie each permission to the agent that needs it. Runtime policies should name only the specific model ARN, Knowledge Base ARN, Lambda function ARN, guardrail identifier, schema bucket, and KMS key used in verified production calls. Hypothetical future needs and discarded development paths do not belong in that scope.

AWS Organizations Service Control Policies support full IAM language and can allowlist Bedrock API actions within approved accounts and regions, regardless of broader permissions in a role policy. IAM Access Analyzer validates policies against more than a hundred policy checks and should act as a pre-production gate for overly broad access. These controls address different failure modes.

After deployment, a formal permission review should take place each time an action group, Knowledge Base attachment, or Lambda is added to keep authority tied to the current workflow. The absence of dangerous administrative permissions from agent-assumed and unjustified developer-held production roles should also be verifiable and audited. Turning on model invocation logging creates the record needed to investigate how permissions are used.

Logs, however, are not the final answer to who watches the agents. Real-time visibility into anomalous API calls, policy violations, and unexpected permission use addresses behavior as it happens. Purpose-built agent governance platforms are designed to close this runtime gap by complementing IAM boundaries. Least privilege for agents is not a state achieved at launch but a discipline maintained through every change.