Least Privilege for AI Agents on AWS: How Cedar Stops Authorization Scope Creep

When an AI agent delegates to another agent on AWS, authorization scope can silently expand at every hop — OWASP classifies this as ASI03: Identity & Privilege Abuse, and AWS published a Cedar pattern on July 6, 2026 to stop it.

What Authorization Scope Creep Means for AI Agents

Standard IAM works at the level of a single call: does this principal have permission to take this action on this resource? Multi-agent systems create a different problem. A chain of agents — each with their own IAM role, each correctly configured — can collectively reach resources and actions that the originating user never authorized.

Every hop in the chain trusts the call it received, not the human’s original intent. Individual agents look fine. The aggregate authorization surface is not.

This is authorization scope creep. It is a structural problem, not a misconfiguration.

Why Multi-Agent Chains Expand the IAM Blast Radius

In a traditional deployment, the IAM blast radius is a resource map: which services and resources can this role reach? In a multi-agent deployment, it is a delegation tree. Agent A orchestrates Agent B. Agent B delegates to Agent C. Agent C calls a tool.

Even when role-based access control (RBAC) policies are correctly set at each individual hop, the chain can reach beyond what the user at the top ever authorized. As AWS’s security blog puts it: “an agent can potentially act beyond what the originating user authorized, even when role-based access control (RBAC) policies are in place.”

OWASP’s Top 10 for Agentic Applications classifies this as ASI03: Identity & Privilege Abuse. It is distinct from ordinary IAM misconfigurations because no single role is wrong — the problem is in how authorization scope compounds across the chain.

How AWS’s Cedar Pattern Enforces Least Privilege Across Every Hop

On July 6, 2026, the AWS Security Blog published a pattern using Cedar — AWS’s open-source authorization language — to enforce least-privilege authorization across multi-hop agent chains.

Cedar evaluates authorization in three sequential layers at every delegation hop:

Layer 1 — Agent-to-tool validation. Cedar validates the calling agent’s trust score, namespace, and lifecycle stage. An agent that does not meet the threshold cannot proceed, regardless of its IAM role.

Layer 2 — Delegation scope. Cedar checks the delegation hop count and enforces a hard limit of 5 hops. No chain — no matter how many agents are stacked — can extend beyond five steps.

Layer 3 — Originating user authorization. The originating user’s authorization context (role, MFA status, delegation depth) is propagated through the entire chain and signed with HMAC-SHA256. No downstream agent can tamper with or exceed this context. Evaluation halts on the first deny decision.

The cryptographic signing is the key: if any hop in the chain were to modify or inflate the user’s authorization context, the signature would fail and the request would be denied.

How to Implement This on AWS

The reference implementation uses Amazon Cognito as an OIDC-compliant identity provider and OAuth 2.0 Token Exchange (RFC 8693) for on-behalf-of delegation scoping. Cedar policies are evaluated at each hop before any tool call is permitted.

This pattern is framework-agnostic. Whether you are using Amazon Bedrock agent frameworks, building on Strands Agents, or using any other orchestration library, the Cedar evaluation layer sits outside the framework — it enforces authorization before the agent’s action reaches the tool.

Teams moving multi-agent workloads toward production should treat this pattern as foundational. Retrofitting authorization controls after deployment is harder than building them in from the start, and the vulnerability is invisible until it is exploited.

How Different Industries Could Use This

Healthcare. An AI agent chain automating prior-authorization workflows might delegate to a billing sub-agent and a clinical-records agent. Cedar would ensure the billing agent can only access what the originating clinician’s role allows — preventing inadvertent cross-system data access without additional application-level checks.

Financial services. In a multi-agent research pipeline analyzing market data, Cedar’s hard 5-hop limit and originating-user scope could prevent downstream agents from reaching privileged data feeds the originating analyst was not authorized to query.

SaaS platforms. A customer-facing AI assistant that delegates to internal agents for CRM, billing, and ticketing systems could use Cedar to enforce per-customer data isolation at every delegation step — matching the authorization context of the logged-in user, not the agent service account.

Cybersecurity. SIEM automation chains that delegate threat-hunting tasks to sub-agents benefit from Cedar’s delegation-depth limit: an agent cannot spawn an unbounded sequence of tool calls that escalates into administrative actions the originating analyst never initiated.

Composite Authorization Is Already a Discipline — for IAM

The delegation-chain problem is new to AI agents, but the underlying idea is not: authorization has to be reasoned about across a chain of identities, not one principal at a time. That is the core of Cloud Infrastructure Entitlement Management (CIEM).

Sherpa’s CIEM analysis already traces this for your AWS identities today — privilege-escalation chains (which principals can chain permissions or assume their way to higher privilege), who can reach which resources across accounts, and the blast radius of each path. That is composite authorization for static IAM: reasoning about the whole chain, not each role in isolation.

The Cedar pattern in this post extends the same discipline to a new surface — AI-agent delegation chains, where the “principals” are agents handing off to agents at runtime. Same question, one layer up: what can the full chain actually reach? That is where this work is heading. Today, Sherpa enforces at the action layer — every change it proposes requires human approval before it runs.

FAQ

What is authorization scope creep in multi-agent AI systems?

Authorization scope creep occurs when a chain of AI agents, each with individually correct IAM roles, collectively reaches resources or actions that the originating user never authorized. The problem is structural: each hop trusts the call it received, so scope compounds across the chain even when no single role is misconfigured.

What is ASI03 in the OWASP Top 10 for Agentic Applications?

ASI03 is “Identity & Privilege Abuse” — OWASP’s classification for the risk of AI agents acting beyond what the originating user authorized, including through multi-hop delegation chains. It is listed in the OWASP Top 10 for Agentic Applications as a distinct risk from traditional IAM misconfigurations.

What does Cedar do in a multi-agent chain?

Cedar enforces a three-layer authorization check at every delegation hop: it validates the calling agent’s identity and trust level, enforces a hard limit of 5 delegation hops, and propagates the originating user’s authorization context (signed with HMAC-SHA256) through the entire chain. No downstream agent can exceed the scope the originating user authorized.

Does this pattern only apply to Amazon Bedrock agents?

No. The Cedar authorization pattern is framework-agnostic. While the AWS Security Blog’s reference implementation uses Amazon Cognito and Bedrock, the enforcement model applies to any multi-agent system on AWS that instruments Cedar policy evaluation at each delegation hop.

Does Sherpa analyze authorization scope like this today?

Sherpa analyzes it for your IAM identities today through its CIEM capability — mapping privilege-escalation chains, unused access, and the blast radius of each path across your AWS accounts. Applying the same reasoning to AI-agent delegation chains is where the work is heading; Sherpa’s current enforcement is at the action layer, where every change it proposes requires human approval before it runs.

Should teams implement this before putting multi-agent systems into production?

Yes. OWASP classifies authorization scope creep as a Top 10 risk for agentic applications, and the vulnerability is invisible to standard IAM audit tooling — it does not appear as a misconfiguration because every individual role is correct. The pattern is significantly easier to build in from the start than to retrofit after deployment.