> ## Documentation Index
> Fetch the complete documentation index at: https://relevanceai.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Role-based access controls (RBAC)
> Enhancing security, collaboration, and control for Enterprise teams
RBAC is gradually being rolled out to our Enterprise customers. If you have an Enterprise subscription with Relevance AI and do not have access to this feature yet, please reach out to your sales representative to share your interest in this feature.
You will not be able to access this feature if you are not on an Enterprise subscription.
Role-based access controls (RBAC) in Relevance AI is a security and governance feature that allows organizations to manage user access based on predefined roles and responsibilities. It ensures that individuals only have access to the data, tools, and platform functions necessary for their role, supporting operational control, collaboration, and compliance across teams.
These new controls are designed to enhance security for our Enterprise clients by providing granular permissions at different levels.
There are three main levels: org-level roles (Owner, Admin, Member, Viewer), project-level roles (Admin, Editor, Member, Chat, Viewer), and asset-level roles (Admin, Member, Viewer).
Each role has specific permissions that dictate what users can do within the platform, such as managing credits, using agents, accessing integrations, and using Chat.
This means you can tailor access based on the needs of your team, ensuring that sensitive information and functionalities are only available to those who need them.
## Best Practices
Keep permissions simple. Assign roles based on who needs to build, who needs to view, who needs to chat, and who needs to govern.
### Organization Level
* **Owners** — have full control including billing and can delete the organization. Assign to 1-2 people maximum (CEO, CTO, or Head of Operations). Owners have all Admin permissions plus billing control.
* **Admins** — set up and manage teams, projects, and authentication. Usually your workspace or IT leads.
* **Members** — can only access projects they're assigned to. Cannot create projects at the organization level. Asset creation within projects is controlled by project-level permissions. Best for users who need access to specific projects but shouldn't manage organization-wide settings.
* **Viewers** — view-only access to audit logs, usage data, and compliance reports. Use this for stakeholders who need visibility without operational access.
### Project Level
* **Admins** — own the project setup and governance. They control permission and authentication accounts.
* **Editors** — build, edit, and run all assets in the project. Treat them as your core contributors.
* **Members** — can build their own assets but don't automatically see or edit others'. Great for independent work within shared projects.
* **Chat** — access [Relevance Chat](/get-started/chat/introduction) only, cannot access the web app. Perfect for users who only need to interact with agents through chat. Requires asset-level permissions to run specific agents.
* **Viewers** — can't build or edit. Add them only to the specific assets they need to see.
Keep admin/editor access limited to people actively managing or building. Everyone else should be a member or viewer by default.
### Asset Level
* Project admins and editors automatically have full control.
* Members can run assets but can't modify them unless granted edit rights.
* Viewers can only see results or outputs — they can't run or trigger anything.
Default to least privilege. Grant edit rights intentionally, not by habit.
## Organization level controls
New organization members will be given viewer permissions by default. If invited, their role will be selected during invite.
### Roles
| **Role** | **Capabilities** |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Owner** | Full control of organization, billing, security, users and all projects |
| **Admin** | Manage users, projects, organization-level API keys and OAuths |
| **Member** | Access only assigned projects. Cannot create projects at organization level. Asset creation within projects is controlled by project-level permissions. |
| **Viewer** | View-only access to agent and tool audit logs, usage data and compliance reports |
### Permissions
| **Permission** | **Owner** | **Admin** | **Member** | **Viewer** |
| :----------------------------------------------------- | :-------- | :-------- | :--------- | :--------- |
| Manage billing | ✅ | ❌ | ❌ | ❌ |
| Manage organization settings (name, logo, domain etc.) | ✅ | ✅ | ❌ | ❌ |
| Manage organization users | ✅ | ✅ | ❌ | ❌ |
| Manage API keys & OAuths (Org-level connections) | ✅ | ✅ | ❌ | ❌ |
| View global audit logs | ✅ | ✅ | ❌ | ❌ |
| View all projects and agents | ✅ | ✅ | ❌ | ❌ |
| Delete any asset | ✅ | ✅ | ❌ | ❌ |
| Edit project roles | ✅ | ✅ | ❌ | ❌ |
| View credit information | ✅ | ✅ | ❌ | ❌ |
| Create projects | ✅ | ✅ | ❌ | ❌ |
| View organization members / admins | ✅ | ✅ | ✅ | ✅ |
***
## Project level controls
Project admins will be able to set a users role upon invite. Organization admins can also set this for any project.
### Roles
| **Role** | **Capabilities** |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| **Admin** | Manage users, agents, tools, knowledge and project-level integrations. Can create assets |
| **Editor** | Can edit and create assets, does not manage users |
| **Member** | Use shared assets, provide inputs and view outputs. Can create assets, private by default. |
| **Chat** | Access [Relevance Chat](/get-started/chat/introduction) only - cannot access the web app. Requires asset-level permissions to run agents. |
| **Viewer** | View agents, tools, and knowledge outputs only, cannot run or edit anything |
### Permissions
Scroll horizontally to view all columns, including the Chat role permissions.
| **Permission** | **Admin** | **Editor** | **Member** | **Viewer** | **Chat** |
| :------------------------------------- | :-------- | :--------- | :--------- | :--------- | :------- |
| Delete project | ✅ | ❌ | ❌ | ❌ | ❌ |
| Assign project roles to users | ✅ | ❌ | ❌ | ❌ | ❌ |
| Manage project-level API keys & OAuths | ✅ | ❌ | ❌ | ❌ | ❌ |
| Delete agents | ✅ | ✅ | ❌ | ❌ | ❌ |
| View all assets by default | ✅ | ✅ | ❌ | ❌ | ❌ |
| Edit/run assets they did not create | ✅ | ✅ | ❌ | ❌ | ❌ |
| View project activity logs | ✅ | ✅ | ❌ | ❌ | ❌ |
| Create assets | ✅ | ✅ | ✅ | ❌ | ❌ |
| View Project | ✅ | ✅ | ✅ | ✅ | ❌ |
| Access Web App | ✅ | ✅ | ✅ | ✅ | ❌ |
| Run a chat (LLM) | ✅ | ✅ | ✅ | ✅ | ✅ |
### Chat Role Details
The Chat role is a new feature being gradually rolled out to Enterprise customers. If you have an Enterprise subscription with Relevance AI and do not have access to this feature yet, please reach out to your sales representative to share your interest in this feature.
The **Chat** role is designed for users who only need to interact with AI agents through [Relevance Chat](/get-started/chat/introduction) without accessing the main web application. Key characteristics:
Chat role users can only see and run agents they have Member or higher permissions on. They won't be able to see any other agents in Chat. This allows you to control exactly which agents each Chat user can access by assigning asset-level permissions.
Users with this role are automatically redirected to Chat and cannot access the web app.
Cannot create new agents, tools, or knowledge bases.
Can have conversations with LLMs and in-built Chat Agents directly without agents.
Can trigger Chat and interact with agents (with proper asset permissions).
Cannot create assets or access the web app.
This role is ideal for end users, external collaborators, or team members who only need to use pre-built agents through the chat interface.
***
## Asset level controls
An asset is an Agent, Tool, Knowledge or Workforce.
Upon asset creation, the creator becomes the admin. An asset can have multiple admins (project admin is by default).
### Roles
| **Role** | **Capabilities** |
| ---------- | ------------------------------------------------------------------------- |
| **Admin** | Manage asset configuration, tools, knowledge and assign asset-level users |
| **Member** | Use asset only, provide inputs and view outputs |
| **Viewer** | View asset configuration and outputs only, cannot run or edit anything |
### Permissions
| **Permission** | **Admin** | **Member** | **Viewer** |
| :------------------------------ | :-------- | :--------- | :--------- |
| Edit asset | ✅ | ❌ | ❌ |
| Delete asset | ✅ | ❌ | ❌ |
| Assign roles on asset | ✅ | ❌ | ❌ |
| Assign auth per tool | ✅ | ❌ | ❌ |
| Enable cloning/sharing of asset | ✅ | ❌ | ❌ |
| Create tasks on asset | ✅ | ✅ | ❌ |
| View asset configuration | ✅ | ✅ | ✅ |
| View asset outputs | ✅ | ✅ | ✅ |
| View asset audit logs | ✅ | ✅ | ✅ |
***
## Workforce Permissions
Workforces are treated as first-class assets in the RBAC system. However, running a workforce requires permissions at two levels:
1. **Workforce permission** - The user must have at least Member (run) access to the workforce itself
2. **Agent permissions** - The user must have at least Member (run) access to each agent used within the workforce
This means when sharing a workforce, you must:
* Share the workforce with the user at the desired permission level
* Share each agent in the workforce at a matching (or higher) permission level
### Example scenarios
| Goal | Workforce Role | Agent Roles |
| ------------------------- | -------------- | -------------------- |
| User can run workforce | Member | Member on all agents |
| User can edit workforce | Admin | Admin on all agents |
| User can view but not run | Viewer | Viewer on all agents |
**Note:** If a user has run access to a workforce but lacks permissions on one or more agents, they will see a "Cannot run agent" warning in the workforce builder and will be unable to execute the workflow.
Learn more about [sharing workforces](/build/workforces/share-your-workforce) as cloneable templates.
***
## Frequently asked questions (FAQs)
No. This feature is available for Enterprise subscriptions only.
This feature is gradually being rolled out to Enterprise customers. Please reach out to your sales representative to express your interest in receiving this feature.
To limit a user to only access [Relevance Chat](/get-started/chat/introduction), assign them the **Chat** role at the project level. Users with the Chat role are automatically redirected to Chat and cannot access the main web application. They can still interact with agents and have LLM conversations, but will need appropriate asset-level permissions (Member or higher) on specific agents to run them in Chat.
Yes, assigning a user the Asset Member role for a specific agent allows them to create tasks on the agent, approve/reject escalations, and view outputs, but not edit or delete the agent's configuration.