Permissions boundary

Definition

A permissions boundary is attached to an IAM user or role and sets the maximum permissions that principal may have. It is a ceiling, not a grant: it removes permission an identity-based policy would otherwise give and can never add any. Whether it also caps a resource-based grant depends on which document it is attached to and which principal form the grant names.

The problem

It is routinely described as limiting identity-based policies only, which is incomplete in a way that produces real defects. The same bucket policy caps one role and not another depending on whether it names the role or the role session, and a boundary attached to the principal is invisible to the trusting account’s evaluation in a cross-account request.

Why it matters

The boundary is the per-principal ceiling: it travels with the principal, unlike a service control policy (per account) or a resource control policy (per resource). Choosing between the three is an architecture decision with different blast radii, and it cannot be made correctly while the boundary is modelled as a filter on identity policies alone.

Practical example

A role whose boundary allows read-only S3 actions is granted s3:PutObject by its identity policy: the write is denied at the boundary stage. The same grant arriving from a bucket policy that names the role session ARN bypasses the boundary entirely.

How RELIASTRA approaches it

The boundary is why RELIASTRA’s attribution habit starts with the CloudTrail principal type rather than with a policy: whether any ceiling could have applied to a request is a property of the identity that made it, and only the record says which identity that was.