AWS service control policies expose the gap between guardrails and IAM

At a glance

What this is: This is an AWS SCP guide that explains how org-level guardrails restrict maximum permissions and why the 2025 policy-language update changes governance precision.

Why it matters: It matters because IAM, PAM, and cloud governance teams need to understand where principal-level controls end, where resource-side controls begin, and how to avoid over-restricting legitimate cloud operations.

By the numbers:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Sonrai Security's guide to AWS SCPs and org-level cloud guardrails

Context

AWS service control policies are org-level guardrails that define the maximum permissions principals can exercise across accounts. The governance problem is not access grant alone, but how to prevent inherited privilege, account sprawl, and policy drift from turning cloud flexibility into uncontrolled blast radius.

This matters to cloud IAM and privileged access teams because SCPs sit above account-level IAM policies, while resource control policies add a separate layer on the resource side. In practice, teams need to understand where principal governance ends and resource governance begins before they can enforce least privilege without breaking delivery.

The September 2025 update gives SCPs full IAM language support, which makes them far more expressive but also easier to misuse. That raises the bar for policy design, testing, and ownership across DevOps, security, and governance functions.

Key questions

Q: How should teams implement AWS SCPs without breaking cloud delivery?

A: Start with a narrow OU, simulate the policy against real workloads, and separate guardrail intent from enforcement syntax. Treat SCPs as a ceiling on permissions, not a replacement for IAM, and keep rollback and exception handling documented before rollout reaches production.

Q: Why do AWS SCPs create governance value for cloud IAM programmes?

A: They create an organisation-wide ceiling on what principals can do, which helps stop privilege creep across accounts. That matters when inherited access and account sprawl make local IAM policies too easy to over-grant. The control becomes most valuable when paired with resource-side boundaries and clear ownership.

Q: What breaks when teams rely on SCPs without resource control policies?

A: They can limit identity actions but still leave resources reachable through permissive bucket, key, or queue policies. That creates a gap between what an identity can do and what a resource will accept, which is exactly where cloud exposure often hides.

Q: Who should own cloud guardrail policy decisions in a large organisation?

A: Ownership should be shared across security, platform, and DevOps because SCPs affect delivery as well as protection. If one team writes the policy and another team discovers the outage, the organisation has governance without operational accountability.

Technical breakdown

How AWS SCPs constrain principal permissions across an organisation

Service control policies do not grant permissions. They set an outer boundary on what users, roles, and root in member accounts can ever do, regardless of the permissions inside the account. That distinction matters because IAM policies answer what is allowed within an account, while SCPs answer what is even possible at the organisation or OU level. Because SCPs inherit down the hierarchy, a single deny or missing allow can affect many accounts at once. The 2025 syntax update gives teams finer control, but also increases the risk of unreadable policy logic if statements are stacked without clear intent.

Practical implication: Model SCPs as global permission ceilings and test them in isolated OUs before broad rollout.

Why resource control policies close a different cloud governance gap

RCPs govern who can touch a resource and under what organisational boundary, while SCPs govern what principals may do. That separation is useful because many cloud failures come from assuming one policy type can solve both identity and resource control. An org can restrict a principal well yet still leave a bucket, queue, or key too broadly reachable through its resource policy. RCPs address that blind spot on the resource side, especially for services such as S3, KMS, Secrets Manager, and SQS. The key design point is that principal scope and resource scope are different governance problems, not interchangeable ones.

Practical implication: Use SCPs and RCPs together when you need both identity-side and resource-side boundaries.

Why the 2025 IAM language expansion raises both precision and complexity

The new support for conditions in allow statements, NotAction in allow, NotResource, and resource ARNs inside SCPs gives architects much more expressive policy options. That precision can reduce overbroad denies, but it also makes troubleshooting harder because a single policy can now encode several layers of exception logic. In mature environments, the failure mode is no longer only missing guardrails. It is also hidden policy interaction, where legitimate activity is blocked by a policy chain that nobody can easily reason through. Documentation and intent capture become operational controls, not just nice-to-have notes.

Practical implication: Require plain-English intent notes and policy simulation before any complex SCP reaches production.

Threat narrative

Attacker objective: The attacker aims to expand reach across accounts and resources by exploiting governance gaps between principal permissions and resource boundaries.

1. Entry occurs when inherited cloud permissions or poorly scoped account policies give an identity more reach than the business intended.
2. Escalation follows when excessive privilege crosses account boundaries or survives because the org has no resource-side boundary to stop it.
3. Impact is lateral movement, service disruption, or sensitive resource exposure across a multi-account AWS estate.

Breaches seen in the wild

• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

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

NHI Mgmt Group analysis

Org-level guardrails fail when teams treat principal governance and resource governance as the same control problem. SCPs restrict what identities can do, but they do not solve how resources are exposed through their own policies. That means many cloud programmes still carry a false sense of coverage if they rely on one layer alone. The practical implication is that cloud identity design must be evaluated as a two-sided boundary model, not a single permissions stack.

The September 2025 SCP language expansion creates policy precision debt. More expressive syntax reduces the need for broad deny statements, but it also increases the number of ways a policy can become opaque to operators. When policy intent is not documented in plain English, teams inherit governance they cannot safely change. The implication is that policy readability becomes a security property, not just a documentation preference.

Least privilege in AWS is now an orchestration problem, not a static policy problem. Hierarchical inheritance, account sprawl, and the split between IAM, SCPs, and RCPs mean entitlement decisions are distributed across multiple control planes. That is why cloud governance programmes need shared ownership between security, platform, and DevOps rather than isolated policy authorship. Practitioners should treat cloud permission design as continuous governance, not one-time hardening.

Resource-side control is the missing piece in many org-wide identity programmes. SCPs can stop a principal from doing too much, but they cannot by themselves ensure that a resource only accepts the right organisational context. RCPs fill that gap where AWS supports them, especially for sensitive services such as KMS and Secrets Manager. The implication is that mature cloud IAM now requires resource governance to sit alongside identity governance, not behind it.

From our research:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, 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, according to the 2026 Infrastructure Identity Survey.
• For the governance pattern behind this shift, see Ultimate Guide to NHIs for the lifecycle controls that keep access scoped as environments grow.

What this signals

Policy precision is becoming a cloud governance differentiator. As AWS SCPs gain more expressive language, the operational question shifts from whether teams can write a restrictive policy to whether they can still reason about it after exceptions stack up. That is the same structural problem identity teams face when entitlement logic becomes too distributed to audit in one pass.

With 70% of organisations already granting AI systems more access than human employees, per the 2026 Infrastructure Identity Survey, the appetite for guardrails is rising faster than programme maturity. Cloud teams that cannot separate identity ceilings from resource boundaries will keep discovering the gap only after an incident or an outage.

The next maturity step is not just tighter deny rules. It is a governance model that joins policy authoring, simulation, ownership, and review across identity and resource layers before privilege drift becomes operational debt.

For practitioners

• Map principal and resource boundaries separately Document which controls are meant to cap identity permissions and which are meant to constrain resource access. Treat SCPs as permission ceilings and RCPs as resource-side boundaries so teams do not assume one policy type covers both.
• Simulate SCP changes before organisation-wide rollout Test policy inheritance in a sandbox OU and validate allow, deny, NotAction, and NotResource behaviour against real workloads. Keep a clear rollback path because a malformed SCP can disrupt member accounts quickly.
• Write plain-English intent alongside every complex policy Store the business purpose, intended exceptions, and affected services next to the SCP definition. When policy logic mixes conditions and exceptions, readable intent is the control that prevents accidental lockouts.
• Keep a break-glass recovery role outside normal change flow Maintain a tightly scoped administrative path in the management account with strong MFA and alerting so a bad SCP can be corrected without waiting on external support.

Key takeaways

• AWS SCPs are ceiling controls, not grant controls, so they only work when teams understand how they interact with IAM and resource policies.
• The September 2025 IAM language expansion improves precision but also raises the risk of unreadable, hard-to-debug policy logic.
• Practitioners should separate principal governance from resource governance, test policy inheritance, and keep recovery paths ready before rollout.

Key terms

• Service Control Policy: An SCP is an organisation-level AWS policy that sets the maximum permissions available to accounts, users, and roles beneath it. It does not grant access on its own. Instead, it acts as a guardrail that constrains what other IAM policies can ever allow.
• Resource Control Policy: An RCP is an AWS organisation-level control that limits how resources can be accessed, rather than limiting only the actions of identities. It complements SCPs by enforcing resource-side boundaries for services that expose sensitive data or control planes.
• Policy Inheritance: Policy inheritance is the way higher-level AWS controls flow down through organisations, OUs, and accounts. In practice, it means one policy decision can affect many workloads at once, so careful scoping and testing are essential to avoid accidental service disruption.
• Break-glass Role: A break-glass role is a tightly controlled emergency access path used when normal administration is blocked. In cloud governance, it should be heavily scoped, monitored, and protected so it can restore control without becoming a standing privilege path.

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 responsible for identity security strategy or governance maturity, it is worth exploring.

This post draws on content published by Sonrai Security: AWS Service Control Policies (SCPs): A Complete Guide for 2026. Read the original.