A policy answers three questions: who it applies to, which servers it covers, and what they get. Policies are evaluated per request.

Allow and deny

Every policy has an effect of allow or deny.

• A matching deny refuses the request. Deny beats allow, always.
• A matching allow permits it, and supplies the principals and the maximum session duration.
• If nothing matches, the request is refused. There is no implicit allow.

priority orders evaluation among policies of the same effect. It does not let an allow outrank a deny.

Who a policy applies to

Subjects attach to a policy and can be individual users, groups, or a role tier. Role subjects match on the role's base tier — member, manager, admin, super_admin — not on a custom role's name, so a custom role built on the manager tier matches a manager subject.

Which servers it covers

Targeting is a set of filters, and a server has to satisfy the ones you set:

Field	Meaning
customerId	Limit to one customer's servers
targetEnvironments	demo, dev, staging, prod
targetLabels	Match servers carrying these labels
targetServerIds	Specific hosts

Leaving a filter empty means it does not narrow anything. A policy with no targeting at all covers every server in scope, which is rarely what you want — start narrow.

What it grants

Field	Meaning
allowedPrincipals	The Unix accounts the certificate may log in as
maxSessionDuration	Upper bound on certificate lifetime, in seconds
allowKeyDownload	Whether the requester may download the private key to use their own client
osProvisioning	Just-in-time account creation settings on the host

allowedPrincipals is the part people get wrong. A certificate is only useful if its principal matches an account that exists (or will be provisioned) on the target. Granting root because it is convenient throws away most of the benefit of scoped access.

Approval

Field	Meaning
requireApproval	Force review even for non-production
autoApprove	Skip review — non-production only
approverGroupId, approverRoles, approverUserIds	Who may approve

If all three approver fields are empty, approval falls back to the requester's manager. Any one resolved approver can act on the request.

DANGER

autoApprove cannot grant unreviewed production access. If the server's environment is prod, the request goes to an approver regardless of this flag. The only exception is a requester whose role holds access.prod_bypass in an organisation with prodBypassEnabled on — and that path still creates the request, still demands a reason, is audited as access_request.prod_bypass, and notifies the approvers afterwards.

Break-glass

isBreakGlass marks a policy as an emergency path. Use it for a deliberately narrow, loudly audited route to production for on-call, not as a way to avoid building a normal approval flow.

A sane starting set

1. Deny everything targeting prod for the member tier. Written first, so it is obvious.
2. Allow dev and staging for engineers, autoApprove on, principals limited to a deploy account, duration a few hours.
3. Allow prod for the people who operate it, approval routed to a named group, short duration, no key download.

Then test with a real request before you rely on it.