# 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, `.`. 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. ## Roles [#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 [#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](/guides/agents) 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 [#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 [#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](/security/organizations): creating an organization, invites, roles and removal. - [SSO and SCIM](/security/sso): sign-in through Okta, Microsoft Entra ID or any OpenID Connect provider, SCIM provisioning and group roles.