6 AWS SCP Guardrails That Contain a Compromised Account
If an attacker lands in one of your AWS member accounts with leaked credentials, service control policies (SCPs) are the containment layer they cannot modify from inside that account. Six guardrails do most of the work: blocking account exits, restricting Regions, capping root actions, protecting security services, preventing destructive deletes and shielding platform resources. They are effective because an SCP never grants access by itself: it only lowers the ceiling on what any principal in a member account can do, and AWS explicitly defines SCPs as permission guardrails rather than grants.
What an SCP actually enforces
An SCP looks like an IAM policy, but it does something narrower and, for incident containment, more useful. It filters the maximum available permissions for the IAM users and roles below it in the organization tree, and effective permissions are the logical intersection of what the SCP allows and what identity-based or resource-based policies grant. Nothing becomes accessible because an SCP exists; access only shrinks. AWS publishes its starter policies with a deny list strategy, which means you keep the default FullAWSAccess policy attached and add explicit Deny statements for the actions you want fenced off. AWS warns that removing FullAWSAccess without replacing it with allowed actions makes all member-account actions fail, so the deny list pattern is the safe default.
Six guardrails worth enabling
The aws-samples repository maintained by AWS groups example policies by control type, which maps cleanly onto a containment-first rollout. The table below combines the three recommended starters with the categories around them.
| Guardrail | Containment effect | Example location |
|---|---|---|
| Deny account leave | An attacker holding root in a member account cannot detach it from the organization, consolidated billing or central trails | Privileged-access-controls |
| Approved Regions only | Actions outside your approved Region list are denied, shrinking where stolen credentials can mine or stage data | Region-controls |
| Block root credential moves | Root credential management in member accounts is denied outright | Privileged-access-controls |
| Protect security services | Member accounts cannot disable GuardDuty, organization trails and comparable governance tooling | Deny-changes-to-security-services |
| Block destructive deletes | Deletion of designated Amazon S3 buckets and objects is denied | Service-specific-controls |
| Protect platform resources | Critical shared resources resist modification and deletion | Protect-cloud-platform-resource |
If you only deploy three, make them the starters AWS itself recommends: deny member accounts from leaving the organization, restrict usage to approved Regions, and prevent root credentials management in member accounts. The leave-org denial is the quiet hero of the set, because an account that cannot exit the organization also cannot exit its CloudTrail organization trail, its GuardDuty delegation or its consolidated billing visibility.
Root users and exceptions
Two boundary facts decide where these policies actually bite. First, the member account’s root user stays inside the guardrail while the management account sits outside every SCP, so root credentials stolen from a member account still hit the wall, but nothing protects careless use of the management account itself, which is why AWS tells you to keep workloads out of it. Second, SCPs do not affect any service-linked role, so AWS-managed integrations keep working no matter how tight your deny lists get, but that also means service-linked roles cannot be part of your containment story and need separate monitoring.
Why admin policies cannot override
Hierarchy beats local privilege. Because a blocked permission at any level above the account stays blocked, no amount of AdministratorAccess inside the account can restore an action that a parent policy blocks. That single rule is what turns SCPs from policy hygiene into incident containment: an attacker with stolen administrator credentials, or a compromised CI pipeline running with full IAM rights, can create users, roles and access keys all day, yet every one of those principals inherits the same ceiling. Local escalation stops buying anything.
Testing without locking yourself out
AWS strongly recommends against attaching new SCPs to the organization root without testing; move accounts into a test OU one or a few at a time instead, and check service last accessed data before denying a service nobody remembers using. Once a policy passes, deploy it to narrow OUs first and broaden gradually. Budget matters too: one service control policy document can hold at most 10,240 characters, and whitespace counts when you save via the CLI or SDK, so keep deny lists tight and push per-team nuance down into IAM where it belongs. As you roll these out, pair them with adjacent reviews such as the decisions to settle before enabling KMS key rotation and the controls worth enforcing before MCP agents connect, since guardrails, key hygiene and agent access all constrain the same blast radius.