Skip to main content

​
Single Sign On

Arize AX supports Single Sign-On via SAML2. Configure your Identity Provider with the following information about the Arize Service:
  • SSO URL / ACS (Assertion Consumer Service) : https://app.arize.com/auth/v2/saml
  • URI / EntityID: https://app.arize.com
  • UserName / NameID format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
If needed for your Identity Provider, Arize SAML metadata.xml can be downloaded from https://app.arize.com/auth/v2/saml/metadata
To configure SAML settings, role mappings, and user provisioning, see the SAML Configuration page.

SAML Configuration

​
Role Based Access Control

Arize AX supports full role-based access control. Using organizations and spaces, users can be restricted to only have access to data they are permitted. Your Arize AX account can consist of multiple organizations and spaces. In addition to built-in roles, Arize AX supports fine-grained custom roles that can be assigned at the space or project level for more granular access control.

Custom Roles

Create roles with fine-grained permissions

Resource Restrictions

Restrict access to sensitive projects and dashboards

RBAC REST API

Manage access control programmatically

​
Account

You are a member of one Arize AX account. An account consists of one or more organizations. Admin - Has full access to all entities in the account. Can manage users, create organizations, manage custom roles, and configure AI provider integrations. Member - Access is determined by organization and space roles.
ActionAdminMember

User management

  • Remove users and change user roles
✅❌

Invite users

✅Up to Member/Annotator
Create organizations✅❌
Create and manage custom roles✅❌
Manage AI provider integrations✅❌
Create User keys✅If the account role has developer access: ✅
If not: ❌
Create Service keys✅If the account role has developer access and has access to the target space: ✅
If not: ❌

​
Developer Access

Developer access controls whether a user can create User keys and Service keys. It is derived from the user’s assigned account role rather than set per user at invite time — each account role carries a grants_developer_access attribute. Assigning or changing a user’s account role recomputes their developer flag from the new role. An Account Admin can still override the flag for one user, either in Account Settings or via PATCH /v2/users/{user_id} in the RBAC REST API (the CLI’s ax users update supports the same override). Assigning the user a new account role recomputes the flag from that role, replacing the override — even if the assigned role is the same as before. The one exception is SAML: a login that leaves the user’s account role unchanged preserves the override; see SAML Configuration for details. Revoking developer access deletes the user’s existing API keys. Account admins always retain API key access regardless of this flag.
The account-wide developer access lock (Account Settings → Security) blocks human users from the programmatic REST and GraphQL APIs. It does not change stored developer access or prevent an Account Admin from granting it. Human users cannot use user keys or OAuth credentials with these APIs while the lock is on. No user can create or refresh a user key or service key through the UI or API while the lock is on.Existing service keys continue to access the REST API while the lock is on. Each service key remains limited to its assigned roles and resource scopes. Turning the lock off restores human API access according to each user’s stored developer access.

​
Organizations

Organizations represent a single business unit and help you silo work across different areas of your business. Within your account, you can be a member of multiple Organizations. An Organization may consist of one or more spaces. Admin - Has full access to all entities in the organization, including AI provider integrations. Member - Has partial access at the organizational level. Can create spaces and integration keys. They can only edit or delete integration keys they create. Space access is determined by space role. Read-only Member - Has read-only access to the organization. Cannot create spaces nor integration keys. Public space access is read-only unless added to the space. Private space access is determined by space role.
ActionAdminMemberRead-only Member

Organization Member management

  • Invite and remove members and change their roles
✅❌❌
Create spaces✅✅❌
View public spaces✅✅✅
Edit public spaces✅✅❌ (unless explicitly added)
View private spaces✅

If added to space: ✅

If not: ❌

If added to space: ✅

If not: ❌

Create integration keys✅✅❌
Edit / delete integration keys✅If creator: ✅
If not: ❌		❌
Manage AI provider integrations✅❌❌

​
Spaces

Spaces represent an environment for groups of models. You can be a member of multiple spaces across multiple organizations within your account. Spaces can either be public or private. Public Spaces are visible to all members (regardless of role) of the parent organization. Private spaces are only visible to explicitly invited members of the space. Admin - Has full access to all entities in the space. Member - Has write access to entities associated to models (e.g., monitors) but does not have access to membership management. Read-only Member - Has read-only access to entities in the space. Due to popular customer request, read-only members are still able to run the prompt playground. Annotator - Has access only to assigned items in the labeling queue.
ActionAdminMemberRead-onlyAnnotator

Space Member management

  • Invite and remove members and change their roles
✅❌❌❌
Create Projects✅✅❌❌
Delete Projects✅❌❌❌
Send traces✅✅❌❌
Create and delete file import jobs✅❌❌❌
Update model settings✅✅❌❌
Create/Edit Dashboards✅✅❌❌
Create/Edit Monitors✅✅❌❌
View project entities (Datasets, monitors, dashboards etc.)✅✅✅❌
Create/Edit Evaluation Tasks✅✅❌❌
Create/Edit Datasets✅✅❌❌
Run Experiments✅✅❌❌
Annotate on Spans✅✅❌❌
Create/Edit/Delete Prompts✅✅❌❌
Create/Edit Evaluators✅✅❌❌
Create/Edit Custom Metrics✅✅❌❌
Manage Tags✅✅❌❌
View/Manage Data Fabric✅✅❌❌
Access Annotation Queues✅✅✅✅
Run Playground✅✅✅❌
Managing AI provider integrations (creating, updating, deleting) requires Organization Admin or Account Admin access. Space-level roles do not grant AI provider management permissions.
For more granular control over permissions, you can create custom roles and assign them to specific users at the space or project level.

​
Invite Users

Want to invite team members?
  1. Go to ‘Account Settings’ —> Members —> Add Members
  2. Go to ‘Org Settings’ —> Members —> Add Members
  3. Go to ‘Space Settings’ —> Members —> Add Members
When adding a member, you will select their permission level for your Account, Organization, and Space. You can also invite and manage users programmatically — including listing, updating, and removing users across your account, organizations, and spaces. See the RBAC REST API for the full endpoint reference, or go directly to the interactive API docs.

​
Who Can Invite Whom

A user can invite another user at a role up to their own account role — never above it. An Account Annotator’s own role has no invite privileges, so an Annotator cannot invite anyone. This ceiling applies wherever an invite can be sent: the UI, POST /v2/users, and the CLI. Resending an invitation is subject to the same authorization as sending one.

​
Troubleshooting Invite Errors

This generic error can be triggered by several conditions:
  • Email already exists in the system — If the email address is associated with an active or inactive user (even in a different account), the invite will be rejected. Check whether the user already has an Arize account with that email.
  • Missing required fields — A role (admin, member, annotator) must be assigned at invite time.
  • SAML misconfiguration — If the email domain matches a configured IdP and the configuration is invalid (e.g., bad metadata), the invite may be blocked. Verify your SAML metadata is correct in SAML Configuration.
If none of the above apply, contact Arize support.
You tried to invite (or resend an invite to) a user at a role above your own account role. See Who Can Invite Whom for the ceiling that applies to your role.
No. If Allow Only SAML Logins is off, invites work the same as for accounts without SSO. Role mappings and the “Sync permissions on each login” setting are login-time features and have no effect on the invite flow.

​
Configuration Changes

To re-name an organization:
  1. Go to ‘Organization Settings’ —> Config
  2. Go to ‘Space Settings’ —> Config
Note: project names are defined when tracing is set up. They are not configurable in the UI.

​
JIT User Provisioning

To enable just-in-time user provisioning, it’s recommended to provide an attribute Name or http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name that maps to the full name of the user to properly create the First/Last Name for the user in Arize AX. Arize also supports automated role assignment during JIT provisioning, enabling you to enforce role-based access control. To configure this, you can declare a mapping between the values of a specified SAML attribute from your Identity Provider (idP) and corresponding Arize user roles. For example, if you have an attribute for team/department in your idP (e.g., "Department": "Ads ML Engineering"), you can map that attribute to a specific Space/Org role in Arize AX. Role mappings also support assigning custom roles for fine-grained permissions, as well as project-level role bindings on restricted projects — so sensitive projects can be provisioned entirely through your IdP without any manual access management. These attributes need to be included in the SAML assertion/response. Below is an example configuration:
Once this configuration is set, Arize AX will automatically assign the appropriate roles when provisioning users via SSO, based on your role mapping. To configure SAML settings, see the SAML Configuration page.

SAML Configuration