AWS Bedrock agent permissions and the least-privilege gap

At a glance

What this is: AWS Bedrock agents can inherit standing IAM roles that retain testing-time permissions into production, creating a least-privilege gap at runtime.

Why it matters: IAM and cloud security teams need to treat Bedrock agent authorisation as a live governance problem because dynamic tool use can exercise excess permissions without human approval.

By the numbers:

• Sonrai Security says over 90% of cloud permissions across human and non-human identities are not used.

Context

A Bedrock agent execution role is meant to define what the agent can reach at runtime, but in practice that role often reflects the build process rather than the live operating model. When permissions accumulate during testing and survive into production, the identity boundary no longer matches the workload’s actual function.

This is an IAM governance problem as much as an AI problem. The article describes agents chaining API calls, invoking Lambda functions through action groups, and querying knowledge bases under a standing role, which means privilege review must track the role’s real runtime behaviour, not just its deployment state.

The pattern is familiar to anyone managing non-human identities: once an operational role becomes the default identity for a system, access tends to outlive the need that created it. For Bedrock agents, that gap is widened by model-driven action selection at runtime.

Key questions

Q: What breaks when Bedrock agents reuse shared IAM roles?

A: Shared roles blur accountability, make least-privilege scoping impossible, and allow one workflow change to affect multiple agents at once. They also hide privilege creep when the agent is repurposed for a new task. Shared execution roles are a governance shortcut that usually becomes an audit and containment problem later.

Q: Why do overprivileged Bedrock agent roles create more risk than standard workload roles?

A: Because the agent does not follow a fixed code path. It can chain actions dynamically based on model output, so any excess permission becomes reachable at runtime without human approval. That turns the permission surface into the attack surface.

Q: What are the signs that a Bedrock agent role is failing least privilege?

A: The clearest signals are managed policies carried over from development, broad wildcards where specific ARNs should exist, and permissions that no one can tie to a verified production call. If the role keeps growing with each new integration, least privilege is already eroding.

Q: How should teams govern Bedrock agents once they go live?

A: Treat every new action group, knowledge source, or Lambda attachment as a formal permission review, and pair IAM scoping with separate guardrail governance. That keeps model behaviour controls distinct from resource authorisation and prevents one control from being mistaken for the other.

Technical breakdown

Why Bedrock agent roles drift after testing

AWS Bedrock agents require an execution role at creation, and teams often expand that role during testing to get past AccessDenied errors or to wire in new capabilities. The problem is not just excess permissions, but the way those permissions become attached to a standing non-human identity that then runs automatically in production. In that state, the role is no longer a temporary build artefact. It becomes the agent’s operational authority, which makes every permission addition a lasting change to the attack surface.

Practical implication: treat every change to an agent execution role as a production authorisation decision, not a development convenience.

Why guardrails do not solve IAM scope

Bedrock guardrails and IAM permissions operate at different layers. Guardrails constrain model inputs and outputs, such as topics, content filters, or sensitive information patterns. IAM permissions control what AWS resources and actions the agent can invoke. A tight guardrail cannot stop an overprivileged role from reaching unrelated Lambda functions or data sources, and a narrow IAM policy cannot stop the model from producing undesirable content. Security depends on both controls being correct for their own domain.

Practical implication: review model-safety controls and resource permissions separately, because one does not compensate for the other.

Why dynamic tool use changes the permission surface

Traditional workloads follow predefined code paths, so developers can usually predict which calls are possible. Bedrock agents chain API calls dynamically based on model output, which makes the permission surface closer to a live decision tree than a static application role. If the agent can choose from multiple attached services, Lambda functions, or knowledge bases, any excess permission is a reachable capability rather than dead weight. That is why least privilege has to be defined against runtime behaviour, not against the broadest testing scenario.

Practical implication: scope each agent to the exact runtime ARNs it can justify and remove anything the agent does not demonstrably use.

Threat narrative

Attacker objective: The objective is to exploit the agent’s standing permissions to reach data, functions, or services beyond the intended runtime scope.

1. Entry occurs when a Bedrock agent is deployed with the same IAM role it used during testing, preserving permissions that were added to unblock development.
2. Credential access is not the issue here; instead, the standing role provides direct authorisation to services, Lambda functions, and knowledge bases that the agent can invoke automatically.
3. Escalation happens when the agent chains those permissions dynamically, so a single prompt or workflow can reach far more resources than the original build intent suggested.
4. Impact is the expansion of blast radius in production, where excess permissions remain live and can be exercised without a human approval step.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing execution roles create identity fossilisation: When a Bedrock agent keeps the same IAM role it used during development, the role stops reflecting operational reality and starts reflecting historical convenience. Permissions added to debug a sprint become the agent’s permanent authority in production. The practitioner implication is that role design must be tied to runtime use, not build history.

Least privilege is defined too early if the actor can choose actions at runtime: Static scoping assumes the full access pattern is knowable at provisioning time. Bedrock agents break that assumption because model output determines which services, functions, or knowledge bases get used next. The implication is that privilege review has to move from launch-time approval to ongoing runtime validation.

Guardrail separation is now a governance requirement, not a nuance: Model guardrails, IAM policy scope, and resource-based permissions answer different questions and fail in different ways. Teams that collapse them into one security story will miss the control gap that actually enables overreach. Practitioners need to govern the permission plane and the model-behaviour plane as separate risk surfaces.

Runtime authorisation for AI agents should be treated as a distinct non-human identity pattern: A Bedrock agent is not just another workload because it chains tool use dynamically and can activate permissions in ways a deterministic service never would. That makes the identity problem closer to governed delegation than to ordinary application access. The implication is that existing workload-role assumptions need to be revalidated for agentic execution.

Identity blast radius is the right concept for Bedrock governance: The article shows that the meaningful control question is not whether an agent has access, but how far that access can propagate through attached services and functions. Once a role is allowed to invoke multiple actions, the blast radius becomes the real security unit. Practitioners should measure and reduce that radius before production traffic begins.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: AI Agent Authorisation Guide

What this signals

Identity fossilisation: Bedrock roles often outlive the testing decisions that created them, so the operational identity no longer matches the service’s actual runtime need. That is a governance failure, not a deployment quirk, because permissions that persist by habit become reachable capability in production.

Agentic runtime requires permission-plane governance: When an AI system can choose actions dynamically, least privilege cannot be treated as a one-time launch control. Access review, authorisation scoping, and resource-based policy checks have to follow the agent’s live execution pattern, or the control will be obsolete on day one.

For practitioners

• Replace development-time managed policies with scoped runtime policies Build a custom policy for the Bedrock agent execution role that names only the specific model ARN, knowledge base, Lambda functions, schema bucket, guardrail, and KMS key the agent actually uses.
• Review each attached role independently Assess the knowledge base service role, each Lambda execution role, and the Lambda resource-based policy separately so one permissive attachment does not mask another.
• Remove permissions that lack a verified runtime call Treat any action that cannot be mapped to an observed production invocation as excess capability and remove it before the agent handles live traffic.
• Apply organisational ceilings with SCPs Use service control policies at the account or OU level to prevent disallowed Bedrock-related services or actions from ever appearing in production roles.
• Build permission review into every agent change Treat new action groups, new integrations, and new knowledge sources as triggers for a fresh authorisation review rather than a default approval.

Key takeaways

• Bedrock agent permissions can drift from build-time convenience into production authority, which leaves standing access that was never meant to persist.
• The article’s core evidence is that agents may keep inherited IAM roles while Sonrai Security says over 90% of cloud permissions across human and non-human identities are unused.
• The practical fix is to scope agent roles to verified runtime ARNs, review each attached role separately, and enforce organisational ceilings before live traffic starts.

Key terms

• Bedrock Agent Execution Role: The IAM role that an AWS Bedrock agent assumes to call services, functions, and knowledge bases at runtime. In practice, this role becomes the agent’s operational identity, so any excess permission attached to it can be exercised automatically without a human in the loop.
• Identity Fossilisation: A control failure where an identity keeps permissions that reflect historical build or testing conditions rather than current operational need. For AI agents and other NHIs, this means the role or token stays live long after the rationale for each permission has disappeared.
• Permission surface: Permission surface is the total set of content and systems that an identity can reach, whether or not that access is regularly used. In AI-enabled environments, a large permission surface becomes a direct exposure surface because search and summarisation can traverse it quickly.
• Guardrail Separation: The discipline of treating model-behaviour controls and resource authorisation controls as separate layers. Guardrails can limit outputs or topics, but they do not constrain AWS IAM scope, so both layers must be governed independently to avoid false confidence.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.