Permissions
Three roles, named permissions, and agents that never have more access than the person they act for.
Every member of an organization has one role, Viewer, Developer or Admin, which applies to all of its projects. A role is a set of named permissions, <resource>.<verb>. Every API endpoint names the one permission it needs, and the CLI, MCP server and console go through the same check. A refusal is 403 forbidden with the missing permission in the body.
| Permission | Viewer | Developer | Admin | Agents |
|---|---|---|---|---|
See workloads and logs logs.read | ||||
Create, use and destroy sandboxes sandbox.create | — | |||
Run jobs jobs.run | — | |||
Promote, approve, roll back and freeze environments environments.deploy | — | — | ||
Set and rotate secrets secrets.write | — | |||
Reveal secret values secrets.reveal | — | — | — | |
Production database production.database | — | — | — | |
Exec in production production.exec | — | — | — | |
Manage domains domains.manage | — | — | ||
Manage members members.manage | — | — | ||
Manage SSO and SCIM sso.manage | — | — | — | |
Create projects projects.create | — | — |
Roles
- Viewer sees workloads, builds, logs, and secret names and metadata. Never secret values.
- Developer creates and uses sandboxes, runs jobs, sets and rotates secrets, and promotes, rolls back and freezes production.
- Admin manages members, domains and projects, and is the only role that can reveal a secret value, reach the production database or exec into production. Each of those is an audited action.
Someone who is not a member of the organization gets no access to its projects, including their names in the console. Every member sees staging and production logs, with known secret values masked.
Agents
An agent always acts for a person, and its token carries both. It gets that person's permissions, minus the ones marked as never for agents in the table above: an Admin's agent still cannot reveal a secret, reach the production database or exec in production. Those are done by the Admin.
A sandbox token is further scoped to one sandbox: it is a Developer agent inside that sandbox and reaches nothing outside it.
Every agent action is recorded in the project's activity history with the agent and the person it acted for, for example Claude Code for ana@acme.test.
Tokens
| Token | Prefix | Scope | Holds |
|---|---|---|---|
| Project token | ppt_ | One project, with the person's role | People and CI |
| Sandbox token | pst_ | One sandbox, as a Developer agent; expires with the sandbox | Agents |
GET /v0/token returns a token's person, role, scope and granted permissions. A sandbox token is also refused anything outside its sandbox, whatever that list says.
Sign-in and members
People sign in to the console with GitHub or Google, or through their organization's own identity provider. Parity stores no passwords.
- Organizations and members: creating an organization, invites, roles and removal.
- SSO and SCIM: sign-in through Okta, Microsoft Entra ID or any OpenID Connect provider, SCIM provisioning and group roles.