A permission boundary is one of the more misunderstood corners of IAM, largely because it looks exactly like an ordinary policy document — the same Version/Statement shape, the same Effect/Action/Resource fields — while behaving completely differently once attached. IAM Permission Boundary Generator builds that same familiar shape, but frames the whole workflow around the one fact that matters most: a boundary sets a ceiling on what an identity can ever do, and grants nothing on its own.
When a permission boundary is attached to an IAM user or role, AWS evaluates that identity's effective permissions as the intersection of two separate things: whatever its identity-based policies allow (or, for resource access, whatever the relevant resource policy allows), and whatever the boundary allows. An action only succeeds if both sides permit it. This means a boundary that allows s3:* does not by itself grant any S3 access — an identity policy still has to grant it — but it also means that no matter how permissive an identity policy someone attaches later (deliberately or by mistake), the boundary caps what can actually happen. That single property is why boundaries are the standard tool for letting a delegated administrator create and manage their own IAM users and roles without being able to escalate those identities beyond a pre-approved ceiling.
Because that intersection behavior is exactly what makes boundaries useful, this tool leads with a one-click starting point built from the pattern AWS's own documentation recommends most often: an Allow statement scoped to a single service action prefix (say, s3:* or lambda:*) as the outer limit of what the bounded identity should ever be able to touch, paired with an explicit Deny statement blocking iam:* and organizations:* — the two families of actions that would let a bounded identity manage other identities' permissions or leave the account's control plane altogether. Because IAM's evaluation logic always lets an explicit Deny win over any Allow, that second statement holds even if the identity policies eventually paired with this boundary are far more permissive than intended.
From that starting point — or from a blank slate, since the template is optional — the rest of the workflow is identical to the general-purpose IAM Policy JSON Generator: fill in a statement's Sid, Effect, one action per line, one resource per line, and an optional single condition, click Add statement, and it joins a running list with a remove button per row. Add as many statements as the boundary needs, then build the final document, which runs through the same structural validator used across these tools: Version present, Statement non-empty, and every statement carrying a valid Effect, an Action, and a Resource.
What this tool cannot check, because nothing client-side can, is the other half of the intersection: which identity policies this boundary will eventually be paired with, and therefore what the bounded identity's actual effective permissions will turn out to be. That evaluation only happens once both the boundary and the identity policies are attached in a real AWS account (or run through IAM's policy simulator). This tool's job stops at producing a correctly-shaped, structurally valid boundary document — the pairing and the resulting effective permissions are yours to reason through, and the description above is deliberately explicit about that so the boundary is never mistaken for a grant.