AI agent identity risk in AWS exposes IAM gaps in cloud security

At a glance

What this is: This analysis argues that AWS Bedrock agents behave as non-human identities whose execution roles can quietly expand the blast radius of cloud access.

Why it matters: It matters because IAM teams must govern agent permissions, service-to-service access, and lifecycle review with the same discipline they apply to human and workload identities.

👉 Read Sonrai Security's analysis of AWS Bedrock IAM risk for AI agents

Context

AWS Bedrock agents are AI-driven workloads that act through IAM roles, not human sign-in sessions. That means the security question is not only who can invoke the agent, but what the agent can reach once its role is assumed. In cloud programmes, that shifts AI agent identity risk from application logic into identity governance.

The practical gap is familiar: teams often scope permissions for the initial use case and then fail to revisit them when the agent is repurposed. Once an agent can chain API calls across S3, Lambda, DynamoDB, or network controls, a single over-permissioned role becomes a cloud access risk rather than just a model integration detail.

Key questions

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. Scope permissions to the smallest working set, remove wildcard access, and validate what the agent can actually do across downstream services. The safest control is to govern the role, not the prompt.

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. That makes over-permissioned access harder to spot and faster to abuse. In practice, the risk comes from effective privilege, not just who initiated the action.

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: 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.

Technical breakdown

AWS Bedrock agents inherit risk through IAM execution roles

Bedrock agents do not authenticate like people. They assume an IAM execution role and then issue AWS API calls under that role's permissions. If the role is broad, the agent can read data, invoke functions, or modify infrastructure far beyond the original intent. The important detail is that the agent's effective authority is defined by role scope, not by the user prompt alone. That is why a permissive role becomes the real control plane for AI agent identity risk.

Practical implication: Scope each agent to a dedicated execution role and review every policy attached to that role before production use.

Why over-permissioned AI agents create blast radius in cloud environments

An over-permissioned agent can chain actions across services in rapid succession. For example, broad S3 read access combined with Lambda invocation rights can let the agent move from a data source to downstream changes in seconds. In cloud identity terms, that is a classic blast-radius problem, but now the actor is non-human and can move faster than a manual review cycle. The risk is not only data access. It is also privileged service interaction that can alter network, storage, or compute state.

Practical implication: Limit each agent to the minimum service set it actually needs and deny wildcard permissions wherever possible.

Guardrails do not replace permission boundaries

AWS guardrails can shape what an agent says or how it behaves, but they do not fully control what the agent's IAM role can do. If the underlying role can modify guardrails, invoke privileged functions, or reach sensitive resources, the behavioural layer can be bypassed by permission changes. This is why identity security has to sit beneath the AI layer. The control that matters is not only model governance, but permission enforcement across the target services and the organisation boundary.

Practical implication: Treat guardrails as a secondary control and enforce organisation-level ceilings with SCPs, logging, and resource policies.

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

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.

Standing privilege creates the wrong security model for agents that can chain actions quickly. A role that looks acceptable at provisioning time can become dangerous once the agent starts combining S3, Lambda, DynamoDB, and infrastructure APIs in one session. The blast radius grows because the environment assumes permissions are reviewed after use, while the agent can consume them before human review catches up. The implication is that review cadence and runtime behaviour are now misaligned.

Confused deputy risk in AI agents is really delegated privilege without a lifecycle boundary. The article's scenario shows how an agent can be repurposed, inherit new integrations, and keep old access without anyone re-authorising the changed purpose. That is not a tool problem. It is a governance assumption failure about access staying aligned to original intent. Security teams should treat every repurpose event as a fresh identity change, not as a minor configuration edit.

Least privilege for AI agents must be measured against effective actions, not declared intent. The article makes clear that a role granted for one narrow task can still interact with many downstream services if those permissions are broadly scoped. That means governance teams need to test what the agent can actually reach when roles, resources, and service chaining are combined. Practitioners should use effective privilege as the control lens, not policy intent alone.

Cloud identity programmes need a named concept for the gap between agent autonomy and permission oversight. Agent blast radius: the distance between a harmless-sounding prompt and the largest set of cloud actions the agent can actually execute through inherited IAM permissions. That gap grows when roles are reused, guardrails are mutable, and access reviews are human-paced. The practical conclusion is that AI agent identity governance must be designed around runtime authority, not just deployment approval.

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.
• 19% of organisations give AI systems dramatically more access than human employees, which shows how quickly exception-based AI access becomes normalised.
• Read Ultimate Guide to NHIs for the broader lifecycle and governance context that sits behind this access problem.

What this signals

Agent blast radius is becoming a programme-level issue. As AI workloads move from pilots into infrastructure operations, the real control question is whether your entitlement model can keep pace with machine-speed decision chains. The broader pattern is visible in our research: with 52% of security leaders already seeing AI security decision-making power shift toward platform and infrastructure teams, governance is moving out of the traditional IAM lane and into operational ownership.

Security leaders should expect agent governance to converge with workload identity, PAM, and cloud policy enforcement. The organisations that will manage this well are the ones that treat AI agents as durable identity subjects with ownership, review, and revocation, not as temporary application features. That shift is already visible in the way cloud teams are taking on more of the AI access burden, and it will shape how identity programmes are measured over the next cycle.

For practitioners

• 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. Review every trust policy and attached permission policy before the agent is allowed to touch production resources.
• 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. Validate the policy against the agent's real API call pattern, not the original design intent.
• Enforce organisation-wide ceilings with SCPs Use Service Control Policies to restrict where agents can be deployed and which Bedrock actions can be invoked. This keeps account-level role changes from silently expanding into new regions or unmanaged environments.
• Log and review every agent invocation path Enable CloudTrail for bedrock:* activity and correlate invocation logs with the downstream AWS services the agent touches. If an agent can call an action and leave no durable audit trail, you cannot prove what it accessed or changed.
• Re-certify agent roles whenever use cases change Treat repurposing as a governance event. If the agent gains new integrations, a new owner, or a new data domain, recertify its effective access before the new workflow goes live.

Key takeaways

• AWS Bedrock agents are non-human identities, so their security posture is determined by IAM role scope rather than model behaviour alone.
• Over-permissioned agent roles expand cloud blast radius because agents can chain actions across services faster than human review cycles can respond.
• The practical control point is lifecycle governance of the role itself, including scope reduction, logging, recertification, and organisation-wide policy ceilings.

Key terms

• AI Agent Identity: A machine identity used by an AI system to authenticate and act inside an environment. In cloud settings, the agent usually inherits permissions through an execution role, which means the identity model is defined by access scope, revocation, and downstream service reach rather than by human login patterns.
• Execution Role: The IAM role an AI agent assumes to call cloud services on behalf of a workflow. It is the main control point for what the agent can do, so poor scoping turns an ordinary agent into a high-blast-radius identity with access that can outlive the original use case.
• Blast Radius: The amount of damage an identity can cause if it is misused, over-permissioned, or repurposed without review. For AI agents, blast radius grows quickly when one role can reach multiple services, because a single prompt can cascade into many actions across storage, compute, and network layers.
• Confused Deputy: A service that can be induced to perform actions on behalf of a caller that should not have that level of access. In AI agent deployments, the problem appears when a broadly privileged agent can be invoked by the wrong user or reused for a new purpose without re-authorisation.

Deepen your knowledge

AI agent identity risk in AWS is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building cloud governance for Bedrock agents or similar workloads, it is worth exploring.

This post draws on content published by Sonrai Security: AI in AWS, Why Locking Down IAM Is Critical for Secure AI Agents. Read the original.