Skip to main content
Roles determine which resources members can access and what actions they can perform in Arize AX. Permissions are managed at the account, organization, and space levels, so you can give a team broad access to its own spaces while limiting who can change account settings or see data in other spaces.
Diagram of Arize AX access levels: an account contains organizations, and organizations contain spaces

Where roles are assigned

Every member has an account role and a role in each space they belong to. Accounts with more than one organization also assign organization roles. In a public space, a member without an explicit space role falls back to their organization role, so you can set a default at the organization and override it in the spaces that need a different role. Custom roles cover cases where the built-in roles grant too much or too little.

Managed roles

Arize AX includes managed roles at every level. These roles are ready to use and cannot be modified.

Account

Organization

Space

Project

Three managed project-level roles are designed for resource restrictions. You can also create custom roles with any combination of project-level permissions to suit your specific needs.

Developer access

Developer access is required to create API keys and service keys. It comes from the account role’s grants_developer_access attribute. An Account Admin can override developer access for one user in Account Settings, with PATCH /v2/users/{user_id} in the RBAC REST API, or with ax users update. Assigning an account role, even the same one, recomputes developer access from the role and drops the override. A SAML login that leaves the account role unchanged keeps it. Revoking developer access deletes the user’s API keys.
Account Admins can turn on the developer access lock under Account Settings → Security. While the lock is on, human users cannot call the REST or GraphQL APIs with user keys or OAuth credentials, and nobody can create or refresh an API key or service key, Account Admins included. Stored developer access is unchanged. Existing service keys keep working within their roles and scopes.

Custom roles

A custom role is a named, account-wide set of permissions. Only Account Admins create them. A role binding assigns one to a user on a space or project.
  1. Go to Account Settings → Roles and click New Role.
  2. Enter a name.
  3. Choose the permissions. The permission list is searchable. To start from an existing role, clone it from the roles table and edit the copy.
  4. Click Save Role.

Permission categories

When you create or edit a custom role, permissions are grouped into the categories below. You can select individual permissions within each category.
The AI Providers category grants read access only. On accounts created before July 27, 2026, managing AI provider integrations requires Organization Admin or Account Admin. Newer accounts also allow Space Admins and Account Members.
Managed Agents permissions control who can view and run agents in a space. Viewing Signal issues uses project read access. Enabling or configuring Signal uses project update. See Skills and permissions.

Role bindings

A role binding assigns a role to a user on one space or project, with at most one binding per user per resource. Effective access is the union of the built-in role and all bindings.

Assign roles

A role is assigned to a member on a space or, for restricted projects, on a project:
  • Invitation: Choose the role when you invite someone to a space. See Invite & Manage Members.
  • Members table: Go to Settings → Space Settings → Space Members, then change the member’s role in the table.
  • Project access: On a restricted project, open Config → Access Control and add the user with a project role.
  • SAML role mapping: Map identity provider attributes to roles so they are assigned at each sign-in. See SAML Configuration.
  • REST API: See the RBAC REST API.