Skip to main content
By default, every resource in a space inherits access from the space — anyone who is a member of the space can see and interact with it. Resource restrictions let you override this behavior for individual projects and dashboards. When you restrict a resource, it becomes opt-in. Only users who have been explicitly granted a role on that resource (or space, organization, and account admins) can access it. Everyone else in the space loses visibility into it.
Resource TypeSupported?Notes
Project✅Only generative (LLM tracing) projects. Non-generative projects do not support this feature.
Dashboard✅All dashboards support restriction.

​
Who Can Restrict a Resource?

RoleCan Restrict?Scope
Account Admin✅Any project or dashboard in the account
Organization Admin✅Projects and dashboards in their organization’s spaces
Space Admin✅Projects and dashboards in their space
Space Member❌—
Space Read-only❌—
Project Admins (a project-level role) can manage access on an already-restricted project, but a Space Admin or above is required to initially enable restrictions. For dashboards, only a Space Admin or above can restrict a dashboard today — see Dashboard roles below for the current limits on granting access to one.

​
Roles

​
Project roles

Once a project is restricted, you assign users one of three managed project roles — or a custom role:
  • Project Viewer — Read-only access. Can view traces, spans, metrics, and evaluations.
  • Project Editor — Everything a Viewer can do, plus create and update spans, annotate traces, and manage evaluation tasks.
  • Project Admin — Everything an Editor can do, plus delete the project and manage access restrictions.
For a detailed permissions breakdown, see the managed project roles table.

​
Dashboard roles

There are no managed dashboard roles. A custom role can hold the dashboard permissions you need:
  • DASHBOARD_READ — View the dashboard.
  • DASHBOARD_UPDATE — Edit the dashboard’s contents.
  • DASHBOARD_DELETE — Delete the dashboard.
Rolling out: Binding one of these custom roles to a specific dashboard isn’t available yet — POST /v2/role-bindings currently only accepts SPACE and PROJECT resources, and the dashboard Access Control UI hasn’t shipped. Until dashboard role bindings ship, restricting a dashboard leaves it accessible only to space, organization, and account admins.

​
Restricting a Resource

​
Via the UI

This UI flow is currently available for projects only. The dashboard version is rolling out — until it’s available, restrict and manage access on dashboards through the REST API below.
  1. Navigate to the project you want to restrict.
  2. Open Settings (three-dot menu in the top right).
  3. In the Access Control section, select Restricted.
  4. Add users and assign each a managed project role.
  5. Click Save Changes.
Project three-dot menu showing Config option
Access Control section with Unrestricted and Restricted options
Manage Project Access dialog showing user search and role assignment
Space admins, organization admins, and account admins always retain access to restricted resources without needing an explicit role assignment. You don’t need to add them to the access list.

​
Via the REST API

Results from the list endpoint are filtered by what you’re permitted to manage after a page is read. A page can be short — or empty — while has_more is still true. Keep paging with cursor until has_more is false; do not stop on an empty page.
See the RBAC REST API page for full endpoint details.

​
Granting Access to a Restricted Resource

After restricting a project, grant access via the UI by assigning a role binding to each user who needs it:
  1. Open the restricted project’s Settings → Access Control section.
  2. Search for the user you want to add.
  3. Select a managed project role.
  4. Click Add, then Save Changes.
You can also assign project roles programmatically using POST /v2/role-bindings. See the RBAC REST API for details. Dashboard role bindings aren’t supported through this endpoint yet — see Dashboard roles above.

​
Via SAML Role Mapping

For organizations using SAML SSO, you can provision project-level access automatically as part of your SAML role mappings. When configuring a role mapping, you can add project assignments within each space assignment — specifying a project role (Viewer, Editor, Admin, or custom) for any restricted project in that space.
SAML role mappings currently support project-level assignments only. Dashboard role bindings aren’t yet assignable through any path — UI, REST, or SAML — see Dashboard roles above.
When a user logs in via SAML and matches the role mapping, they are automatically granted the configured project roles. If Sync permissions on each login is enabled, project role bindings are re-evaluated on every login to stay in sync with your IdP.
This eliminates the need to manually add users to restricted projects after provisioning. Define your project access rules in your IdP and let SAML handle the rest.

​
Modifying Access

  1. Open the restricted project’s Settings → Access Control section.
  2. To change a role: use the role dropdown next to the user’s name.
  3. To remove a user: click the remove button next to their entry.
  4. To add a new user: search and add them with a role.
  5. Click Save Changes.

​
Removing Restrictions

  1. Open the restricted project’s Settings → Access Control section.
  2. Select Unrestricted.
  3. Confirm that all space members will regain access.
For a dashboard, remove the restriction with DELETE /v2/resource-restrictions/{resource_id}.
Unrestricting a resource does not delete existing role bindings. If you re-restrict it later, the previous role assignments will still be in effect.

​
How Restrictions Interact with Space Roles

​
When a resource is unrestricted (default)

  • Space-level roles apply as normal.
  • All space members can access the resource based on their space role.
  • If a user also has a role binding on the resource itself, the more permissive access applies.

​
When a resource is restricted

  • Space-level membership alone does not grant access.
  • Only explicit role bindings on the resource grant access.
  • Exception: Space admins, organization admins, and account admins always retain full access.

​
Example Scenarios

UserSpace RoleResource StatusResource RoleResult
AliceMemberUnrestricted projectNoneCan access (via space role)
BobMemberRestricted projectNoneCannot access
CarolMemberRestricted projectViewerCan view only (via project role)
DaveAdminRestricted projectNoneFull access (admin override)
EveRead-onlyUnrestricted projectEditorCan edit (project role overrides)
FrankMemberRestricted dashboardNone — dashboard role bindings aren’t available yetCannot access

​
FAQ

Projects (generative/LLM tracing only) and dashboards. Non-generative projects do not support this feature.
Dashboards have no managed roles — access would come from a custom role holding the dashboard permissions you need (DASHBOARD_READ, DASHBOARD_UPDATE, DASHBOARD_DELETE). You can restrict a dashboard today via POST /v2/resource-restrictions, but binding a role to it isn’t available yet through the UI or the REST API — until it ships, a restricted dashboard is accessible only to space, organization, and account admins.
Any space member without an explicit role binding on that resource immediately loses access. They will no longer see it in their project or dashboard list. Make sure to add all necessary users before or at the time of restricting.
Yes. A Project Admin on a restricted project can add, remove, and change roles for other users on that project.
Yes. The same access control enforcement applies to API and programmatic access. If a project is restricted, API calls must be authenticated as a user with an appropriate role binding on it (or an admin). A restricted dashboard is currently accessible only to admins, since dashboard role bindings aren’t available yet.
AI provider management is a separate, organization-level capability. Resource restrictions control access to project and dashboard data. Managing AI provider integrations requires Organization Admin or Account Admin access regardless of resource restrictions.