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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Sonrai Security's blog post: AWS permission boundaries are too granular for org-wide least privilege, while SCPs provide the organisational ceiling needed to cover every identity in scope.
Why it matters: For IAM, PAM, and cloud security teams, the practical question is not whether least privilege is desirable, but whether the chosen control can actually cover human, NHI, and workload identities consistently.
Context
AWS least privilege breaks down when the control is applied too close to the identity and too far from the organisation. Permission boundaries cap a role or user individually, which means coverage depends on every identity being configured and maintained correctly. In large AWS estates with human users, service roles, CI/CD identities, and AI agents, that per-entity model leaves gaps.
Service Control Policies shift the control point to the organisation, account, or OU level, so every IAM principal in scope inherits the ceiling automatically. The governance problem is no longer just policy design. It is deciding what can safely be denied when usage is distributed, permissions are inherited, and production risk is real.
Key questions
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. SCPs provide a consistent permission ceiling across accounts and organisational units, while permission boundaries remain useful for delegated IAM creation. The practical requirement is visibility into real permission usage, so teams can deny safely without breaking production.
Q: Why do permission boundaries fail as a least privilege strategy at scale?
A: They fail because coverage depends on every role or user being configured correctly and kept current. In large AWS estates, one missed attachment leaves a gap, and non-human identities created by automation make that gap hard to spot.
Q: What are the signs that an org-wide privilege model is not working?
A: Common warning signs are permissions sprawl, inconsistent application across identities, uncertainty about which privileges are actually used, and hesitation to enforce denies because production impact cannot be predicted. Those signals show the organisation lacks the visibility needed for safe restriction.
Q: When should teams use SCPs instead of permission boundaries?
A: Use SCPs when the control objective is organisation-wide least privilege across many accounts and identities. Use permission boundaries when the goal is narrower delegation, such as letting teams create roles without allowing them to exceed a predefined permission ceiling.
Technical breakdown
Why permission boundaries do not scale across AWS estates
Permission boundaries define the maximum permissions an IAM entity can receive, but they do not apply themselves. Every role or user must be attached individually, so a single missed identity becomes an uncontrolled exception. In practice, that makes boundaries a local control for delegation cases, not a governance mechanism for whole-organisation least privilege. They also do not solve the broader problem of unused permissions accumulated across thousands of roles.
Practical implication: Treat permission boundaries as a narrow delegation control, not the primary mechanism for org-wide privilege reduction.
How SCPs create an organisation-level permission ceiling
Service Control Policies sit above IAM policies and cap the maximum permissions that any principal in scope can have. Because they apply at the account, OU, or organisation level, they automatically cover existing and future identities without per-role attachment. Effective access becomes the intersection of what IAM grants and what the SCP allows, which makes SCPs structurally better suited to broad least-privilege enforcement. The trade-off is that denial must be grounded in real usage, not guesswork.
Practical implication: Use SCPs to enforce the upper bound of access across the AWS organisation, then validate denies against actual workload usage before rollout.
Why usage visibility is the safety layer for restrictive policies
The technical challenge is not writing an SCP, but knowing what can be denied without interrupting production. Large cloud estates contain dormant permissions, inherited access, and non-human identities that bypass human review processes. Without usage telemetry, teams either over-restrict and cause outages or under-restrict and preserve privilege sprawl. This is where policy design and operational evidence must meet: least privilege becomes enforceable only when actual access patterns are visible.
Practical implication: Feed SCP design with live usage data so denial decisions are based on observed activity rather than static entitlements.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Permission boundaries are a delegation control, not an organisational governance model. They work when a team wants to cap what a developer-created role can do, but they assume each identity will be configured correctly and kept current. That assumption fails at AWS scale because coverage depends on manual attachment, and manual attachment breaks under identity sprawl. The implication is that programme design must distinguish local guardrails from true org-wide privilege control.
SCPs are the correct enforcement layer when least privilege must cover every principal in scope. By sitting above IAM policies, they cap effective access across humans, NHIs, and future identities without relying on per-entity hygiene. That makes them especially relevant in estates where service roles, automation, and AI-related workloads accumulate faster than review processes can keep up. Practitioners should read SCPs as a structural ceiling, not a replacement for identity governance.
Org-wide least privilege fails when usage visibility is absent. Restrictive policies are only as safe as the evidence used to authorise them, and cloud teams still struggle to separate active permissions from dormant ones. Usage visibility gap: this is the point at which policy intent outpaces operational truth, leaving teams either unwilling to enforce or likely to break production. The practitioner conclusion is clear: the control problem is as much observability as policy.
Non-human identities are the stress test for AWS permission models. They are created quickly, inherit privileges silently, and often sit outside human-driven access review cadences. A governance model that depends on identity-by-identity review will always lag behind the cloud account factory. For IAM programmes, the lesson is to govern the ceiling centrally and review the exception paths deliberately.
Least privilege at scale is now a cloud identity lifecycle problem. The article shows that enforcement cannot stop at creation, because permissions must be continuously bounded as accounts, roles, and workloads change. That aligns with NIST CSF access control discipline and with cloud governance expectations in SOC 2 and ISO 27001 environments. Practitioners should treat least privilege as an ongoing operating model, not a one-time policy exercise.
From our research library:
- 49% of IT professionals would prioritise improving privileged access management if the decision were theirs alone, according to Netwrix's 2023 Hybrid Security Trends Report.
- Read next: Agentic AI Identity Maturity Model
What this signals
Usage visibility is the real gating factor for org-wide least privilege. Central policy only becomes safe when teams can see which permissions are active, dormant, or inherited across the AWS estate. Without that evidence, deny-list enforcement turns into guesswork and the organisation will either stall or over-restrict.
Non-human identities expose the weakness of identity-by-identity governance. Service roles, CI/CD identities, and cloud workloads are created too quickly for manual boundary attachment to keep pace. Org-level guardrails must therefore assume that some identities will never pass through human review at the same speed as workload creation.
For practitioners
- Use SCPs as the org-wide ceiling Apply Service Control Policies at the account or OU level so every IAM principal in scope is constrained consistently, including identities created after the policy goes live.
- Map where permission boundaries still add value Reserve permission boundaries for delegation cases where teams need to create roles without being able to exceed a defined maximum permission set.
- Inventory non-human identities before tightening controls Catalogue service roles, CI/CD identities, Lambda roles, and AI agent identities so you know which principals are covered by central guardrails and which ones are still drifting.
- Validate denies against real usage data Use activity telemetry to identify dormant permissions and test proposed SCP denies against observed workloads before enforcement, so production impact is predictable.
- Separate policy ownership from account ownership Assign clear responsibility for org-level permission ceilings, because split ownership between security, cloud platform, and governance teams is a common reason enforcement stalls.
Key takeaways
- Permission boundaries are useful in narrow delegation cases, but they are not a dependable model for organisation-wide least privilege in large AWS estates.
- The main operational risk is not policy syntax, it is incomplete coverage and unsafe denial decisions when usage data is missing.
- SCPs can enforce a stronger ceiling across the organisation, but they only become safe when teams validate restrictions against real access patterns.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0, CIS Controls v8 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article is about enforcing least privilege across AWS identities. |
| Recommendation — Apply AC-6 to cap effective permissions and remove excess access from AWS identities. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The piece centres on organisation-wide permission ceilings and entitlement control. |
| Recommendation — Use PR.AA-05 to govern entitlements centrally across accounts and identities. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article focuses on identity sprawl and consistent control of cloud accounts and roles. |
| Recommendation — Apply CIS-5 to inventory accounts and remove unmanaged access paths. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Org-wide access ceilings and governance map directly to ISO access control requirements. |
| Recommendation — Define and enforce access control rules for cloud identities under Annex A. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article is about cloud IAM governance across accounts and principals. |
| Recommendation — Use IAM domain controls to centralise entitlement governance across the cloud estate. | ||
Key terms
- Permission Boundary: A permission boundary is the enforceable limit on what an identity can do, regardless of how it behaves. For AI agents, this boundary matters more than session logs because it determines whether an action is possible in the first place.
- Service Control Policy: An AWS Service Control Policy is an organisation-level guardrail that caps the maximum permissions available to accounts and identities in scope. It does not grant access on its own, but it shapes the outer boundary of what IAM policies can ever allow, which makes it central to org-wide least privilege.
- Usage Visibility: The ability to see how identities, credentials, and resources are actually being used across the environment. It is the evidence layer that turns access governance from assumption into decision, and it is essential for removing dormant access safely.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 3, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org