Permission Boundary vs IAM Policy: What Actually Controls Access

Key Takeaways

• IAM policies grant permissions to an identity and are what AWS checks to determine whether an action is allowed. Permission boundaries don't grant permissions; they cap the maximum permissions an IAM policy can authorize for a given identity.
• When both are present, effective permissions are the intersection: the action must be explicitly allowed by the IAM policy and also fall within what the permission boundary permits. An IAM policy that grants more than the boundary allows is functionally limited to what the boundary covers.
• The decision about which control to use isn't either/or. IAM policies handle what an identity can do. Permission boundaries handle what delegated identities (roles created by developers, automated systems, or AI agents) can ever be granted.
• Most environments need both, but applied to different problems. Reaching for a permission boundary when you need an identity policy, or vice versa, is one of the most common sources of IAM misconfiguration.

Most IAM access problems come down to one of two questions: what is this identity allowed to do, and how do we make sure it can't be granted more than intended? Those are related questions, but they need different answers. IAM policies answer the first. Permission boundaries answer the second.

Understanding when to reach for each, and how they interact, is what makes it possible to build a least-privilege model that holds as environments grow, teams expand, and automated workloads multiply.

The Core Difference

An IAM policy is a grant. A permission boundary is a constraint on what grants can do. Every time an identity makes a request, IAM checks whether the action is allowed by the policy. If a permission boundary is attached, it checks whether the action also falls within the boundary. Both must be true for the request to succeed.

The Decision Framework: Which Control to Reach For

The pattern that emerges: IAM policies are the right tool when you're defining what a known, intentional identity should be able to do. Permission boundaries are the right tool when you're delegating the ability to create or configure identities, and you need to make sure that delegation can't be used to exceed what you intended.

How the Intersection Works

When an identity has both an IAM policy and a permission boundary attached, AWS computes effective permissions as the intersection of both. Consider a role with an IAM policy that grants s3:* on all buckets, and a permission boundary that only includes s3:GetObject and s3:PutObject. The role's effective permissions are s3:GetObject and s3:PutObject. Nothing more. The broader IAM policy doesn't expand what's possible beyond what the boundary permits.

Permission boundaries don't default to permissive. Any action the boundary doesn't explicitly allow is implicitly denied, even if the IAM policy grants it. An explicit deny in either policy overrides everything else.

This is why permission boundaries are useful for delegation: a developer could write the most permissive IAM policy they can imagine and attach it to a role they created, and the boundary the central team defined still holds. The role can't do more than the boundary permits, regardless of what the IAM policy says.

Where Teams Get This Wrong

Using a permission boundary when an SCP is the right answer. Permission boundaries apply to individual identities within a single account. If you need a guardrail that applies to every identity across an account or organizational unit, Service Control Policies are the right control. Permission boundaries don't enforce account-wide restrictions; they constrain the scope of specific identities.

Assuming a permission boundary replaces identity policies. A permission boundary that lists an action doesn't allow the identity to perform it. The IAM policy still needs to grant the action. The boundary only prevents the policy from granting more than intended.

Not accounting for resource-based policies. If a resource-based policy grants access directly to a principal ARN, that access can take effect even if the permission boundary doesn't include an explicit allow. Teams using resource policies alongside permission boundaries should review this interaction in their access architecture.

Treating permission boundaries as a substitute for scoping. Permission boundaries handle the ceiling. IAM policies still need to be scoped correctly for the use case. A broad IAM policy with a permission boundary isn't the same as a well-scoped IAM policy; the boundary caps the ceiling, it doesn't do the work of defining intent.

For more on how these controls fit within a broader enforcement architecture, see What Are Cloud Security Guardrails? and Why CSPM Tools Can't Stop Cloud Misconfigurations From Recurring on the Native blog.

Connecting the Decision to Architecture

IAM policies and permission boundaries are primitives. They're the right tools for their respective problems, but they work within a single account and they don't connect to each other across environments. In most cloud organizations, these controls accumulate through individual decisions, a boundary here, a policy scoped there, without a coherent picture of which identities are allowed to operate where, which access paths are intentional, and which baselines should hold regardless of how roles get configured over time.

That's the layer Native operates at. Native gives security teams a way to define architectural intent across zones, boundaries, and baselines, and translates that intent into the provider-native controls already available in AWS, Azure, Google Cloud, and OCI, including IAM policies, permission boundaries, SCPs, and RCPs. As the environment changes, Native tracks drift and keeps enforcement aligned to what was actually intended.

Frequently Asked Questions

When should I use a permission boundary instead of an IAM policy? Use an IAM policy when you're defining what a specific, known identity should be able to do. Use a permission boundary when you're delegating the ability to create or manage IAM roles, and you need to make sure those roles can't be granted more access than the central team intended. The two controls solve different problems and most environments need both.

Does a permission boundary override an IAM policy? Not exactly. A permission boundary doesn't override an IAM policy; it caps what the policy can authorize. If an IAM policy grants broader access than the boundary allows, the effective permissions are limited to what the boundary permits. The policy still applies, it just can't exceed the ceiling the boundary sets.

Can a permission boundary work without an IAM policy attached? No. A permission boundary only restricts; it doesn't grant access on its own. If a permission boundary is attached to a role but no identity policy grants the action, the request is denied. Both must be present and both must allow the action for it to succeed.

What's the difference between a permission boundary and an SCP? A permission boundary applies to a specific identity within a single account. An SCP applies to every identity across an entire account or organizational unit. Use an SCP when you need an account-wide guardrail that holds regardless of what any individual role's policies say. Use a permission boundary when you're constraining the scope of roles created through delegated IAM management, without restricting every other identity in the account.

If a developer attaches a very permissive IAM policy to a role, does the permission boundary still hold? Yes. That's the core value of the control. A developer can attach any IAM policy they have access to, but the permission boundary the central team defined limits what that policy can authorize. The role's effective permissions are still the intersection of both, so no matter how broad the identity policy is, the boundary is the ceiling.

Schedule a demo to see it applied to your environment.