diff --git a/docs/features/authentication-access/rbac/roles.md b/docs/features/authentication-access/rbac/roles.md index bd92fd0d..7a50478a 100644 --- a/docs/features/authentication-access/rbac/roles.md +++ b/docs/features/authentication-access/rbac/roles.md @@ -22,7 +22,7 @@ The Admin role is designed for system maintainers. :::warning Admin Limitations & Best Practices While Administrators generally have unrestricted access, certain system configurations can limit their capabilities for security and privacy: -* **Privacy Controls**: Environment variables like [`ENABLE_ADMIN_CHAT_ACCESS=False`](/reference/env-configuration#enable_admin_chat_access) can prevent Admins from viewing user chats. +* **Privacy Controls**: [`ENABLE_ADMIN_CHAT_ACCESS=False`](/reference/env-configuration#enable_admin_chat_access) hides user chats from admins in the interface. It does not keep an admin away from the data; see [Chat Data Privacy](/security/chat-data-privacy-and-encryption#admin-users). * **Feature-Specific Exceptions May Apply**: Some features can enforce additional checks beyond the standard admin bypass behavior. For API keys specifically, admins can generate keys whenever `ENABLE_API_KEYS` is enabled. * **Access Control Exceptions**: If `BYPASS_ADMIN_ACCESS_CONTROL` is disabled, Admins are checked against access grants like everyone else. A private workspace item (model, knowledge base, prompt, tool, skill, note) is visible only to its owner and to the people it is shared with. Admin-configured connections and arena models with no grants stay admin-only. See [What Private Means for Each Resource Type](/features/authentication-access/rbac/groups#what-private-means-for-each-resource-type). diff --git a/docs/features/chat-conversations/chat-features/subagents.mdx b/docs/features/chat-conversations/chat-features/subagents.mdx index 6c5662c0..22c27142 100644 --- a/docs/features/chat-conversations/chat-features/subagents.mdx +++ b/docs/features/chat-conversations/chat-features/subagents.mdx @@ -85,6 +85,8 @@ Sub-agents are deliberately narrower than the chat that starts them: - **No code interpreter in the background**, unless the engine is Jupyter, since the browser-based Pyodide engine needs a live session. - **No user tool servers in the background.** A foreground sub-agent inherits the tool servers the user added in their own Settings, which run from the browser; a background one does not. Tool servers an admin added (OpenAPI and MCP) stay available to both. If a delegated task depends on a [user tool server](/features/extensibility/plugin/tools/openapi-servers/open-webui), keep it in the foreground. +Each sub-agent runs in its own chat. These chats are hidden from chat lists and search, and are deleted together with the parent chat. Admins can read them by id even with [`ENABLE_ADMIN_CHAT_ACCESS`](/reference/env-configuration#enable_admin_chat_access) off. + ## Cost Every delegation is another full chat completion, with the same model and tools, and may loop up to the iteration limit. One reply can start several at once, and each background result restarts the parent chat to process it, which is another turn. diff --git a/docs/reference/env-configuration.mdx b/docs/reference/env-configuration.mdx index 722ff964..81894101 100644 --- a/docs/reference/env-configuration.mdx +++ b/docs/reference/env-configuration.mdx @@ -649,7 +649,7 @@ Treat anything in this cluster as *what the admin sees and does in the product U - Type: `bool` - Default: `True` -- Description: Controls whether admins can open other users' chats inside Open WebUI. When enabled, an admin can read any user's chat, which opens read-only. Through the API the admin can also edit or delete its messages, delete the chat, change its share settings and clone it. Replying, regenerating, stopping replies and approving tool calls stay with the owner and anyone the chat is shared with through [Allow replies](/features/chat-conversations/chat-features/chatshare#allowing-replies). When disabled, the admin panel hides other users' chats, the **Sessions** view in [Analytics](/features/administration/analytics#sessions) is hidden and its endpoints return `403`, and the chat endpoints give an admin only what a share gives them. The admin-only `GET /api/tasks` and `POST /api/tasks/stop/{task_id}` endpoints still list and stop any running task, whatever this setting says. If you disable this, consider also disabling `ENABLE_ADMIN_EXPORT` (especially on SQLite), since exports include user chats. The toggle covers the product surface only: an admin can still reach every chat through the database, the server itself or a Function or Tool. See the admin-posture-toggles note above. +- Description: Controls whether admins can open other users' chats inside Open WebUI. It hides chats in the product and does not keep an admin away from the data; see [Chat Data Privacy](/security/chat-data-privacy-and-encryption#admin-users). When enabled, an admin can read any user's chat, which opens read-only. Through the API the admin can also edit or delete its messages, delete the chat, change its share settings and clone it. Replying, regenerating, stopping replies and approving tool calls stay with the owner and anyone the chat is shared with through [Allow replies](/features/chat-conversations/chat-features/chatshare#allowing-replies). When disabled, the admin panel hides other users' chats, the **Sessions** view in [Analytics](/features/administration/analytics#sessions) is hidden and its endpoints return `403`, and the chat endpoints give an admin only what a share gives them. The admin-only `GET /api/tasks` and `POST /api/tasks/stop/{task_id}` endpoints still list and stop any running task, whatever this setting says. If you disable this, consider also disabling `ENABLE_ADMIN_EXPORT` (especially on SQLite), since exports include user chats. The toggle covers the product surface only: an admin can still reach every chat through the database, the server itself or a Function or Tool. See the admin-posture-toggles note above. **Exception for internal chats:** admins can still retrieve a chat marked internal even when this is `False`. Internal chats are the ones Open WebUI creates on a user's behalf without the user opening them: [sub-agent](/features/chat-conversations/chat-features/subagents) chats, [timer](/features/chat-conversations/chat-features/timers) chats and note-attached chats. This carve-out is what lets an admin retrieve one at all, because internal chats are **excluded from the chat listing surfaces**: they do not appear in chat lists, search, counts, exports or the admin chat list. Apart from the **Sessions** view in Analytics, which lists them with every other chat, they are reachable only by id. diff --git a/docs/security/chat-data-privacy-and-encryption.mdx b/docs/security/chat-data-privacy-and-encryption.mdx index cd029b7e..76865d35 100644 --- a/docs/security/chat-data-privacy-and-encryption.mdx +++ b/docs/security/chat-data-privacy-and-encryption.mdx @@ -15,7 +15,7 @@ Open WebUI's standard experience is designed for self-hosted control, auditabili | Concern | Best available measure | | :--- | :--- | -| Reduce admin product access to employee chats | Set `ENABLE_ADMIN_CHAT_ACCESS=false` | +| Hide user chats from admins in the interface | Set `ENABLE_ADMIN_CHAT_ACCESS=false` | | Control admin product exports | Set `ENABLE_ADMIN_EXPORT=false` | | Scope admin workspace list/selector visibility | Set `BYPASS_ADMIN_ACCESS_CONTROL=false` | | Production database storage exposure | Use PostgreSQL with encrypted volumes, provider encryption, TDE where available, TLS, and encrypted backups | @@ -41,7 +41,7 @@ DATABASE_URL=postgresql://user:password@db-host:5432/openwebui Database encryption protects data at rest. The running Open WebUI application uses the database key to serve authenticated users and normal product workflows. -For SQLite-only deployments, put the data directory on an encrypted filesystem (LUKS on Linux, BitLocker on Windows, FileVault on macOS). SQLCipher is not supported since v0.9.0. +For SQLite-only deployments, put the data directory on an encrypted filesystem (LUKS on Linux, BitLocker on Windows, FileVault on macOS). SQLCipher is not supported. ### Limit Admin Chat and Export Surfaces @@ -51,7 +51,7 @@ ENABLE_ADMIN_EXPORT=false BYPASS_ADMIN_ACCESS_CONTROL=false ``` -These reduce what admins can access through Open WebUI. Direct database, host, backup, and application-secret access should be limited to operators inside your approved trust boundary. +These hide other users' chats and exports from admins in the interface. They do not keep an admin away from the data; see [Admin Users](#admin-users). ### Use SSO and Restrict Accounts @@ -124,7 +124,7 @@ Regular users can read their own chats and chats explicitly shared with them. Ac ### Admin Users -Admins have broad control by design. `ENABLE_ADMIN_CHAT_ACCESS=false` and `ENABLE_ADMIN_EXPORT=false` prevent casual access through Open WebUI product surfaces. Infrastructure-level access should be handled through operator trust, access review, and separation of duties. +Admins control the instance, so treat every admin as able to read every chat. `ENABLE_ADMIN_CHAT_ACCESS=false` and `ENABLE_ADMIN_EXPORT=false` only hide other users' chats and exports in the interface. An admin can still reach the data in other ways, for example by installing a function or tool that runs code on the server, and through internal chats such as sub-agent chats, which stay readable by id. Limit the admin role, and database, host and backup access, to people you trust with the data. ### Database, Host, and Backup Operators