AWS service control policies expose the gap between guardrails and IAM

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Sonrai Security's blog post: AWS Service Control Policies work, the September 2025 IAM language update changed them, and SCPs sit beside IAM policies and RCPs.

Why it matters: It matters because cloud IAM teams need to understand the boundary between permission grants and org-level guardrails before precision policies create outage risk or leave privilege gaps unchecked.

Context

AWS Service Control Policies are org-level guardrails for cloud permissions, not permission grants themselves. In this article, the governance problem is the gap between what IAM policies allow inside an account and what SCPs can restrict across an organisation, especially after the September 2025 update expanded policy expressiveness.

The article’s central point is that more expressive SCPs do not automatically produce better governance. They can reduce excess privilege and tighten cloud controls, but they also increase the risk of policy logic that is hard to debug, hard to delegate safely, and capable of disrupting valid work if teams treat syntax as the whole control model.

For IAM and cloud security teams, the real question is whether org-level guardrails still remain understandable, testable, and recoverable once they use conditions, NotAction, NotResource, and resource-level scope. That is the operational boundary this guide is really about.

Key questions

Q: What breaks when AWS SCPs are written too broadly?

A: Broad SCPs can block legitimate engineering, support, or recovery activity because the policy ceiling applies across the organisation and can override downstream allows. The result is not just reduced access, but difficult troubleshooting when teams cannot tell whether a denial came from the SCP, the IAM policy, or the resource policy. That is why testing and rollback planning matter before enforcement.

Q: Why do org-level guardrails sometimes create outage risk in AWS?

A: Because SCPs control the maximum permissions available to principals, a mis-scoped deny can stop valid actions even when account-level IAM permissions exist. When the policy is inherited across many accounts and OUs, the operational impact scales quickly. The risk is highest when teams treat policy syntax as a security task rather than a production change.

Q: How do cloud teams know whether an SCP design is working?

A: An SCP is working when it blocks only the intended actions, leaves approved workflows intact, and remains understandable enough for security and platform teams to troubleshoot quickly. If engineers need repeated exceptions, if denials are hard to attribute, or if policy changes cause unexpected service failures, the control is too opaque to operate safely.

Q: When should organisations use RCPs instead of SCPs?

A: Use RCPs when the governance problem is resource-side access, such as controlling who can touch an S3 bucket, KMS key, or SQS queue. Use SCPs when the problem is the maximum privilege a principal can exercise across the organisation. Many cloud estates need both because they answer different questions.

Technical breakdown

How SCPs constrain permissions without granting them

AWS SCPs sit above account-level IAM policies and act as maximum-permission filters for principals in an organisation or OU. They do not grant access the way IAM policies do. Instead, they define what can never be permitted beyond the boundary set by the organisation. That distinction matters because teams often misread an SCP as an allow mechanism, when its real function is to cap effective privilege across accounts. In practice, the evaluation path is policy intersection, not policy replacement, so a single deny can override downstream allows. This makes SCPs powerful for central governance, but also unforgiving when teams do not model inheritance correctly.

Practical implication: Model SCPs as ceiling controls and test the effective permission path before deployment.

Why the September 2025 IAM language update changes guardrail design

The September 2025 update made SCPs materially more expressive by allowing conditions in allow statements, resource ARNs, NotAction with allow, NotResource, and wildcards anywhere in the action string. That does not just add convenience. It changes the design space for org-wide policy because teams can now express much narrower boundaries and carve-outs. The downside is that each added construct increases cognitive load and the chance of unintended policy interactions. A policy that is precise in intent can still be opaque in operation if the authoring team cannot reason through the exception paths and inheritance order cleanly.

Practical implication: Treat richer SCP syntax as a governance design change, not a formatting upgrade.

Where SCPs end and RCPs begin in cloud governance

SCPs govern what principals can do across the organisation, while RCPs govern what resources can be accessed and by whom. That distinction closes a common governance gap because some controls belong on the identity side and others belong on the resource side. AWS introduced RCPs in November 2024 to cover resource-side boundary questions that SCPs alone cannot answer, such as restricting access to an S3 bucket, KMS key, or SQS queue regardless of the resource policy. The practical lesson is that org-wide cloud governance now depends on aligning principal-side and resource-side guardrails, not assuming one policy family can solve both.

Practical implication: Use SCPs and RCPs together when principal control and resource boundary control are both in scope.

Threat narrative

Attacker objective: The objective is to exploit excess cloud privilege or policy confusion to reach resources that should have remained out of scope.

1. Entry begins when overly broad org-level policy scope or inherited account permissions leave principals with more usable access than intended.
2. Escalation occurs when unclear allow and deny logic, combined with complex inheritance, turns guardrails into hidden privilege paths or accidental outages.
3. Impact is either unauthorised use of cloud resources or operational disruption when a mis-scoped SCP blocks legitimate work across the organisation.

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

Org-level guardrails are only as effective as their interpretability: The article shows that SCPs are becoming more expressive at the exact moment cloud estates remain highly distributed. That creates a governance problem as much as a policy problem, because precision without operational clarity can increase outage risk and slow delegated decision-making. Practitioners should treat policy readability as part of the control, not as documentation afterthought.

Resource-side and principal-side governance are now separate control problems: SCPs do not solve resource access boundaries, and RCPs do not solve principal privilege boundaries. The discipline here is to stop treating “cloud guardrails” as one control and instead separate who can act from what can be touched. That split is essential for org-wide IAM governance in large AWS estates.

Policy expressiveness can widen the blast radius of mistakes: The September 2025 language additions give teams more ways to encode intent, but also more ways to encode hidden exceptions. That means policy authorship now behaves like a high-risk governance activity, not a routine administration task. Teams need stronger review, testing, and rollback discipline because subtle syntax differences can materially alter effective permissions.

Guardrail design has become a lifecycle issue, not a one-time configuration task: SCPs, IAM policies, and RCPs interact over time as accounts, OUs, and resource patterns change. Static review cadences will miss drift in large cloud estates. The practical implication is that cloud governance programmes must monitor policy evolution as an ongoing access-control lifecycle, not a periodic checklist.

Scope precision is the new least-privilege boundary: The article’s real signal is that least privilege in AWS is no longer just about denying excess access. It is about deciding whether the control belongs at the principal, resource, or organisational layer, and then proving that the resulting boundary still behaves as intended. Practitioners should re-evaluate where the organisation wants the guardrail to live before expanding policy complexity.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Read next: Agentic AI Identity Guide

What this signals

Scope precision is now the core cloud governance problem: As SCPs gain more expressive power, the hardest question is no longer whether AWS can enforce a boundary, but where that boundary should live. Teams that collapse principal, account, and resource control into one layer will create avoidable ambiguity in privilege review and incident response.

Cloud programmes should treat exception handling as a control surface, not an afterthought. Once conditions, NotResource, and richer allow logic enter the policy model, the ability to explain and reverse a policy becomes part of the security requirement.

For practitioners

• Map the control boundary before writing policy Separate principal restrictions, resource restrictions, and account-level permission grants before drafting SCPs so policy intent is not encoded in the wrong layer.
• Test inheritance and exception paths first Validate how allow and deny statements interact from root through OU to account, including NotAction and NotResource cases, before rollout.
• Keep a break-glass recovery role in the management account Use a tightly scoped management-account role with strong MFA and monitoring so a mistaken SCP does not strand administrators in member accounts.
• Pair SCPs with resource-side guardrails where needed Use RCPs when the governance question is who can touch a specific resource, and reserve SCPs for the maximum permissions of principals across the organisation.
• Document policy intent in plain English next to the JSON Record why an SCP exists, what exception it allows, and what business process it is protecting so future changes do not reverse the original control objective.

Key takeaways

• AWS SCPs are a ceiling on principal privilege, not a substitute for account-level IAM permissions or resource-side controls.
• The September 2025 language update makes guardrails more precise, but also increases the chance of hard-to-debug policy interactions.
• Cloud teams need to separate principal-side and resource-side governance so tighter policy does not become hidden outage risk.

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.
• 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.
• 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.
• Policy inheritance: Policy inheritance is the way higher-level controls flow down into lower-level environments unless explicitly restricted. In federated API governance, it determines whether local teams can tune settings without weakening mandatory security or compliance requirements.

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.