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.
Editorial analysis by NHI Mgmt Group, based on content published by Sonrai Security: “AWS Bedrock Agent Permissions: What You Need to Lock Down Before Go-Live”.
By the numbers:
- Sonrai Security says over 90% of cloud permissions across human and non-human identities are not used.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Bedrock agent permissions can drift from build-time convenience into production authority, which leaves standing access that was never meant to persist.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/06/2026 7:07 pm
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.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: AWS Bedrock agent permissions and the least-privilege gap