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

​
Who Can Restrict a Project?

RoleCan Restrict?Scope
Account Admin✅Any project in the account
Organization Admin✅Projects in their organization’s spaces
Space Admin✅Projects 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.

​
Project Roles

Once a project is restricted, you assign users one of three predefined 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 predefined project roles table.

​
Restricting a Project

​
Via the UI

  1. Navigate to the project you want to restrict.
  2. Open Project Settings (three-dot menu in the top right).
  3. In the Access Control section, select Restricted.
  4. Add users and assign each a project role (Viewer, Editor, Admin, or a custom 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 projects without needing an explicit role assignment. You don’t need to add them to the access list.

​
Via the REST API

# Restrict a project
curl -X POST https://api.arize.com/v2/resource-restrictions \
  -H "Authorization: Bearer <api-key>" \
  -H "Content-Type: application/json" \
  -d '{"resource_id": "<project-global-id>"}'

# Remove restriction
curl -X DELETE https://api.arize.com/v2/resource-restrictions/<project-global-id> \
  -H "Authorization: Bearer <api-key>"
See the RBAC REST API page for full endpoint details.

​
Granting Access to a Restricted Project

After restricting a project, grant access by assigning a project 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 role (Viewer, Editor, Admin, or a custom role).
  4. Click Add, then Save Changes.
You can also assign roles programmatically using POST /v2/role-bindings. See the RBAC REST API for details.

​
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.
Unrestricting a project does not delete existing role bindings. If you re-restrict the project later, the previous role assignments will still be in effect.

​
How Restrictions Interact with Space Roles

​
When a project is unrestricted (default)

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

​
When a project is restricted

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

​
Example Scenarios

UserSpace RoleProject StatusProject RoleResult
AliceMemberUnrestrictedNoneCan access (via space role)
BobMemberRestrictedNoneCannot access
CarolMemberRestrictedViewerCan view only (via project role)
DaveAdminRestrictedNoneFull access (admin override)
EveRead-onlyUnrestrictedEditorCan edit (project role overrides)

​
FAQ

No. Project-level restrictions are currently only supported for generative (LLM tracing) projects.
Any space member without an explicit project role binding immediately loses access to the project. They will no longer see it in their project 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 project role binding (or an admin).
AI provider management is a separate, organization-level capability. Project restrictions control access to project data (traces, spans, annotations). Managing AI provider integrations requires Organization Admin or Account Admin access regardless of project restrictions.