> ## Documentation Index > Fetch the complete documentation index at: https://to11.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Roles & Permissions > Control what each member can do with roles, a permission catalog, per-user overrides, and trace access. Access in to11 is governed by permissions. A permission is a single capability — such as creating an API key or approving a routing change. Permissions are grouped into roles, and roles are assigned to members. ## Roles A role is a named set of permissions. Assigning a role to a member grants them every permission it contains. Roles exist at three tiers — organization, workspace, and project — and each tier ships the same four built-in roles, from most to least access: | Role | Typical access | | -------------------------------------------- | ------------------------------------------------------------------- | | `owner` | Full control of the tier, including deleting it. | | `admin` | Manage configuration and members; includes production trace access. | | `developer` | Read and change configuration; non-production trace access. | | `viewer` (`member` at the organization tier) | Read-only access. | A member's effective access is the union of the roles they hold across the tiers that apply to them — an `org_developer` who is also a `project_admin` on one project has admin access there and developer access elsewhere. **Assigning roles.** Set a person's organization role when you invite them, and adjust roles — including per-workspace and per-project roles — from the [Team](/docs/platform/team) page. Changing someone's role grants every capability the new role carries. **Custom roles.** When the built-in roles don't fit, you can define a custom role at the organization, workspace, or project tier with exactly the permissions you choose, then assign it like any built-in role. ## The permission catalog Permissions are scoped to the level they act on. The catalog spans, among others: | Area | Examples | | ----------------- | --------------------------------------------------------------------- | | Organization | Create, read, update, delete organizations | | Workspace | Create, read, update, delete workspaces | | Project | Manage projects, labels, and environments | | Members & invites | List members, manage members, manage invitations | | Routing | Read, write, publish, review, and roll back routing | | Providers | Edit configuration, rotate credentials, approve changes | | Prompts | Read, create, update, archive, review, publish, and roll back prompts | | Environments | Manage environments and environment policies | | API keys | Create, list, rotate, revoke keys | | Ingestion | Send gateway LLM traffic and OpenTelemetry ingest for a project | | Traces | Read traces, read production traces | | Audit | Read and export the audit log | The catalog is enforced server-side: every protected action checks for the permission it requires, and [API keys](/docs/platform/api-keys) draw their scopes from the same catalog. ## Per-user overrides Beyond roles, a specific permission can be granted to or removed from an individual member with an override, scoped to the organization, a workspace, or a project. An override can also be set to expire. Use an override for the exception that doesn't justify a new role: granting one person a single extra capability, or denying one capability someone's role would otherwise include. A **deny** override always wins over a grant — whether the grant comes from a role or another override — so you can carve out an exception without rebuilding the role. Reach for a custom role instead when the same exception applies to several people. ## Trace access Reading traces is gated by two independently grantable permissions. Production traces — those captured in environments flagged `is_production = true` — sit behind a permission distinct from the one that grants access to non-production traces. | Permission | Scope | Grants | | ------------------ | ------- | ------------------------------------------------------------ | | `traces:read` | Project | Read traces from environments where `is_production = false`. | | `traces:read:prod` | Project | Read traces from environments where `is_production = true`. | `traces:read:prod` does not imply `traces:read` — they are independently grantable, which matters for API keys scoped to a single ingestion path. ### Which roles hold which permission There is no dedicated prod-trace-reader role; the two permissions cascade onto the existing tier roles. | Tier | Role | `traces:read` | `traces:read:prod` | | ------------ | ------------------------------------- | :-----------: | :----------------: | | Organization | `org_owner` / `org_admin` | Y | Y | | Organization | `org_developer` | Y | | | Organization | `org_member` | | | | Workspace | `workspace_owner` / `workspace_admin` | Y | Y | | Workspace | `workspace_developer` | Y | | | Workspace | `workspace_viewer` | | | | Project | `project_owner` / `project_admin` | Y | Y | | Project | `project_developer` | Y | | | Project | `project_viewer` | | | Developer-tier roles hold only non-production trace access; admin and owner roles at every tier hold both. Viewer-tier roles and `org_member` hold neither. ### Capture-time classification A trace's production / non-production classification is fixed when the trace is written, from the originating environment's `is_production` flag at that moment. Flipping the environment's flag later does not re-classify historical traces. This preserves audit determinism. A user who opens a production trace without `traces:read:prod` sees an explicit boundary state naming the missing permission — not a generic 404 — so they can request access. Trace IDs from other projects return a generic not-found, so the boundary state can't be used to enumerate traces across projects. ### Granting production trace access You need `org_admin` (or higher) in the organization, and the project must have at least one environment flagged `is_production = true`. * **To a teammate** — on the [Team](/docs/platform/team) page, open the principal's role popover at the relevant tier and assign a role that carries `traces:read:prod`. Note that changing the role grants every capability the new role carries, not just the trace permission. * **To an API key** — create or edit a key (see [API keys](/docs/platform/api-keys)) and select the trace scopes you need. `traces:read:prod` alone is a legal scope and is the right choice for a key that only reads production traffic. Issue prod-trace access on a dedicated key and rotate it independently rather than adding it to a multi-purpose ingestion key. * **To revoke** — change the user's role to one without `traces:read:prod`, or remove the scope from (or revoke) the API key. The change takes effect on the principal's next request. Every grant, revocation, and role change touching `traces:read` or `traces:read:prod` is recorded for accountability. ## Next steps Assign roles to people. Scope programmatic access.