Permission Boundary

A Permission Boundary is a managed IAM policy that you attach to an IAM user or role to define the maximum permissions that entity can have. It does not grant permissions, it limits what identity-based policies can effectively allow.

Think of it as a filter: the effective permissions are the intersection of the identity-based policy and the permission boundary. If a policy allows s3:* but the boundary only allows s3:GetObject, the effective permission is only s3:GetObject.

Use Cases

• Delegation: allow developers to create IAM roles for their applications, but only within the boundary you define
• Privilege escalation prevention: prevent users from creating roles with more permissions than they have
• Multi-tenant environments: limit each tenant's permissions to their own resources

How Boundaries Fit With Other Policy Types

A permission boundary applies to a single IAM user or role, and only to that entity. It does not affect resource-based policies: if an S3 bucket policy grants access to a role directly, the boundary on that role still applies to the role's own requests, but the boundary of one entity never restricts another entity. Boundaries also cannot be attached to groups or to service-linked roles. In an organization, the effective permissions of a principal are the intersection of the identity-based policy, the permission boundary (if present), and any SCPs that apply to the account. All three have to allow an action for it to succeed, and an explicit deny anywhere always wins.

How It Goes Wrong in Practice

The typical failure is a delegation setup that enforces boundaries at creation time but not afterwards. A platform team wants developers to create their own application roles, so they grant iam:CreateRole and iam:AttachRolePolicy with a condition requiring the iam:PermissionsBoundary key to equal the approved boundary policy ARN. So far so good: every role a developer creates must carry the boundary.

The gap: the same developers are also granted iam:DeleteRolePermissionsBoundary, or the condition is applied to iam:CreateRole but not to iam:PutRolePermissionsBoundary and iam:AttachRolePolicy. A developer (or an attacker using a developer's credentials) creates a compliant role, then strips or swaps the boundary, or attaches an admin policy to an existing unbounded role. The boundary scheme collapses because the surrounding IAM permissions were not locked down. A working delegation model must deny iam:DeleteRolePermissionsBoundary and iam:DeleteUserPermissionsBoundary, deny modifying or deleting the boundary policy itself, and require the boundary condition on every create and attach action, not just role creation. A second common mistake is treating the boundary as a grant: teams attach a boundary and no identity policy, then wonder why the role can do nothing. The boundary is a ceiling, not a floor.

Setting a Boundary From the CLI

To attach or replace the boundary on an existing role:

aws iam put-role-permissions-boundary --role-name lambda-application-role --permissions-boundary arn:aws:iam::123456789012:policy/developer-boundary

Both parameters are required: --role-name takes the friendly role name (not the ARN) and --permissions-boundary takes the ARN of the managed policy to use as the ceiling. The command produces no output on success. The equivalent for users is aws iam put-user-permissions-boundary. Note that boundaries cannot be set on service-linked roles, and the boundary must be a managed policy, not an inline policy.

Frequently Asked Questions

What is the difference between a permission boundary and an SCP?

Both are ceilings that limit rather than grant, but they operate at different levels. An SCP is attached to an AWS account, an OU, or the organization root through AWS Organizations, and it caps every principal in the affected accounts. A permission boundary is attached to one specific IAM user or role. Use SCPs for organization-wide guardrails and boundaries for fine-grained delegation inside an account.

Do permission boundaries grant any permissions on their own?

No. A role with a boundary but no identity-based policy has no permissions at all. The effective permissions are the intersection of what the identity-based policies allow and what the boundary allows. The boundary only defines the maximum.

Can a boundary restrict access granted by a resource-based policy?

Only for the bounded principal's own actions. When a principal with a boundary makes a request, the boundary is evaluated as part of that request. But a resource-based policy that grants access to a different principal is unaffected by boundaries attached to anyone else. This is why boundaries alone are not sufficient to protect sensitive resources: you still need tight resource policies and SCPs.

Can I attach a permission boundary to an IAM group?

No. Boundaries apply only to IAM users and roles. If you need a ceiling for a group of people, attach the same boundary to each user, or better, move them to roles federated through IAM Identity Center and apply the boundary in the permission set.