Permission Boundaries: The Sandbox for Delegated Administration

The Privilege Escalation Problem

Suppose you want to let a developer manage IAM roles for their own Lambda functions — a reasonable request. You grant them iam:CreateRole and iam:AttachRolePolicy. But now you have a problem: that developer can create a role with AdministratorAccess and then call sts:AssumeRole to assume it, instantly becoming an admin. This is called privilege escalation, and it is one of the most common IAM attack vectors.

Permission Boundaries solve this by separating two concerns:
1. What actions can this identity perform? (Identity Policy)
2. What is the maximum permission ceiling for any role this identity creates? (Permission Boundary)

How Permission Boundaries Work

A Permission Boundary is itself an IAM policy, but it is attached to a User or Role in a special way — as a boundary, not as a permission grant. The effective permissions of an identity are the intersection of its Identity Policy and its Permission Boundary.

Effective Permissions = Identity Policy ∩ Permission Boundary

Delegated Administration Pattern

Here is the pattern used in production:

1. Security team creates a "developer boundary" policy that allows only Lambda, S3, DynamoDB, and CloudWatch Logs.
2. Security team grants developers iam:CreateRole with a condition:
   json { "Effect": "Allow", "Action": "iam:CreateRole", "Resource": "*", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DeveloperBoundary" } } }
3. Developer can now create roles — but only if they attach the DeveloperBoundary to them.
4. Even if the developer attaches AdministratorAccess to the new role, the boundary restricts effective permissions to Lambda, S3, DynamoDB, and CloudWatch Logs.

The developer is sandboxed. They have real autonomy within a safe perimeter.