Skip to main content
A permission boundary is a policy attached to a principal that sets the maximum it can ever be granted. It grants nothing on its own — it is a ceiling, not a floor.
An action has to be allowed by both. A policy that grants something outside the boundary grants nothing.

​
Why they exist

Without boundaries, letting someone manage permissions means letting them grant themselves anything. A boundary lets you delegate that safely: a team lead can create service accounts and attach policies, and nothing they attach can reach past the ceiling you set.
1

Write the ceiling

A policy describing the widest set of permissions anything in this team may ever hold.
2

Attach it as a boundary

The same three routes exist for users and roles: PUT, GET and DELETE.
3

Delegate policy management

Whoever manages this principal can now attach whatever policies they like. Anything outside the ceiling has no effect.

​
What a boundary applies to

An assumed-role session is bounded by the role it assumed, not by whoever assumed it. The role is the bounded entity; a session cannot escape its role’s ceiling by being created from an unbounded caller.
Organization owners are not bounded. An owner’s implicit access is subject only to an explicit deny; the boundary check is never reached for them. Do not model an owner as “an administrator with a ceiling” — use an explicit deny for a guardrail that has to hold for everyone.

​
How it combines with everything else

A boundary is the last of the three narrowing steps, and each one can only subtract: An explicit deny anywhere short-circuits all of it. See how a request is authorized.

​
Failing closed

If a boundary is set but the boundary or its policy cannot be read, the request is denied. A boundary that exists but is unreadable might be capping this very action, so the safe answer is no.The practical consequence: deleting a policy that is in use as a boundary does not widen access, it removes it.

​
Worked example

Delegating instance management to a team, safely.
Everything this team may ever touch — compute and storage, only on resources tagged as theirs, and never IAM.
A policy letting them manage their own service accounts:
Suppose the lead attaches {"effect": "allow", "actions": ["*"], "resources": ["*"]} to a bounded service account.That service account still cannot touch IAM, cannot touch a resource tagged for another team, and cannot reach any service outside compute and storage — the boundary intersects every one of those away. The broad policy is not rejected; it simply does not reach past the ceiling.
Note what this example does not do: it does not let the lead attach or remove boundaries. If they could, they could raise their own ceiling. Grant boundary management only to whoever is meant to set the ceiling.

​
Boundary or explicit deny?

Both restrict, and they are not interchangeable.

Use a boundary

To cap one principal while letting someone else manage its policies. It is a ceiling on delegation, and it does not apply to organization owners.

Use an explicit deny

For a rule that must hold for everyone, including owners. A deny beats every allow and is never intersected away.

​
Next

Writing policies

The document format a boundary uses — it is an ordinary policy.

Roles and credentials

Session policies narrow the same way, per set of credentials.