Skip to main content
A permission boundary is a policy attached to a principal that sets the maximum within its policy domain it can 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. Account service accounts and roles use account policy boundaries. Users use Workspace organization policy boundaries. Account boundaries do not cap separately delegated organization permissions; control those with organization policy grants and applicable session policies.

​
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

Open the user, service account or role and find its Permission Boundary card. Choose Set Boundary and pick the policy. Once one is set the button reads Change, and clearing it confirms with Remove Permission Boundary.A group has no such card, which is the table below made visible.
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 follow the same policy evaluation as other principals. A durable boundary that removes the owner’s required administrator access cannot be attached. Transfer ownership before restricting those grants. Temporary session restrictions still apply.

​
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 in the evaluated policy domain short-circuits 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.
An account policy allowing service-account creation and selected account policy attachments. Attachment checks require both identity and policy CRNs:
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.

Use an explicit deny

To refuse matching actions even when another policy allows them. A deny beats every allow in the same policy domain.

​
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.