Permission Boundaries vs SCPs: How They Differ and When to Use Each

Use SCPs when you need to enforce a permission ceiling across an entire AWS account or organizational unit; use permission boundaries when you need to cap what a specific IAM role or user can do within a single account, especially when delegating IAM management to others.

Key Takeaways

• SCPs operate at the AWS Organizations level and restrict the maximum permissions available to every principal in an account or OU, making them the right tool for org-wide guardrails that hold regardless of what IAM policies individual teams attach.
• Permission boundaries apply to individual IAM users and roles within a single account and define the maximum permissions those identities can exercise, but they don't grant any permissions themselves.
• The two controls operate at different layers and aren't substitutes. In environments that need both account-level enforcement and fine-grained identity scoping, running them together is common and intentional.
• Treating one as a substitute for the other is the most common misconfiguration, and it tends to produce enforcement that's either too broad to be useful or too narrow to protect the account.

What Each One Is

Both SCPs and permission boundaries answer a variation of the same question: how do you prevent an IAM principal from exercising permissions it technically has? They solve the problem from different vantage points, at different scopes, and with different operational owners.

An AWS Service Control Policy (SCP) is an organization-level policy attached to the root, an organizational unit, or an individual account within AWS Organizations. SCPs define the maximum permissions that principals in that scope can be granted. A principal can't exercise a permission the account's SCP disallows, regardless of what the principal's IAM policies say. SCPs don't grant permissions on their own; they define the ceiling. Everything inside that ceiling still requires an explicit IAM allow. SCPs are one of several org-level controls in AWS Organizations; for how they compare to resource control policies, see AWS RCPs vs. SCPs.

A permission boundary is an IAM managed policy that an administrator attaches to an IAM user or role. It defines the maximum permissions that identity can exercise, regardless of what identity-based policies are attached to it. Like SCPs, permission boundaries don't grant permissions; they cap them. If a permission boundary allows only s3:GetObject on a role that has AdministratorAccess attached, that role can only perform s3:GetObject.

The key conceptual difference is scope. SCPs are an organizational control, and permission boundaries are an identity-level control. SCPs govern what an account can do. Permission boundaries govern what a specific identity within that account can do. For how SCPs compare to declarative policies, another org-level construct, see Declarative Policies vs. SCPs.

Side-by-Side Comparison

How They Interact

When both controls are in place, effective permissions are the intersection of three layers: the identity-based policies attached to the principal, the permission boundary on that identity (if one exists), and the SCP on the account. A principal needs an explicit allow from all applicable layers to take an action. An explicit deny in any single layer blocks the action regardless of what the others say.

SCPs set the hard outer boundary for the account. Permission boundaries then narrow what a specific identity within that account can do, to a subset of whatever the SCP permits. If an SCP allows S3 operations across the account but a specific role has a permission boundary that excludes S3, that role still can't perform S3 operations. Neither control can override the other.

One important nuance: permission boundaries don't restrict access granted through resource-based policies in same-account scenarios. If an S3 bucket policy in the same account explicitly grants a principal access, the principal's permission boundary doesn't narrow that access. SCPs do apply to how principals use those grants, which is one reason SCPs provide stronger org-wide guarantees than permission boundaries alone.

Decision Framework

Use an SCP when:

The restriction needs to apply to every principal in an account, regardless of what IAM policies are attached. This includes enforcing approved regions, blocking access to entire service categories, preventing root user actions in member accounts, or ensuring that no principal, even one with AdministratorAccess, can bypass a baseline control. SCPs are also the right tool when you're managing multiple accounts under an OU and want consistent guardrails that don't depend on each account admin applying them manually.

Use a permission boundary when:

You need to delegate IAM management to developers, platform teams, or automation pipelines without giving them the ability to create roles that exceed what you intend. Permission boundaries let account admins hand off the ability to create and attach roles while enforcing a structural cap on what those roles can do. They're also the right fit when you need to scope a specific CI/CD role, service account, or agentic workload to a narrower set of actions than its attached policies would otherwise allow, without changing the attached policies themselves.

Use both when:

You're operating in a multi-account organization where accounts need baseline guardrails (SCP) and specific identities within those accounts need additional scoping (permission boundary). This is especially common when you've delegated IAM role creation to account-level teams and want to ensure those teams can't create roles that bypass org policy or grant themselves capabilities outside what you've sanctioned.

Worked Scenario: Both Controls in a Production AWS Organization

A platform engineering team manages a multi-account AWS organization. The organization has separate accounts for production, staging, and development, all under distinct OUs. Several development team members have IAM roles in the development account with policies that allow broad access for experimentation.

The org-level problem: The platform team needs to ensure that nothing in the development account can interact with production data stores or cross into production infrastructure, regardless of how individual IAM policies evolve.

The identity-level problem: The development team has limited IAM management permissions within the development account. The platform team needs developers to be able to create roles for their workloads, but can't let them create roles that exceed what it intended to authorize.

How they apply both controls:

The platform team attaches an SCP to the development account that denies sts:AssumeRole for roles in the production account from any principal in the development account, and explicitly denies actions on production resource ARNs. This SCP enforces account-level separation. Even if a developer inadvertently grants a development role access to production resources, the SCP prevents those actions from completing.

The platform team also attaches a permission boundary to the IAM management role that developers use to create other roles. The boundary limits that role to creating roles with policies drawn from an approved, pre-scoped set. Developers can provision service roles for their workloads. They can't attach AdministratorAccess or any policy outside the approved list to anything they create.

The result is layered enforcement. The SCP holds account-level separation. The permission boundary holds identity-level scoping within the account. Neither control is doing the other's job, and neither is sufficient alone. For a broader view of how these controls fit into a layered cloud security architecture, see The Architecture of Intent: Zones, Boundaries, and Baselines in the Cloud.

Common Mistakes

Treating them as alternatives. SCPs and permission boundaries address different scopes. An SCP doesn't help you scope a specific developer role within an account. A permission boundary doesn't enforce account-wide restrictions that hold for all principals. Choosing one and skipping the other leaves one layer of the problem open.

Forgetting that neither grants permissions. A common misconfiguration is attaching a permission boundary that allows a set of actions and assuming the principal now has those permissions. The boundary defines the ceiling. The principal still needs an identity-based policy with an explicit allow within that ceiling. Without the corresponding identity policy, access is blocked regardless of what the boundary says.

Assuming SCPs restrict the management account. SCPs don't apply to the management account. No SCP at the org or OU level blocks actions taken from the management account root. Organizations relying on SCPs as their sole org-wide guardrail have a real gap at the management account level.

Attaching permission boundaries without auditing for unconditional identity policies. A permission boundary on a role that still has AdministratorAccess attached does cap effective permissions, but the combination is easy to misread. Auditors reviewing the identity policy see full admin access; the boundary lives in a separate location and requires its own review step. Wherever possible, trim the identity policy to match the boundary so the effective permissions are legible in one place.

Neglecting service-linked roles in your enforcement model. SCPs don't restrict service-linked roles. If a service-linked role operates with permissions that span what your SCP restricts for human and machine principals, the behavior looks inconsistent and can create gaps that are difficult to explain during audits. Service-linked roles are AWS-managed by design, and they're outside SCP scope. Account for them explicitly in your enforcement model rather than assuming SCPs cover everything.

For more on how controls drift from frameworks over time, see Cloud Security Controls: What They Are, How They Map to Frameworks, and Where They Break Down.

Why Native

SCPs and permission boundaries answer enforcement questions that identity and access policies alone can't. Keeping them aligned with architectural intent as the environment evolves is where the operational weight lives: new accounts join the org, roles accumulate, permission boundaries age out of sync with the workloads they were written to cap, and SCPs get modified by different teams without a clear view of downstream effects.

Native connects the SCPs and permission boundaries already present in your AWS environment to the architectural intent behind them. When an SCP drifts from the policy it was meant to enforce, when a permission boundary no longer matches the workload it's attached to, or when a new role gets created without a boundary that your governance model requires, Native surfaces it. See how Native works across AWS, Azure, Google Cloud, and OCI.

FAQ

Can an SCP override a permission boundary?

No, and neither can a permission boundary override an SCP. They operate at different layers. An SCP applies to the account and sets the outer ceiling for what any principal in the account can do. A permission boundary applies to a specific identity and sets a narrower ceiling within that SCP-allowed space. A permission can only be exercised if the SCP allows it, the identity policy grants it, and the permission boundary (if one exists) allows it. All applicable layers have to be satisfied.

Can permission boundaries be applied to IAM groups?

No. Permission boundaries apply only to IAM users and IAM roles. They can't be attached to groups. Groups don't have permission boundaries, so membership in a group doesn't help a user escape their own boundary. The user's boundary still applies to every permission they hold, including those that come from group-attached policies.

Do SCPs affect cross-account role assumptions?

Yes, in both directions. When a principal in one account assumes a role in another account, the SCP of the source account applies to the assume-role action. The SCP of the destination account applies to what the assumed role can do in that account. Both account SCPs have to permit the action.

Can a permission boundary prevent privilege escalation?

Yes, and this is one of the primary reasons to reach for them. When you delegate IAM management to a team, attaching a permission boundary to the IAM management role ensures that team can't create roles or users with permissions that exceed what the boundary allows. Without a boundary, a principal with iam:CreateRole and iam:AttachRolePolicy can create a role with AdministratorAccess and then assume it.

How many SCPs can be attached to an account?

Five, including any SCPs inherited from parent OUs and the root. If an account sits inside an OU that's inside another OU, the SCP count applies across all inherited levels combined.

Do permission boundaries apply to AI agents and service roles?

Yes. If an agentic workload or CI/CD pipeline assumes a role with a permission boundary attached, the boundary applies to every action that role takes. This is directly relevant when scoping what an AI agent can reach and act on within a cloud environment. The boundary enforces the ceiling structurally, so the agent can't exercise permissions beyond what the boundary defines, regardless of how its identity policies are configured. For more on enforcing boundaries for AI workloads, see how Native approaches enabling AI for engineering.