Block overprivileged IAM roles at the org boundary.
IAM misconfiguration is the #1 cloud breach vector. SCPs enforce least-privilege across all accounts before roles are assumed — not after a breach report lands.
SCP conditions evaluated before roles are created.
Native Security reads your SCPs and maps the conditions on iam:CreateRole, iam:AttachRolePolicy, and iam:PutRolePolicy statements. When a Terraform plan or CloudFormation stack includes a new IAM role, the guardrail checks whether the proposed role would be blocked by any SCP in the account's effective policy set.
- Evaluates SCP condition blocks: StringEquals, ArnLike, StringNotEquals
- Supports PermissionsBoundary enforcement patterns
- Checks both explicit Deny and missing Allow conditions
- Works with AWS Organizations inherited and directly attached SCPs
{
"Sid": "DenyAdminRoleWithoutBoundary",
"Effect": "Deny",
"Action": [
"iam:CreateRole",
"iam:PutRolePolicy"
],
"Resource": "*",
"Condition": {
"StringNotLike": {
"iam:PermissionsBoundary":
"arn:aws:iam::*:policy/OrgPermBoundary"
}
}
}
Admin role without boundary. Deploy blocked.
A developer pushes Terraform that creates an admin IAM role with no PermissionsBoundary condition. The SCP DenyAdminRoleWithoutBoundary is active on the target account. Without Native Security, the Terraform apply fails at AWS API call time — buried in the apply output. With Native Security, the deploy gate fails before apply, with a clear explanation.
- Fails at plan stage — before any AWS API calls
- Violation message includes the SCP condition that triggered it
- Suggested fix included in output: add PermissionsBoundary
See your SCP coverage before the next deploy cycle.
Connect your AWS Organization, get a full SCP inventory in minutes, and wire in the deploy gate. The SCPs you wrote will finally do what you intended.