Docs
Roles & Permissions
Roles are per-project, not org-wide: being an Admin on one project doesn't give you Admin (or any access at all) on another. The Owner is the one exception, with unconditional full access to every project in the org.
Owner
Full access to every project in the org, always — no per-project grant needed. Owner access can't be overridden by the permission matrix below — an org can never accidentally lock itself out of managing itself.
Admin
Full access by default within a project they've been granted Admin on, overridable per environment tier via the permission matrix. Can manage that project's members and create new projects (subject to Owner approval).
Developer
Within a project they've been granted Developer on: read/write on Development, Testing, and Staging by default, read-only on Production by default.
Viewer
Within a project they've been granted Viewer on: read-only on Development, Testing, and Staging by default, no access to Production by default.
The default matrix
Every role×environment-tier combination above is a sensible default, not a hardcoded rule. The Owner can open an org's Permission Matrix and grant or restrict access per role, per tier, org-wide — for example, giving Viewers read-only access to Production for an incident review, without giving them write access anywhere. Overrides are sparse: a role/tier combination with no explicit override simply falls back to the default above, so most orgs never need to touch it.
Service tokens inherit identity
A CLI service token isn't independently scoped — it can only ever do what its creator can do, evaluated against their live role at request time, and it's hard-locked to the single organization it was issued for. Anyone can create a token for themselves — since it can never exceed their own access, there's no escalation risk in self-service creation. Non-owners only see and manage their own tokens; the Owner can see and revoke any token in the org.
Project-level access
Being a member of an org doesn't give you a role in any particular project — a role is granted per project (from that project's Members panel), and it's that project-level role, not any org-wide standing, that the environment-tier matrix above is evaluated against. The Owner is the only exception: full access to every project, with no grant needed.
Anyone in the org — including a member with no project grants at all — can browse the full project list and request access to a specific project, optionally naming the role they're requesting. An Owner, or an Admin who already has access to that project, can approve or reject the request.
Inviting and changing roles
Only the Owner, or a project's own Admin, can invite someone to that project — and only as Developer or Viewer if the inviter isn't the Owner (an Admin can't create a peer Admin without the Owner doing it directly). Every project invite is usable immediately; there's no separate approval step, since the inviter already has the exact authority they're granting. A plain org-only invite (no project, no role — just membership) can be sent by any existing member.
There's no org-level role to assign or change — the only org-wide distinction is Owner vs. everyone else, and ownership only ever moves through a direct, immediate transfer (Team → Permissions, Owner-only).
Anyone already in the org can request access to a project (or a different role in a project they're already in) from the Projects page — an Owner, or that project's own Admin, approves or rejects it. A project created by an Admin needs Owner approval unless the Owner has turned on auto-approve for that Admin (Projects page, Owner-only) — a project created by the Owner is immediate.