Notifications
Clear all
Topic starter
03/06/2026 2:20 pm
TL;DR: AWS permission boundaries remain useful for delegated IAM creation, but they do not scale to org-wide least privilege because they must be applied identity by identity, according to Sonrai Security. SCPs solve the coverage problem, but safe enforcement depends on usage visibility, or teams risk breaking production while leaving privilege sprawl intact.
NHIMG editorial — based on content published by Sonrai Security: Why SCPs Beat Permission Boundaries for Org-Wide Least Privilege and How to Enforce It Safely at Scale
Questions worth separating out
Q: How should security teams enforce least privilege across large AWS organisations?
A: They should enforce least privilege at the organisation layer, not by relying on per-role controls alone.
Q: Why do permission boundaries fail as a scale control for cloud access?
A: Permission boundaries fail at scale because they must be attached to each identity individually.
Q: How do organisations know whether an SCP will break production?
A: They know by comparing proposed restrictions against observed identity activity, not by assuming the current policy set is accurate.
Practitioner guidance
- Map enforcement to the right layer Use permission boundaries for targeted delegation cases and SCPs for org-wide ceilings, so each control does the job it was designed to do.
- Inventory non-human identities before tightening policy Include service accounts, CI/CD roles, Lambda roles, and AI agents in the same access review cycle so hidden privilege does not escape governance.
- Base deny decisions on observed usage Collect usage telemetry before applying restrictive SCPs, then remove only permissions that are demonstrably idle or unnecessary in production.
What's in the full article
Sonrai Security's full blog post covers the operational detail this post intentionally leaves for the source:
- A side-by-side AWS policy walkthrough showing where permission boundaries stop and SCPs begin.
- A practical explanation of how Sonrai maps identity usage to safe deny decisions before enforcement.
- A cloud access workflow that ties least privilege to request-and-approve controls for overbroad permissions.
- Examples of how org-wide enforcement interacts with audits, compliance evidence, and developer workflow.
👉 Read Sonrai Security's analysis of SCPs versus permission boundaries for AWS least privilege →
SCPs vs permission boundaries: what IAM teams miss at scale?
Explore further
03/06/2026 2:26 pm
Permission boundaries are a delegation control, not an enterprise least-privilege model. They work when a team wants to cap what one identity can create or approve, but they fail as a scalable governance layer because coverage depends on entity-by-entity consistency. That makes them useful in narrow scenarios and unreliable as the backbone of org-wide cloud access governance. Practitioners should stop treating them as the default answer for fleet-wide enforcement.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments.
A question worth separating out:
Q: What is the difference between SCPs and permission boundaries in AWS governance?
A: SCPs cap the maximum permissions for every principal in an account, OU, or organisation, while permission boundaries cap one IAM entity at a time. SCPs are the better choice for org-wide guardrails, and boundaries are the better choice for specific delegation scenarios. They solve different problems and should not be treated as interchangeable.
👉 Read our full editorial: SCPs versus permission boundaries for org-wide least privilege
