IAM Permission Boundary

What is an IAM permission boundary?

An IAM permission boundary is an AWS feature that sets the maximum permissions an IAM role or user can have — a ceiling, not a grant. Attaching a permission boundary to an entity means that entity’s effective permissions are the intersection of its identity policies (what’s granted) and the boundary (what’s allowed at most): the entity can never do something its boundary forbids, even if an identity policy grants it. Like a Service Control Policy, a permission boundary does not grant any permissions on its own — it only limits — which is the single most important and most misunderstood thing about it.

The problem it solves — safe delegation without privilege escalation

Permission boundaries exist to solve a specific, tricky problem: safely letting people create and manage IAM entities without letting them escalate their own (or others’) privileges. Imagine you want to let a development team create their own IAM roles for their applications (good for autonomy and velocity) — but if they can create roles with any permissions, they can simply create a role with admin access and assume it, escalating past whatever limits you intended. That’s a privilege-escalation hole. Permission boundaries close it: you grant the team permission to create roles but require that every role they create has a specific permission boundary attached, which caps what those roles can do. Now the team can freely create and manage roles for their apps, but none of those roles can exceed the boundary you defined — they can’t mint an admin role because the boundary forbids it. This is the core use case: delegated IAM administration with a guardrail that prevents escalation. It’s what lets platform teams give application teams self-service IAM without handing over the keys to the kingdom.

How it fits with the other “limiting” controls

AWS has several controls that cap rather than grant permissions, and understanding how they stack is essential (and a common source of “why is this denied when my policy allows it?” confusion). Effective permissions are the intersection of all applicable limiting controls and the identity’s grants: an action is allowed only if it’s permitted by the identity policy (grants) AND not blocked by the permission boundary (per-entity ceiling) AND not blocked by any SCP (org/account-wide ceiling from AWS Organizations) AND not denied by a resource policy or session policy. An explicit Deny anywhere always wins. So permission boundaries and SCPs are complementary: SCPs set guardrails at the account/organization level (applying to everyone in the account), while permission boundaries set guardrails on individual entities (applying to a specific role/user) — you use SCPs for org-wide rules and permission boundaries for delegating IAM safely to specific teams. Both embody the principle of least privilege as enforced ceilings. The realities: because a boundary is a ceiling not a grant, forgetting that trips people up constantly — attaching a boundary doesn’t give an entity any access, and an entity with a boundary but no identity policy can do nothing (empty intersection); and the delegation pattern only works if you also prevent the delegated users from removing or altering the boundary (otherwise they just detach it and escalate — so the permission to manage roles must be conditioned on keeping the boundary attached). The recurring mistakes: thinking a permission boundary grants access (it only limits), forgetting the effective-permissions intersection when debugging denials, and setting up delegated role creation without preventing users from stripping the boundary off.

What people get wrong

• Thinking it grants permissions — a permission boundary only sets a ceiling; the entity still needs identity policies to actually be allowed anything, and the effective set is the intersection.
• Forgetting the intersection when debugging: “my policy allows it but it’s denied” is usually a boundary or SCP capping it — effective access requires all limiting controls to permit the action.
• Delegation without protecting the boundary — if delegated users can detach or edit their boundary, they can escalate freely; the delegation must be conditioned on the boundary staying attached.

Primary source: AWS IAM permissions boundaries