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

# Resource Restrictions

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

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.

<table>
  <thead>
    <tr>
      <th>Resource Type</th>
      <th>Supported?</th>
      <th>Notes</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td><strong>Project</strong></td>
      <td><strong>✅</strong></td>
      <td>Only generative (LLM tracing) projects. Non-generative projects do not support this feature.</td>
    </tr>

    <tr>
      <td><strong>Dashboard</strong></td>
      <td><strong>✅</strong></td>
      <td>All dashboards support restriction.</td>
    </tr>
  </tbody>
</table>

## Who Can Restrict a Resource?

<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 or dashboard in the account</td>
    </tr>

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

    <tr>
      <td><strong>Space Admin</strong></td>
      <td><strong>✅</strong></td>
      <td>Projects and dashboards 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. For dashboards, only a Space Admin or above can restrict a dashboard today — see [Dashboard roles](#dashboard-roles) below for the current limits on granting access to one.
</Info>

## Roles

### Project roles

Once a project is restricted, you assign users one of three managed project roles — or a [custom role](/docs/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 [managed project roles table](/docs/ax/security-and-settings/sso-and-rbac/custom-roles#project).

### Dashboard roles

There are no managed dashboard roles. A [custom role](/docs/ax/security-and-settings/sso-and-rbac/custom-roles) can hold the dashboard permissions you need:

* **`DASHBOARD_READ`** — View the dashboard.
* **`DASHBOARD_UPDATE`** — Edit the dashboard's contents.
* **`DASHBOARD_DELETE`** — Delete the dashboard.

<Note>
  **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.
</Note>

## Restricting a Resource

### Via the UI

<Note>
  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](#via-the-rest-api) below.
</Note>

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

<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 resources without needing an explicit role assignment. You don't need to add them to the access list.
</Tip>

### Via the REST API

```bash theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
# 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={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
# Restrict a dashboard
curl -X POST https://api.arize.com/v2/resource-restrictions \
  -H "Authorization: Bearer <api-key>" \
  -H "Content-Type: application/json" \
  -d '{"resource_id": "<dashboard-id>"}'
```

```bash theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
# Remove a restriction (works for either resource type)
curl -X DELETE https://api.arize.com/v2/resource-restrictions/<resource-id> \
  -H "Authorization: Bearer <api-key>"
```

```bash theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
# List restrictions you're permitted to manage, optionally filtered by type
curl -X GET "https://api.arize.com/v2/resource-restrictions?resource_type=DASHBOARD" \
  -H "Authorization: Bearer <api-key>"
```

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

See the [RBAC REST API](/docs/ax/security-and-settings/sso-and-rbac/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](/docs/ax/security-and-settings/sso-and-rbac/rbac-rest-api) for details. Dashboard role bindings aren't supported through this endpoint yet — see [Dashboard roles](#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](/docs/ax/security-and-settings/sso-and-rbac/saml-configuration#configuring-a-role-mapping). 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.

<Note>
  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](#dashboard-roles) above.
</Note>

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.

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

## 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}`.

<Info>
  Unrestricting a resource does not delete existing role bindings. If you re-restrict it later, the previous role assignments will still be in effect.
</Info>

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

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

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

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

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

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

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

    <tr>
      <td>Frank</td>
      <td>Member</td>
      <td>Restricted dashboard</td>
      <td>None — dashboard role bindings aren't available yet</td>
      <td><strong>Cannot access</strong></td>
    </tr>
  </tbody>
</table>

## FAQ

<Accordion title="Which resources can be restricted?">
  Projects (generative/LLM tracing only) and dashboards. Non-generative projects do not support this feature.
</Accordion>

<Accordion title="How does dashboard access differ from project access?">
  Dashboards have no managed roles — access would come from a [custom role](/docs/ax/security-and-settings/sso-and-rbac/custom-roles) 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.
</Accordion>

<Accordion title="What happens to existing users when I restrict a resource?">
  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.
</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 resource 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 role binding on it (or an admin). A restricted dashboard is currently accessible only to admins, since dashboard role bindings aren't available yet.
</Accordion>

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