Notifications
Clear all
Topic starter
08/06/2026 4:43 pm
TL;DR: AI agents in AWS Bedrock execute through IAM roles, so overly broad execution permissions can turn a prompt into broad infrastructure access, data exposure, or configuration change, according to Sonrai Security. The core issue is that access review and least-privilege models still assume stable, human-paced use of permissions, not rapid agent-driven API chaining.
NHIMG editorial — based on content published by Sonrai Security: AI in AWS, Why Locking Down IAM Is Critical for Secure AI Agents
Questions worth separating out
Q: How should security teams govern IAM access for AI agents in AWS?
A: Treat each AI agent as a non-human identity with its own execution role, trust policy, and review cycle.
Q: Why do AI agents create more cloud access risk than human users?
A: AI agents can chain API calls quickly, interact with multiple services in one session, and operate without the familiar human signals that security tools expect.
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.
Practitioner guidance
- Assign a dedicated IAM role per AI agent Avoid shared execution roles, because reused roles make it impossible to separate one agent's purpose from another's permissions.
- Remove wildcard permissions from agent roles Replace broad actions such as s3:* or lambda:* with service- and resource-specific permissions that match the exact workflow.
- Enforce organisation-wide ceilings with SCPs Use Service Control Policies to restrict where agents can be deployed and which Bedrock actions can be invoked.
What's in the full article
Sonrai Security's full blog covers the operational detail this post intentionally leaves for the source:
- The exact Bedrock execution-role patterns that create over-permissioned access in AWS.
- The CloudTrail and SCP configuration details used to enforce and observe agent activity.
- The practical checklist for separating agent invocation controls from resource-level permissions.
- The step-by-step hardening guidance for S3, Lambda, and other downstream services.
👉 Read Sonrai Security's analysis of AWS Bedrock IAM risk for AI agents →
AWS Bedrock agents and IAM scoping: what security teams miss?
Explore further
08/06/2026 6:29 pm
AI agent identity risk is an IAM problem first, not an AI problem first. The article shows that Bedrock agents become non-human identities the moment they execute through IAM roles. That means the security boundary is the permission set, not the model prompt. Practitioners should therefore evaluate agent deployments as identity objects with scope, lifecycle, and revocation requirements, not as isolated application features.
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.
- 19% of organisations give AI systems dramatically more access than human employees, which shows how quickly exception-based AI access becomes normalised.
A question worth separating out:
Q: Who is accountable when an AI agent reaches sensitive AWS resources?
A: The organisation is accountable for the permissions granted, the controls around role use, and the review process that allowed access to persist. If the agent was repurposed without re-certification, that is a lifecycle failure. If the role was too broad, that is an access governance failure.
👉 Read our full editorial: AI agent identity risk in AWS exposes IAM gaps in cloud security
