Skip to main content
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: 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 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: The catalog is enforced server-side: every protected action checks for the permission it requires, and API keys draw their scopes from the same catalog.
Skills add no permission of their own. A skill is the second kind of prompt, so it is gated by the prompt permissions above rather than by a parallel set. Two are worth naming because they are not where a reader would look first:
  • Importing a skill from a folder needs prompt:create — the scope that creates versions, which is what an import produces. Its own scope would mean a maintainer who can create versions cannot import one, which is a distinction nobody has asked for.
  • Resolving organization/workspace/project to a project id needs project:read — deliberately narrower than the three calls it replaces, which need organization-level read. Resolution is a lookup, not a way to enumerate: it answers about a project you can already reach, and a project you cannot reach is reported the same way as one that does not exist.
Releasing a skill uses prompt:publish, the same scope as releasing a chat prompt. The two could deserve separate scopes — a skill reaches developer machines where a prompt reaches a request — but nobody has asked to grant one without the other, and a scope splits later more easily than it merges.

​
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. 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. 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 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) 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

Team

Assign roles to people.

API keys

Scope programmatic access.