diff --git a/admin/project-management/add-members.mdx b/admin/project-management/add-members.mdx
index 7b97675c..7dbcba99 100644
--- a/admin/project-management/add-members.mdx
+++ b/admin/project-management/add-members.mdx
@@ -17,7 +17,7 @@ description: "Add members to your project to collaborate with your team."
### User roles
-Members in your organization can be assigned the following roles: Admin, Editor and Viewer. These roles determine what they can do inside of the platform, and what they can do when using the API.
+Members in your organization can be assigned the following roles: Admin, Editor, Chat, and Viewer. These roles determine what they can do inside of the platform, and what they can do when using the API.
@@ -41,19 +41,18 @@ Members in your organization can be assigned the following roles: Admin, Editor
- Can run agents and tools.
+
+ Access [Relevance Chat](/get-started/chat/introduction) only — cannot access the web app. Requires asset-level permissions to run specific agents.
+
- **Has read permissions for:**
-
- - All datasets
- - All knowledge sets
- - All agents
-
- **Other permissions:**
-
- - Can run agents.
+ View agents, tools, and knowledge outputs only. Cannot run agents, create assets, or edit anything.
+
+For comprehensive permission details including enterprise RBAC controls, see [Role-based access controls](/enterprise/rbac).
+
+
### Cancel pending invitations
If you've sent an invitation that hasn't been accepted yet, you can cancel it before the recipient responds. Only the person who created the invitation or a project admin can cancel pending invitations.
diff --git a/enterprise/rbac.mdx b/enterprise/rbac.mdx
index 1f147a64..a66b87e0 100644
--- a/enterprise/rbac.mdx
+++ b/enterprise/rbac.mdx
@@ -93,6 +93,10 @@ Project admins will be able to set a users role upon invite. Organization admins
| **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 |
+
+Editor is a project-level role only and does not exist at organization or asset levels. Project Editors automatically have Admin permissions on all assets within the project.
+
+
### Permissions
@@ -113,6 +117,9 @@ Scroll horizontally to view all columns, including the Chat role permissions.
| Access Web App | ✅ | ✅ | ✅ | ✅ | ❌ |
| Run a chat (LLM) | ✅ | ✅ | ✅ | ✅ | ✅ |
+
+Project Viewer access grants read-only visibility to full asset configurations — including prompts, tools, and steps. There is no field-level redaction. If a Viewer cannot see an agent's internals, it's because they lack asset-level access entirely, not because their read access is limited to metadata.
+
### Chat Role Details
@@ -180,6 +187,10 @@ Upon asset creation, the creator becomes the admin. An asset can have multiple a
| View asset outputs | ✅ | ✅ | ✅ |
| View asset audit logs | ✅ | ✅ | ✅ |
+
+Asset Viewer access grants read-only visibility to full asset configurations — including prompts, tools, and steps. There is no field-level redaction. If a Viewer cannot see an agent's internals, it's because they lack asset-level access entirely, not because their read access is limited to metadata.
+
+
----
## Workforce Permissions
@@ -211,6 +222,34 @@ Learn more about [sharing workforces](/build/workforces/share-your-workforce) as
----
+## Permission inheritance and cascading
+
+Permissions cascade automatically from project level to assets within that project:
+
+| Project role | Automatic asset access |
+| ------------ | ---------------------- |
+| **Admin** | Admin on all assets |
+| **Editor** | Admin on all assets |
+| **Viewer** | Viewer on all assets |
+
+
+Read access cascades automatically, but execution permissions (run/trigger) may require explicit asset-level grants due to known gaps in the system. If a project Viewer needs to run specific agents, grant them Member access at the asset level explicitly.
+
+
+Project Members do **not** automatically have access to all assets. Members must be granted asset-level permissions explicitly for each asset they need to access.
+
+----
+
+## Technical implementation notes
+
+The following is relevant primarily for API users and developers integrating directly with the authorization system.
+
+- **Member vs operator:** The "Member" role label in the UI maps to the `operator` role in the underlying authorization system. When querying permissions via the API, use `operator` rather than `member`.
+- **Authorization system:** The platform uses OpenFGA for authorization. Some parts of the system use a legacy authorization layer that may produce slightly different behavior in edge cases.
+- **Embeddable agents:** Agents shared via public embed links (Chat UI, Chat Widget) may behave differently under the legacy authorization system. Test permissions explicitly when deploying embedded agents.
+
+----
+
## Frequently asked questions (FAQs)