What are AWS service control policies (SCPs)?

A service control policy (SCP) is an AWS Organizations policy that sets the maximum permissions available to any principal in a member account. It does not grant permissions — it defines the ceiling beyond which no IAM policy, role, or user can reach, regardless of what those policies say.

How do SCPs relate to IAM policies?

SCPs and IAM policies work as an intersection, not a union. Both must allow an action for it to succeed.

An identity in a member account needs permission from two sources simultaneously: the SCP attached to its account (or organizational unit) must not deny the action, and the identity’s own IAM policy must grant it. If either check fails, the request is blocked. This means an administrator cannot accidentally over-grant access by writing a permissive IAM policy if the SCP holds a tighter boundary.

What do SCPs actually protect against?

SCPs protect against privilege escalation and policy drift that would otherwise be undetectable at the account level.

Without SCPs, a sufficiently permissioned user in a member account can grant themselves or others any IAM permission, disable logging, or create resources in regions the organization does not use. SCPs let you lock down these classes of action at the organization level so they cannot occur regardless of what happens inside the account. Common uses include blocking access to unused regions, preventing changes to CloudTrail, and restricting which services member accounts can use at all.

What does a concrete SCP look like?

Blocking cloudtrail:StopLogging is one of the most common production SCPs:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyStopLogging",
      "Effect": "Deny",
      "Action": "cloudtrail:StopLogging",
      "Resource": "*"
    }
  ]
}

Attach this to the root of your AWS organization, and no identity in any member account — including account-level administrators — can disable CloudTrail. The management account itself is not subject to SCPs, which is one reason access to the management account should be tightly restricted separately.

Where do SCPs apply?

SCPs apply to organizational units (OUs) and individual accounts within AWS Organizations. A policy attached to an OU applies to all accounts under that OU, and a policy attached to an account applies only to that account.

SCPs do not apply to service-linked roles, to the management (payer) account, or to resource-based policies in some edge cases. Understanding these boundaries is important when modeling what an SCP will and will not cover.

Can SCPs be used in place of per-account guardrails?

SCPs are organization-level controls, not a substitute for account-level policy management. They set the envelope of what is possible, but they say nothing about whether an action inside that envelope is appropriate in a given context.

A team that needs to delete an S3 bucket during a planned migration has the same SCP boundary as a compromised credential attempting the same action. SCPs cannot distinguish intent, timing, or context. They also make break-glass exceptions awkward to implement: giving an emergency operator elevated access means either loosening the SCP for everyone in scope or building complex condition keys that are difficult to audit.

That gap — controlling what happens inside the permitted boundary, and adapting enforcement to context — is where intent-aware guardrails operate. Korvalis sits at the API layer to evaluate actions that SCPs allow but that may still carry unacceptable risk in a specific circumstance.