SCPs versus permission boundaries for org-wide least privilege

At a glance

What this is: This analysis argues that AWS Service Control Policies are the better mechanism for org-wide least privilege because permission boundaries fail when coverage depends on per-identity configuration.

Why it matters: It matters to IAM teams because the same governance gap that leaves human roles over-permissioned also affects service accounts, CI/CD identities, and other NHIs that slip past manual review.

👉 Read Sonrai Security's analysis of SCPs versus permission boundaries for AWS least privilege

Context

AWS least-privilege programmes often fail for a simple reason: the control is attached to the wrong layer. Permission boundaries cap what one role or user can do, but they do not create org-wide guardrails, so coverage depends on perfect attachment and perfect maintenance. That makes the model brittle in environments where identities are created continuously and reviewed inconsistently.

The article frames the real issue as governance, not syntax. For IAM teams, the question is whether enforcement lives at the identity level or at the organisation level, and whether the control can extend across human users, service accounts, and other non-human identities without relying on manual completeness.

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 scale control for cloud access?

A: Permission boundaries fail at scale because they must be attached to each identity individually. In large environments, one missed role creates a coverage gap, and that gap is enough to leave privilege unchecked. They are a local safeguard, not a durable enterprise control for sprawling cloud estates.

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. Usage analysis reveals which permissions are active, dormant, or only present because of inheritance. Without that evidence, deny-list policies can disable workloads that nobody realised were dependent on them.

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.

Technical breakdown

Why permission boundaries break down in large AWS estates

Permission boundaries set a maximum permission ceiling for an individual IAM entity. That sounds strong until scale enters the picture, because every new role, user, or workload needs explicit attachment. They also do not govern every policy type in the same way, which means the effective control surface is narrower than many teams assume. In large AWS organisations, the operational failure is not policy syntax, but coverage drift. The boundary exists only where a team remembers to place it, so the control becomes a local safeguard rather than an enterprise guardrail.

Practical implication: treat permission boundaries as a delegation control, not as your org-wide least-privilege backbone.

How SCPs enforce an organisation-wide permission ceiling

Service Control Policies sit above individual identities and cap the maximum permissions allowed within an account, organisational unit, or full AWS organisation. They do not grant access, but they constrain every IAM principal in scope, which is what makes them structurally different from per-entity controls. The key architectural point is that the effective permission becomes the intersection of IAM policy and SCP. That means SCPs can establish a consistent ceiling for human and non-human identities alike, provided the organisation understands what can safely be denied.

Practical implication: use SCPs to define the outer boundary of access, then allow IAM policy to decide the inner grants.

Why usage visibility is the real enabler of safe least privilege

The hardest problem is not writing restrictive policies. It is knowing which permissions are actively used and which are just inherited baggage. In cloud estates with thousands of active permissions, a deny-only approach can create outages if the team guesses wrong. Usage-based analysis changes the question from theoretical entitlement to observed activity. That is the mechanism that turns least privilege from a paper policy into something enforceable without constant firefighting. For AI agents and other NHIs, the same logic applies, because unmanaged breadth is often hidden inside automated workflows.

Practical implication: measure real permission usage before tightening controls, especially where NHIs and automation are expanding the attack surface.

Threat narrative

Attacker objective: The attacker aims to convert fragmented permission governance into broad cloud control by exploiting identities whose access ceilings were never enforced consistently.

1. Entry occurs through over-granted cloud identities, usually when broad access is inherited faster than it is reviewed.
2. Escalation follows when the identity can move laterally or create additional permissions because the ceiling is only enforced on some entities.
3. Impact is organisation-wide privilege sprawl, which increases blast radius, complicates audits, and makes containment slower when an account is abused.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Org-wide least privilege belongs at the control-plane layer, not the role layer. SCPs change the enforcement model by constraining every principal in scope, including identities created after the policy is written. That matters because cloud estates grow faster than manual IAM review cycles, and non-human identities often escape identity-level review altogether. The implication is a shift from identity-by-identity remediation to centrally enforced permission ceilings across the organisation.

Non-human identity sprawl is the reason least-privilege debates keep recurring. Service accounts, CI/CD roles, Lambda permissions, and AI-driven workloads expand faster than teams can classify them, and the article is right to call out that these identities often sit outside human IAM review habits. The result is not just excess access, but weak governance assumptions about who owns the access decision. Practitioners should treat NHI coverage as a core design requirement, not a cleanup exercise.

Identity governance fails when the organisation cannot see what permissions are actually used. The hardest part of safe restriction is not the policy mechanism itself, but the evidence needed to deny with confidence. That creates a structural dependence on telemetry and usage context, which is why enforcement and visibility have to be designed together. The implication is clear: least privilege at scale requires operational proof, not just policy intent.

From our research:

• 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.
• If you are mapping this to broader AI identity risk, see 52 NHI Breaches Analysis for the recurring privilege and visibility patterns that make org-wide guardrails necessary.

What this signals

With 70% of organisations granting AI systems more access than comparable human employees, the governance gap is no longer limited to human IAM. The same pattern shows up in cloud estates where non-human identities inherit broad permissions faster than teams can review them, which is why org-level guardrails matter more than per-identity tuning.

Permission ceiling drift: when the organisation cannot prove which identities actually need access, least privilege becomes a policy intention rather than an enforceable state. That is the point at which SCPs, usage telemetry, and lifecycle governance have to be treated as one control system rather than separate projects. For IAM teams, the priority is to shrink the gap between granted access and observed need before the next expansion wave.

As cloud environments absorb more automation, the practical question shifts from whether access is excessive to whether the organisation can still see, explain, and defend it. The next control maturity step is not more review cadence alone; it is better evidence about which identities, including NHIs, can safely be constrained without operational fallout.

For practitioners

• 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.
• Separate delegation from privilege reduction Let developers create roles within a controlled boundary, but reserve org-wide permission ceilings for centrally managed guardrails and audit evidence.

Key takeaways

• Permission boundaries are useful for specific IAM delegation cases, but they do not solve org-wide least-privilege enforcement.
• SCPs create a central permission ceiling across AWS organisations, which is why they scale better as cloud estates expand.
• Safe least privilege depends on real usage visibility, because deny decisions without telemetry risk breaking production.

Key terms

• 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.
• Permission Boundary: A permission boundary is an IAM control that limits the maximum permissions of a single user or role. It is useful for delegation, but it only works where it has been attached, so it does not scale as a complete governance model for large cloud estates or fast-moving non-human identity populations.
• Non-Human Identity: A non-human identity is any machine-recognisable identity used by software, workloads, pipelines, or agents to authenticate and receive access. In cloud governance, NHIs are the identities most likely to expand quickly, evade manual review, and accumulate privilege unless the organisation designs for them explicitly.
• Least Privilege: Least privilege is the practice of giving an identity only the access it needs to do its job, and nothing more. For cloud and NHI environments, it must be based on observed usage and enforced consistently, otherwise it becomes a policy statement rather than a control that actually reduces blast radius.

Deepen your knowledge

SCP enforcement, NHI visibility, and least-privilege design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building cloud guardrails across human and non-human identities, it is worth exploring.

This post draws on content published by Sonrai Security: Why SCPs Beat Permission Boundaries for Org-Wide Least Privilege and How to Enforce It Safely at Scale. Read the original.