6 mins to read
The cloud moves fast. Accounts multiply, roles get spun up for every new service, and somewhere along the way, the permissions inventory balloons into the thousands. Most enterprise AWS environments are sitting on a permissions sprawl problem they can’t fully see and the tools meant to contain it weren’t all built for the same job.
Permission boundaries are one of those tools. They help in specific cases. But ask any security team trying to enforce least privilege across hundreds of accounts and thousands of identities, and you’ll hear the same thing: boundaries don’t scale. They have to be applied identity by identity, and one missed role is a coverage gap.
Service Control Policies (SCPs) are built for the scale problem boundaries can’t solve. But most teams hesitate to deploy them because the risk of breaking production is real. Below we’ll review:
- Why permission boundaries don’t scale for org-wide enforcement
- What SCPs control and where they fit
- Why most teams struggle to deploy SCPs safely
- How to enforce least privilege safely using usage-based insights and native cloud controls
What Are AWS Permission Boundaries?
A permission boundary is an IAM feature that sets the maximum permissions an IAM user or role can have. The IAM policy says what an identity can do. The boundary caps what they’re allowed to do, regardless of what the policy says. If the policy grants access to S3 and CloudWatch but the boundary only includes S3, CloudWatch access is voided.
A few things worth knowing about boundaries:
- They’re applied per entity — every user or role has to be configured individually
- They don’t affect resource-based policies, SCPs, or session policies
- They’re useful when delegating IAM creation to developers without letting them escalate privilege beyond a set ceiling
- Coverage depends entirely on how consistently they’re applied
That last point is where most enterprises run into trouble. Boundaries work great for the identities they’re attached to. They do nothing for the ones they’re not.
What Are AWS SCPs?
Service Control Policies are organization-level policies that cap the maximum permissions for every account, organizational unit (OU), or the full AWS organization. Unlike boundaries, SCPs don’t need to be applied per identity. They apply to every IAM principal in scope automatically; human, non-human, existing, or created tomorrow.
Key things to understand about SCPs:
- They apply at the account, OU, or organization level, and inheritance flows down the hierarchy
- They work alongside IAM policies – the effective permission is the intersection of both
- The AWS management account is not affected by SCPs
- SCPs restrict permissions but do not grant them
SCPs sit at the top of the permission hierarchy. Even if an IAM policy grants something, an SCP denial overrides it. That’s exactly what you want for org-wide guardrails; a ceiling that no individual policy can break through.
Deny statement attached at Production OU and its impact on Account BSCPs vs Permission Boundaries: Side-by-Side
| Permission Boundaries | SCPs | |
| Scope | Per IAM entity | Per account, OU, or org |
| Coverage | Only where manually applied | All identities in scope |
| Maintenance | High, per-entity updates | Centrally managed |
| Non-human identities | Manual per role | Covered automatically |
| Org-wide enforcement | No | Yes |
Permission boundaries are the right tool for specific delegation use cases like handing developers the ability to create roles without letting them grant themselves more than they should have. SCPs are the right tool for org-wide least privilege enforcement.
The Identity Type Nobody Is Covering
In most AWS environments, non-human identities now outnumber human ones and the gap is widening. Service accounts, Lambda roles, CI/CD pipelines, and AI agents get created rapidly, often with broad permissions that nobody revisits.
Permission boundaries are rarely applied consistently to these identities. They’re created by automation, attached to ephemeral workloads, and live outside the human-driven IAM review processes that boundaries depend on. Privilege gets inherited, lateral movement opportunities open up, and most of it never shows up “on paper.”
SCPs apply to every IAM principal regardless of type. That’s a structural advantage, but it still requires confidence in what can actually be restricted without breaking something.
Why Most Teams Struggle to Use SCPs for Least Privilege
The technical mechanics of SCPs aren’t the hard part. AWS documentation is solid, the policy syntax is familiar, and creating an SCP in the console takes minutes. The hard part is deploying them safely at scale. Large AWS organizations have hundreds of accounts, thousands of roles, and thousands of active permissions across services.
In that environment, the question isn’t “can we write an SCP?”, it’s “what can we deny without taking something down?” Teams hit a few common walls:
- They can’t confirm which permissions are actively used versus dormant
- Deny-list SCPs risk breaking production services nobody flagged
- Overly permissive SCPs leave the original risk in place
- Overly restrictive SCPs cause outages and slow down developers, who then route around the controls
There’s also the responsibility question. Who owns SCP strategy? Is it the security team, the cloud platform team, governance? In most organizations, it’s split, and the lack of clear ownership means SCPs either get deployed too cautiously or not at all. Many enterprises end up delaying org-wide SCP enforcement indefinitely.
How Sonrai Automates Org-Wide SCP Deployment
Writing an SCP isn’t the bottleneck. Knowing what’s safe to restrict is. Sonrai provides the context that makes confident SCP deployment possible.
- Maps every identity across the AWS organization — human, non-human, and AI agents
- Continuously analyzes real permission usage across those identities
- Identifies unused or risky permissions based on actual activity, not theoretical access
- Validates what can be restricted without impacting production workloads
Once proper boundaries are defined based on real usage, Sonrai enforces them using native cloud controls like SCPs, without per-role manual effort. The intersection of identity visibility and usage data is what turns SCPs from a feature most teams avoid into a control they can actually operationalize.
Least Privilege and SCP Enforcement
Sonrai enforces a known-good permission baseline per identity called Least Privilege. It’s the minimum set of permissions an identity actually needs to do its job based on observed usage and policy decisions.
Here’s how it works in practice:
- SCPs enforce least privilege across the organization
- Any access outside the state requires a request-and-approve workflow (JIT)
- Permissions can be restored instantly when needed, without permanent over-provisioning
- Every access change is tracked and tied to a policy decision
This eliminates the trade-off between security and developer velocity. Developers don’t lose access they need and they request it through ChatOps and get it on the fly. Security doesn’t carry permanent over-provisioning as the cost of avoiding tickets. The result is a controlled, auditable permission model that holds up at scale.
What This Means for Audits and Compliance
Org-level enforcement backed by usage data produces something auditors actually want to see: a permission ceiling for every identity, documented and enforced by native cloud controls.
That gives you:
- A clearly defined permission ceiling for every identity in the organization
- Documented enforcement of least privilege principles
- Full visibility into who accessed what and why
- Policy-driven access controls aligned with frameworks like SOC 2, ISO 27001, PCI DSS, and HIPAA
Instead of producing evidence after the fact, the enforcement model is the evidence.
Conclusion
Permission boundaries serve a purpose. SCPs are the right mechanism for org-wide least privilege enforcement. But enforcement without context is risky and that’s why so many teams stall out.
The real challenge isn’t applying SCPs. It’s knowing what can be restricted safely. Sonrai solves that by combining identity visibility, usage analysis, and native enforcement into a single workflow so you can shrink the permission surface across your AWS organization without breaking what’s running on top of it.
Frequently Asked Questions
Do permission boundaries enforce least privilege across an AWS org?
No. Permission boundaries are applied per IAM entity, which means coverage is only as good as how consistently they’re attached. In environments with thousands of roles, especially non-human ones created by automation, boundaries leave gaps. They’re useful for specific delegation cases, not org-wide enforcement.
What is the difference between SCPs and IAM policies?
IAM policies grant permissions to users, groups, and roles. SCPs restrict the maximum permissions any identity in an account, OU, or organization can have. IAM policies say what an identity can do; SCPs cap what’s allowed. The effective permission is the intersection of both.
Do SCPs apply to the AWS management account?
No. The AWS management account is not affected by SCPs, even if the account is included in an OU with an SCP attached. This is why AWS recommends reserving the management account for admin tasks only and applying SCPs at the OU level.
Can SCPs and permission boundaries be used together?
Yes, and in many environments they should be. SCPs set the org-wide ceiling. Permission boundaries handle specific delegation scenarios where developers need to create roles without escalating privilege. They solve different problems and complement each other when used for their intended purposes.
Why do many AWS organizations not use SCPs for least privilege enforcement?
The barrier is rarely the policy syntax. It’s the risk of breaking production. Without visibility into which permissions are actively used, deny-list SCPs can take down workloads nobody flagged. Most teams either deploy SCPs too cautiously to be effective, or delay enforcement entirely while they figure out what’s safe to restrict.
Will automating SCP deployment disrupt developer workflows?
Not when it’s done with usage context. Sonrai’s Accepted State defines a per-identity baseline based on real activity, so developers keep the access they actually use. Anything outside that baseline goes through a request-and-approve workflow in ChatOps, with permissions restored on the fly. Guardrails get tighter without the friction.
