AWS Bedrock agent permissions and the least-privilege gap

At a glance

What this is: This is an analysis of AWS Bedrock agent permission scope, showing that production agents often run with standing IAM roles and over-privileged access inherited from development.

Why it matters: It matters because AI agents can chain tool calls dynamically, so IAM teams must treat runtime permissions as the real attack surface for non-human identities.

👉 Read Sonrai Security’s analysis of AWS Bedrock agent permissions before go-live

Context

AWS Bedrock agents are non-human identities, and in practice they often inherit more access than a human operator would ever receive. The core governance gap is simple: permissions granted during build and testing are left in place after go-live, even though the agent’s runtime behavior is not fully predictable.

For IAM and NHI practitioners, that creates a mismatch between role design and real execution. The article’s central concern is not whether Bedrock can work, but whether teams can constrain the agent to the exact services, functions, and data paths it genuinely needs. That starting position is common, not unusual, in cloud environments that move quickly.

Key questions

Q: How should security teams implement least privilege for AI agents in AWS?

A: Start with the agent’s real runtime working set, then scope the execution role to only the exact model, knowledge base, Lambda functions, storage paths, and encryption keys it uses. Remove broad development policies, review related service roles separately, and re-certify access whenever the agent’s tools or integrations change.

Q: Why do AI agents complicate IAM governance more than traditional workloads?

A: AI agents can choose among authorized actions dynamically, so the role’s permission set becomes the effective attack surface. A traditional workload follows code paths you can inspect, but an agent can combine tools in new ways without a human approving each step. That makes over-scoped access far more dangerous.

Q: What breaks when Bedrock agents keep broad testing permissions in production?

A: The agent can reach services, data sources, or cross-account functions that were never meant for live use. Broad permissions also mask which actions are actually required, so teams lose the ability to distinguish necessity from convenience. In practice, over-permissioned roles turn release history into standing risk.

Q: How do security teams know if AI agent permissions are actually under control?

A: Look for a one-to-one mapping between runtime calls and allowed actions, regular re-certification after each integration change, and no unmanaged managed policies attached from testing. If the role still contains wildcard access, or if teams cannot explain each entitlement, the control is not working.

Technical breakdown

Why Bedrock agent roles drift into standing privilege

Bedrock agents require an execution role at creation, which makes the initial permission decision easy to overextend. As teams attach knowledge bases, Lambda action groups, and supporting storage, the role accumulates permissions that reflect project history rather than runtime need. When testing breaks, broad managed policies are often added to unblock deployment, then forgotten. The result is a standing identity with a permission set that no longer matches the agent’s actual purpose. This is a classic NHI lifecycle problem: entitlements expand during build, but no one re-baselines them before production.

Practical implication: Review the agent role as a production identity, not a dev artifact, and remove every permission not tied to a verified runtime call.

How agent tool use changes the IAM risk model

Traditional workloads follow predetermined code paths, so their blast radius is bounded by developer logic. An AI agent can chain calls dynamically based on model output, which means permission scope and execution scope are tightly coupled. If the role can invoke a Lambda function, query a knowledge base, or reach a shared S3 location, the agent can exercise that access without human approval at each step. This is why prompt manipulation and tool misuse matter: the model is not the control plane, but it can drive the control plane through authorized actions.

Practical implication: Map every tool, data source, and downstream API call to a specific entitlement before allowing the agent into production.

Why guardrails do not solve permission overreach

Guardrails and IAM solve different problems. Guardrails filter inputs and outputs, while IAM governs what AWS resources the role can touch. Teams often treat guardrails as if they were a full security boundary, but they do nothing to narrow a role that can already invoke excessive services. Likewise, CloudTrail can show what happened, but it does not by itself establish least privilege. The practical issue is not visibility alone. It is whether the role, the action groups, and any related Lambda permissions are all constrained to the smallest viable runtime surface.

Practical implication: Use guardrails as content control, then enforce custom IAM policies, scoped resource policies, and change reviews as the actual access boundary.

Threat narrative

Attacker objective: The objective is to turn the agent’s trusted runtime role into a path for unintended access, service invocation, or data exposure.

1. Entry occurs when an overprivileged Bedrock agent inherits a broad execution role from development or troubleshooting.
2. Escalation happens when the agent can chain authorized API calls through action groups, Lambda functions, or connected knowledge bases beyond intended scope.
3. Impact follows when the model exercises standing privilege against services, data sources, or cross-account functions that were never meant to be production reachable.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing privilege is becoming the default failure mode for AI agents. The Sonrai analysis shows the same pattern security teams have seen for years with service accounts and workload roles, only now the blast radius is larger because the agent decides which authorized action to take next. This is a lifecycle problem, not a feature problem. Practitioners should assume every AI agent role will drift unless it is continuously re-baselined.

Ephemeral behavior does not equal ephemeral privilege. An AI agent may act in short-lived bursts, but the role behind it often persists indefinitely with the permissions it picked up during testing. That creates identity blast radius: a temporary task executor carrying permanent access. The right governance model is to align authorization duration with task duration, not with deployment convenience.

Bedrock guardrails are necessary but incomplete. Content controls and IAM controls operate at different layers, so one cannot compensate for weakness in the other. Security teams that declare an agent safe because prompts are filtered are overlooking the actual trust boundary, which is the set of AWS actions the role can reach. The practical conclusion is to treat prompt safety and privilege scope as separate controls.

Identity review must become a launch gate for AI agents. If a production agent can invoke Lambda, query knowledge bases, and reach multiple AWS services, then its permissions are part of the release artifact. That means access review, resource scoping, and rollback criteria belong in the go-live checklist. Teams that leave permission cleanup for later are accepting drift as a design choice.

Lifecycle governance is the named concept this topic exposes. Bedrock agents are not just workloads, they are NHI instances with creation, expansion, and retirement phases. The governance gap appears when teams manage creation but ignore post-build pruning and periodic re-certification. Practitioners need a lifecycle model that keeps runtime access aligned to actual agent behavior, not initial implementation history.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• From our research: Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to The 2026 Infrastructure Identity Survey.
• That gap is why NHI teams should pair role scoping with the Ultimate Guide to NHIs and the OWASP NHI Top 10.

What this signals

Ephemeral execution is not a substitute for ephemeral privilege. As AI agents move from pilots into production, teams will need to design access around task duration and tool scope, not around how long the deployment remains active. The practical signal for practitioners is that permission review becomes a release control, not a quarterly cleanup exercise.

With 69% of security leaders saying identity management must fundamentally shift to address agentic AI systems, the operating model is already moving toward NHI governance as a first-class discipline. That shift aligns closely with the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10.

Identity blast radius will become a board-level term as agents gain access to more services, data, and automation paths. Teams that cannot show why each entitlement exists will struggle to defend their controls under audit, incident review, or AI governance scrutiny.

For practitioners

• Re-baseline every Bedrock execution role Replace broad development policies with custom policies scoped to the exact model ARN, knowledge base, Lambda functions, S3 locations, guardrails, and KMS keys the agent truly uses.
• Separate control reviews by role type Review the agent execution role, knowledge base service role, and each Lambda execution role independently so one over-permissioned component does not mask the others.
• Treat guardrails and IAM as separate controls Use Bedrock guardrails for content and policy filtering, but enforce least privilege through IAM policy scope, resource-based policy conditions, and explicit deny boundaries.
• Add permission review to every agent change Require a re-certification step whenever a new action group, data source, or cross-account integration is attached, because that is when role drift usually starts.
• Use org-level ceilings for production accounts Apply service control policies to block services and actions that should never be reachable from a production Bedrock agent, even if a future role change tries to add them.

Key takeaways

• AI agents become high-risk non-human identities when their runtime permissions are left wider than their actual task scope.
• Over-privileged agent roles are not a theoretical concern, because dynamic tool use turns every excess entitlement into reachable attack surface.
• The practical response is to make permission review, role scoping, and re-certification part of the AI deployment lifecycle.

Key terms

• Non-Human Identity: A non-human identity is any machine, service, workload, token, certificate, or agent that authenticates and gets access without a person directly using it. In NHI governance, the key issue is not whether it can log in, but whether its access is scoped, monitored, and retired with the same discipline as human identity.
• Standing Privilege: Standing privilege is persistent access that remains available after the original need has passed. For AI agents and cloud workloads, it creates a large attack surface because excess permissions stay attached long after testing, making accidental misuse or abuse easier than intended.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and actions that become reachable if a single identity is misused or compromised. For AI agents, the blast radius grows quickly when one role can chain tool calls, invoke functions, and access multiple services without a human checkpoint.
• Lifecycle Governance: Lifecycle governance is the practice of managing identity from creation through use, review, rotation, and retirement. For non-human identities, it means treating permissions as temporary business decisions that must be re-validated as the workload, toolset, or agent behavior changes.

Deepen your knowledge

AWS Bedrock agent permission scoping is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are tightening cloud agent governance after deployment, it is a relevant place to start.

This post draws on content published by Sonrai Security: AWS Bedrock Agent Permissions: What You Need to Lock Down Before Go-Live. Read the original.