> ## Documentation Index
> Fetch the complete documentation index at: https://arize-ax.mintlify.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Project-Level Restrictions

> Restrict access to sensitive projects so only users with explicit role assignments can view them.

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.

<Note>
  Only generative (LLM tracing) projects can be restricted. Non-generative projects do not support this feature.
</Note>

## Who Can Restrict a Project?

<table>
  <thead>
    <tr>
      <th>Role</th>
      <th width="140">Can Restrict?</th>
      <th>Scope</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td><strong>Account Admin</strong></td>
      <td><strong>✅</strong></td>
      <td>Any project in the account</td>
    </tr>

    <tr>
      <td><strong>Organization Admin</strong></td>
      <td><strong>✅</strong></td>
      <td>Projects in their organization's spaces</td>
    </tr>

    <tr>
      <td><strong>Space Admin</strong></td>
      <td><strong>✅</strong></td>
      <td>Projects in their space</td>
    </tr>

    <tr>
      <td><strong>Space Member</strong></td>
      <td>❌</td>
      <td>—</td>
    </tr>

    <tr>
      <td><strong>Space Read-only</strong></td>
      <td>❌</td>
      <td>—</td>
    </tr>
  </tbody>
</table>

<Info>
  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.
</Info>

## Project Roles

Once a project is restricted, you assign users one of three predefined project roles — or a [custom role](/ax/security-and-settings/sso-and-rbac/custom-roles):

* **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](/ax/security-and-settings/sso-and-rbac/custom-roles#predefined-project-roles).

## 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**.

<Frame>
  <img src="https://storage.googleapis.com/arize-assets/rbac/project-settings-three-dot-menu.png" alt="Project three-dot menu showing Config option" />
</Frame>

<Frame>
  <img src="https://storage.googleapis.com/arize-assets/rbac/access-control-restricted-toggle.png" alt="Access Control section with Unrestricted and Restricted options" />
</Frame>

<Frame>
  <img src="https://storage.googleapis.com/arize-assets/rbac/manage-project-access-dialog.png" alt="Manage Project Access dialog showing user search and role assignment" />
</Frame>

<Tip>
  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.
</Tip>

### Via the REST API

```bash theme={null}
# 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-id>"}'
```

```bash theme={null}
# Remove restriction
curl -X DELETE https://api.arize.com/v2/resource-restrictions/<project-id> \
  -H "Authorization: Bearer <api-key>"
```

See the [RBAC REST API](/ax/security-and-settings/sso-and-rbac/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](/ax/security-and-settings/sso-and-rbac/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.

<Info>
  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.
</Info>

## 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

<table>
  <thead>
    <tr>
      <th>User</th>
      <th width="120">Space Role</th>
      <th width="120">Project Status</th>
      <th width="120">Project Role</th>
      <th>Result</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>Alice</td>
      <td>Member</td>
      <td>Unrestricted</td>
      <td>None</td>
      <td>Can access (via space role)</td>
    </tr>

    <tr>
      <td>Bob</td>
      <td>Member</td>
      <td>Restricted</td>
      <td>None</td>
      <td><strong>Cannot access</strong></td>
    </tr>

    <tr>
      <td>Carol</td>
      <td>Member</td>
      <td>Restricted</td>
      <td>Viewer</td>
      <td>Can view only (via project role)</td>
    </tr>

    <tr>
      <td>Dave</td>
      <td>Admin</td>
      <td>Restricted</td>
      <td>None</td>
      <td>Full access (admin override)</td>
    </tr>

    <tr>
      <td>Eve</td>
      <td>Read-only</td>
      <td>Unrestricted</td>
      <td>Editor</td>
      <td>Can edit (project role overrides)</td>
    </tr>
  </tbody>
</table>

## FAQ

<Accordion title="Can I restrict a non-generative project?">
  No. Project-level restrictions are currently only supported for generative (LLM tracing) projects.
</Accordion>

<Accordion title="What happens to existing users when I restrict a project?">
  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.
</Accordion>

<Accordion title="Can a Project Admin add other Project Admins?">
  Yes. A Project Admin on a restricted project can add, remove, and change roles for other users on that project.
</Accordion>

<Accordion title="Do API keys respect project restrictions?">
  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).
</Accordion>

<Accordion title="How does this relate to AI provider permissions?">
  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.
</Accordion>