What is a Permission Boundary in AWS?

Definition

A Permission Boundary in AWS is a special IAM policy attached to a user or role that defines the maximum permissions that principal can ever have — regardless of what identity-based policies are attached to them.

It's an upper limit, not a grant. The principal's effective permissions are the intersection of:

• (their identity-based policy) ∩ (their permission boundary).

In simple terms:

A permission boundary says "you may have these powers granted, but you can never exceed this ceiling."

---

Why Permission Boundaries Matter

• Enable safe delegation of IAM management — let team admins create roles/users in their domain without being able to escalate to broader privileges.
• Prevent privilege escalation by IAM principals who can edit their own policies.
• Provide a defense-in-depth layer alongside SCPs (organization-wide) and identity policies (per-principal).

---

How Boundaries Work

Example Use Case

You want each team admin to manage IAM users and roles for their own team — but not be able to grant themselves or others Administrator access to the entire account.

1. Create a permission boundary policy TeamAdminBoundary that allows only the actions you want team admins (and their created principals) to ever have.
2. Attach the boundary to the team admin role.
3. Configure the team admin's identity policy so they can only create new IAM principals with this boundary attached.

Now no matter what policies the team admin attaches to themselves or others, the boundary caps the permissions.

---

Boundary Policy Example

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowedActions",
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*",
        "iam:Get*",
        "iam:List*",
        "iam:CreateUser",
        "iam:CreateRole",
        "iam:AttachUserPolicy",
        "iam:AttachRolePolicy",
        "iam:PutUserPermissionsBoundary",
        "iam:PutRolePermissionsBoundary"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyEscalation",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteUserPermissionsBoundary",
        "iam:DeleteRolePermissionsBoundary"
      ],
      "Resource": "*"
    }
  ]
}

The boundary itself caps actions; the explicit Deny prevents removing the boundary.

---

Boundary vs SCP vs Identity Policy

Layer	Scope	Purpose
SCP	Organization (account/OU)	Organization-wide guardrails
Permission Boundary	Single principal	Per-principal ceiling
Identity Policy	Single principal	Grants specific permissions
Resource Policy	Resource	Cross-account / resource-side allow/deny

A request must pass all applicable layers; explicit Deny anywhere wins.

---

Common Pitfalls

• Forgetting to require boundary attachment when delegated admins create new principals — they can create boundaryless principals with full power.
• Boundary too permissive — defeats the purpose.
• Boundary blocking necessary AWS service operations (e.g., service-linked roles) — break workflows.
• Removing boundary by allowed iam:DeleteUserPermissionsBoundary — must be denied in the boundary itself or via SCP.
• Confusion with SCPs — they serve different scopes.
• No automation — manual boundary attachment errors.

---

Real-World Examples

1. Application Team Self-Service

App team admins manage IAM in their account. Boundary AppTeamBoundary allows only the AWS services that team uses (EC2, S3, RDS) and explicitly denies IAM actions that could escalate. Team can create roles for their workloads but never an Admin role.

2. Vendor Onboarding

Vendor's role attached with strict boundary that only allows the specific actions they need; even if their identity policy is broader, the boundary caps them.

3. Misconfigured Boundary

Boundary allows iam:CreateRole without requiring iam:PermissionsBoundary condition. Delegated admin creates a new role without boundary, attaches AdminAccess. Escalation in one step.

Fix: Use iam:PermissionsBoundary condition on iam:CreateRole/iam:CreateUser and iam:PutRolePolicy to require boundary on created principals.

---

Best Practices

1. Use boundaries for any delegated IAM administration.
2. Require boundary attachment on principal creation via condition iam:PermissionsBoundary.
3. Deny removal of boundary in the boundary or via SCP.
4. Test boundary thoroughly before deployment.
5. Pair with SCPs for organization-wide guardrails.
6. Version-control boundary policies in Git.
7. Document boundary purpose and the team it serves.
8. Periodic boundary review as team needs evolve.
9. Monitor boundary changes in CloudTrail.
10. Use IAM Access Analyzer to detect principals without expected boundary.

---

Checklist

• Boundaries used for delegated IAM admin?
• iam:PermissionsBoundary condition required on creation?
• Boundary denies its own removal?
• Boundaries version-controlled and peer-reviewed?
• Boundaries documented with purpose?
• Combined with SCPs for guardrails?
• Periodic review?
• CloudTrail monitoring on boundary changes?

---

How Forestall Helps

Forestall identifies:

• Delegated admins without boundaries.
• Principals where boundary attachment is missing or weak.
• Escalation paths that boundaries should block.
• Boundary effectiveness against current identity policies.

---

Frequently Asked Questions

Is a boundary the same as an SCP?

No. SCPs apply across accounts/OUs; boundaries apply to single principals.

Does boundary grant permissions?

No — it caps maximum permissions. Identity policy still grants.

Can I attach a boundary to a group?

No — only to users and roles. (Use group policies + uniform boundaries on members.)

What if no boundary is set?

The principal's effective permissions are simply their identity policy (and SCPs/resource policies as usual).

Can boundaries enforce MFA?

Indirectly via Deny statements with conditions like aws:MultiFactorAuthPresent.

---

Conclusion

Permission Boundaries are AWS's mechanism for safely delegating IAM administration. Combined with SCPs, identity policies, and resource policies, they enable scalable IAM ownership without losing centralized control. Used carefully — always required on principal creation, with their own removal denied — boundaries close one of the most common privilege-escalation paths in delegated AWS environments.