Notifications
Clear all
Topic starter
02/06/2026 6:53 pm
TL;DR: Most Bedrock agents in production inherit standing IAM roles with permissions accumulated during testing, so the agent can invoke services, Lambda functions, and knowledge bases automatically at runtime, according to Sonrai Security. That makes least privilege and permission review operational requirements, not launch-day hygiene.
NHIMG editorial — based on content published by Sonrai Security: AWS Bedrock Agent Permissions: What You Need to Lock Down Before Go-Live
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
The practical signal for practitioners is that permission review becomes a release control, not a quarterly cleanup exercise?
👉 Read Sonrai Security’s analysis of AWS Bedrock agent permissions before go-live →
Explore further
02/06/2026 7:07 pm
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.
A few things that frame the scale:
- 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.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to The 2026 Infrastructure Identity Survey.
A question worth separating out:
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.
👉 Read our full editorial: AWS Bedrock agent permissions and the least-privilege gap
