Build IAM permission boundary policies to set maximum permission limits for roles and users.
Last verified: May 2026
Output will appear here...The builder constructs IAM permission boundary policies — JSON documents in the same format as identity policies but applied as a boundary. Output includes the policy JSON itself plus the iam:PermissionsBoundary condition snippet to add to the delegated admin's identity policy (preventing them from creating roles without the boundary attached).
IAM permission boundaries set the maximum permissions that an IAM entity (user or role) can have, regardless of what identity-based policies are attached. They act as a guardrail — the effective permissions are the intersection of the identity policy and the permission boundary. This is critical for delegated administration scenarios where you allow developers to create IAM roles but want to ensure those roles can never exceed certain privilege levels. The Permission Boundary Builder helps you define boundary policies with correct resource constraints, service limitations, and condition keys that prevent privilege escalation.
Your platform team wants to give product engineers self-service IAM role creation for Lambda functions, but they're worried about engineers creating overly-permissive roles. The builder generates a permission boundary that allows: Lambda execution role permissions, CloudWatch Logs, X-Ray, plus DynamoDB/S3 read on resources prefixed with the team's name. Add the iam:PermissionsBoundary condition to engineers' role-create permission. Engineers can now create roles freely, but those roles can never exceed the boundary. Audit logs show which engineer created which roles. Self-service unlocked safely.
Permission boundaries are NOT inherited. If your delegated admin creates a role WITHOUT specifying a permission boundary, the new role has no boundary at all. Always require boundary attachment via the iam:PermissionsBoundary condition in the admin's policy — this is the most-missed escalation vector.
Boundaries don't restrict resource-based policies (S3 bucket policies, SQS, KMS). A bucket policy granting access to a role bypasses that role's boundary. For full data perimeter, you need boundaries + SCPs + resource-based policies aligned together.
Permission boundaries are the right tool for delegated admin scenarios but the WRONG tool for general 'limit what this role can do' goals — that's what regular IAM policies are for. Boundaries add complexity. Use them only when you need to delegate IAM management while preventing escalation.
The effective permissions of an IAM entity are the intersection of its identity-based policies and its permission boundary. If an identity policy grants s3:* and the boundary only allows s3:GetObject and s3:ListBucket, the effective permissions are limited to GetObject and ListBucket. Importantly, permission boundaries do not grant permissions — they only limit them. The entity must still have an explicit Allow in its identity policy for any action to be permitted.
The key pattern is requiring that any IAM role or user created by a delegated administrator must have the same permission boundary attached. You encode this requirement as a condition in the administrator's IAM policy: iam:CreateRole is allowed only if iam:PermissionsBoundary equals a specific boundary policy ARN. This ensures that created roles cannot exceed the boundary's permissions, and since the boundary cannot be removed without explicit permission, escalation is blocked.
No. Permission boundaries only limit identity-based policy permissions. If a resource-based policy (like an S3 bucket policy or SQS queue policy) directly grants access to an IAM entity, the permission boundary does not restrict that access. This is an important distinction — resource-based policies bypass permission boundaries and SCPs for same-account access. For cross-account access, the boundary is still evaluated on the requesting principal's side.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.