SCP Allow-List Still Permits Everything When FullAWSAccess Stays Attached

Symptom

A newly attached allow-list Service Control Policy shows as active against an organizational unit (OU) in AWS Organizations, yet IAM principals in every account beneath that OU can still call API actions the policy was written to block. Engineers who created the SCP to limit member accounts to a short list of approved services — typically EC2, S3 and CloudWatch — find that unrelated services such as IAM, Lambda or RDS remain fully reachable. The console confirms the policy is attached and its JSON validates, and the policy simulator run against the SCP in isolation reports the expected restriction. Despite this, live calls from a role in an affected account succeed where they should be denied.

False Assumption

The team assumed that attaching a restrictive SCP to an OU is sufficient on its own to constrain what that OU’s accounts can do, in the same way that attaching a restrictive IAM policy narrows a role’s permissions. This treats SCPs as if the most recently attached policy overrides earlier, more permissive ones. It does not, and nothing in the Organizations console surfaces this distinction: both policies are simply listed as “attached”, with no indication of how they will be combined when a request is evaluated.

Root Cause

The default FullAWSAccess policy was never detached from the organizational unit, and AWS Organizations combines multiple SCPs attached to the same target differently depending on statement type. Explicit Deny statements always apply regardless of any other attached policy. Allow statements do not work the same way: when more than one non-deny SCP is attached to the same OU or account, the effective set of permitted actions at that level is the union of what each individual policy allows, not the intersection. Because FullAWSAccess allows every action on every resource, its continued presence beside the new allow-list policy means the union is still “every action”, and the restriction is never enforced at that level.

This combination behaviour is a stable characteristic of SCP evaluation, but the exact mechanics — including how newer policy types such as resource control policies interact with SCPs — should be reconfirmed against current AWS Organizations documentation for the account’s applicable policy set before this explanation is relied on in a specific environment.

Impact

Every account under the affected OU keeps unrestricted API access despite the guardrail team’s allow-list, so any action the allow-list was meant to block still succeeds without error or warning. There is no failed API call and no CloudTrail deny event, because from the perspective of policy evaluation nothing is actually being denied. Teams relying on the guardrail as a compliance or blast-radius control will report it as active while it provides no restriction at all, and the gap typically surfaces during an unrelated audit, an incident investigation, or a side-by-side comparison with a correctly configured OU.

Diagnosis

Confirm the presence of FullAWSAccess before attributing the failure to any other cause, and compute AWS Organizations’ own merged view of permitted actions rather than trusting the new policy’s JSON alone.

• List every SCP attached to the target with aws organizations list-policies-for-target and confirm whether the default FullAWSAccess policy is present alongside the new allow-list policy.
• Request the merged effective policy for a representative account with aws organizations describe-effective-policy and compare its allowed actions against the intended allow-list.
• Check CloudTrail for the account: the absence of any SCP-attributed AccessDenied events for actions the allow-list should have blocked is a strong indicator that the restriction is not being enforced.

Correction

Detaching the default FullAWSAccess policy from the OU, but only after confirming the allow-list SCP explicitly permits every action existing workloads depend on, is what restores the intended restriction. Because SCPs never grant permissions on their own, removing FullAWSAccess without a verified, complete allow-list converts a silent over-permission failure into a sudden, wide-scale denial failure across every account in the OU. The safer sequence is to build and exhaustively test the allow-list against a non-production OU first, and only then detach FullAWSAccess from the production target.

Validation

Validation means proving that out-of-scope API calls fail with an SCP-attributed AccessDenied error while every previously working, in-scope action still succeeds. Re-run the effective-policy check after detaching FullAWSAccess and confirm the merged allowed-action set now matches the intended allow-list. Then exercise a representative sample of production workloads’ actual API calls, not just the actions named in the allow-list, because a workload can depend on an action the allow-list author did not anticipate.

• Re-run describe-effective-policy against the same representative account and confirm the merged document no longer includes out-of-scope actions.
• From a role inside an affected account, attempt one in-scope call (expect success) and one out-of-scope call (expect a denial referencing the SCP).
• Run the organisation’s standard workload smoke tests against every account in the OU before treating the change as complete.

Rollback

If detaching FullAWSAccess breaks a legitimate workload, reattaching it immediately to the same target restores the pre-change permission state without waiting for a full incident review. Because SCPs are additive constraints layered over existing IAM permissions, reattaching FullAWSAccess cannot itself grant anything a role did not already hold through IAM; it simply removes the SCP-level restriction that was introduced, making the rollback low-risk and immediately reversible.

• Reattach the default policy: aws organizations attach-policy --policy-id p-FullAWSAccess --target-id <ou-or-account-id>.
• Confirm restoration with describe-effective-policy against the same representative account used during validation.
• Only reattempt the allow-list rollout once the missing action or service has been identified, added, and re-tested in the sandbox OU.

Prevention

Treat “policy attached” as necessary but insufficient, and make “no other non-deny SCP is attached at the same target” an explicit, checked precondition before relying on an allow-list SCP for a guardrail. Where the intent is a hard restriction rather than an additive constraint, prefer explicit Deny statements, which apply regardless of other attached policies, over allow-list statements that depend on FullAWSAccess having been removed. Record which policies were detached and why in the guardrail’s own change history, so a future review does not reattach FullAWSAccess “to be safe” and silently reopen the gap. Build an automated, scheduled check that calls describe-effective-policy for a sample account in every guarded OU and alerts if the merged allowed-action set widens unexpectedly, since OU membership and policy attachments can change independently of the original rollout.