Roles and access

Three roles. The difference between them is what they may change, not what they may see.

Getting an account

Three routes in, and which ones are available depends on how your instance is configured.

1. 1

   Provisioned by an admin

   An admin adds your email under Settings → Members and chooses your role. You then sign in as yourself and land in that organization.

   The role comes from this record and nothing else. A claim in a Google or OIDC token never grants a role by itself.

2. 2

   Provisioned by SCIM

   Your identity provider creates, updates and deactivates accounts. See SSO and SCIM.

3. 3

   Self sign-up

   Where enabled, an unknown Google identity gets a new organization of its own, never membership of an existing one.

Sign-in

Google, and only Google. There is no password login here, by design: a credential nobody can lose is a credential nobody can leak.

Two consequences worth knowing before you roll it out:

• An unverified Google email is rejected outright, because an unverified address may belong to somebody else.
• A refused sign-in says only that it was refused. It does not say whether the account exists, so the screen cannot be used to enumerate your members.

Where sign-in has not been configured at all, the console says so rather than offering a form that cannot work.

The session

The session lives in a cookie the browser cannot read and never appears in a URL, so a redirect cannot leak it through browser history or a Referer header. Signing out ends it on the server, not only in the tab.

That is the whole of what an administrator needs from it. Everything else about how the console holds a session is an implementation detail of the control plane, and is deliberately not something you configure.

Members, grants and status

Grants scope a user to specific workspaces or projects, the mechanism for a contractor who should see one project and not the rest of the company.

Status suspends without deleting. Deleting a user would take their approvals out of the record; suspending leaves the trail intact and closes the door.

Invites

A project-scoped invite creates an account that only reaches that project. Use it by default; org-wide access is the exception, not the starting point.

Agent credentials are not user credentials

An agent token authenticates an agent, carries capabilities, and may read exactly one route beyond the decision endpoints (GET /v1/approvals/:id, its own).

Never issue an agent a user credential, and never let an agent hold an admin token. The whole model assumes the thing being governed cannot reconfigure the governor, see the policy-bypass-protection pack.