github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-06 10:58:17 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #18392] feat: Model-Specific Tool Restrictions #57249

New Issue
Closed
opened 2026-05-05 20:46:54 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-05-05 20:46:54 -05:00
Owner
Copy Link

Originally created by @hectorc98 on GitHub (Oct 17, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18392

Check Existing Issues

  • I have searched all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.

Problem Description

Currently, the toolIds field in model configuration only sets default tools that are pre-enabled when a user selects a model. However, users can still manually enable/disable any available tool through the Integrations menu during a chat session. This creates a challenge for administrators who want to:

  • Restrict certain tools (including MCP servers) from being used with specific models
  • Prevent users from enabling HTTP-based tools that may pose security or cost concerns
  • Enforce model-specific capabilities based on organizational policies

Current Behavior

  1. Admin configures toolIds in Model Editor (Workspace → Models → Edit)
  2. When user selects the model, tools in toolIds are enabled by default
  3. User can click the Integrations button and toggle ANY available tool on/off
  4. No enforcement mechanism exists to prevent this

Desired Solution you'd like

Add a model-specific tool restriction capability that allows administrators to control which tools can be used with each model, not just which are enabled by default.

Preferred Implementation:
Add a restrict_tools boolean capability to the model configuration (similar to existing vision, file_upload, etc.). When enabled:

  • Only tools specified in the model's toolIds array can be toggled on
  • Other tools are hidden or visually disabled in the Integrations menu
  • Backend validates and rejects requests attempting to use unauthorized tools

UI Changes:

  • Add checkbox in Model Editor → Capabilities section: "Restrict Tools" with description "Only allow tools specified in the Tools section"
  • In chat Integrations menu, filter available tools based on model configuration
  • Show visual indicator (lock icon or grayed out) for restricted models

Backend Enforcement:

  • Validate tool IDs in utils/middleware.py before processing chat requests
  • Return appropriate error message if user attempts unauthorized tools
  • Update model schema to include new capability flag

Backward Compatibility:

  • Default restrict_tools: false maintains current behavior
  • Existing models continue to work without modification

Alternatives Considered

Alternatives Considered

1. Tool-level Access Control Only

  • Use existing access_control on tools to restrict by user/group
  • Limitation: Can't restrict based on which model is being used, only who is using it

2. Remove Tools from Workspace

  • Admin removes problematic tools entirely
  • Limitation: Affects all models globally; can't have tool available for some models but not others

3. Add allowedToolIds or disabledToolIds Array

  • More explicit allow/deny lists in model metadata
  • Limitation: More complex to manage, two fields to maintain, less intuitive UX

4. Capability-level Restrictions Instead of Tool-level

  • Disable tool-calling capability entirely per model via capabilities.tools: false
  • Limitation: All-or-nothing approach, no granular control over specific tools

5. Custom Pipeline/Filter

  • Create a filter function that blocks certain tools based on model
  • Limitation: Requires technical knowledge, not accessible to admins, no UI

Additional Context

Real-World Use Cases:

  1. Security Compliance: Organization wants to prevent web search and HTTP tools from being used with models that process PII/confidential data, while allowing them for general-purpose models

  2. Cost Management: Expensive MCP servers should only be available with premium models, not with standard models

  3. Model Limitations: Some smaller/faster models don't support tool calling well and should have tools disabled entirely

  4. Regulatory Requirements: Healthcare/financial organizations need to enforce which external services can be called based on data classification

User Expectations:
Many admins assume that configuring tools in the Model Editor restricts usage to those tools, similar to how capabilities work. The current behavior where it's only a "default" is surprising and reduces trust in the admin interface.

Similar Features:
Open WebUI already has similar restriction patterns:

  • capabilities.vision: false prevents image uploads for that model
  • capabilities.file_upload: false disables file inputs
  • Tool restriction would follow this same established pattern
Originally created by @hectorc98 on GitHub (Oct 17, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/18392 ### Check Existing Issues - [x] I have searched all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request. ### Problem Description Currently, the `toolIds` field in model configuration only sets **default tools** that are pre-enabled when a user selects a model. However, users can still manually enable/disable any available tool through the Integrations menu during a chat session. This creates a challenge for administrators who want to: - Restrict certain tools (including MCP servers) from being used with specific models - Prevent users from enabling HTTP-based tools that may pose security or cost concerns - Enforce model-specific capabilities based on organizational policies ### Current Behavior 1. Admin configures `toolIds` in Model Editor (Workspace → Models → Edit) 2. When user selects the model, tools in `toolIds` are enabled by default 3. User can click the Integrations button and toggle **ANY** available tool on/off 4. No enforcement mechanism exists to prevent this ### Desired Solution you'd like Add a model-specific tool restriction capability that allows administrators to control which tools can be used with each model, not just which are enabled by default. **Preferred Implementation:** Add a `restrict_tools` boolean capability to the model configuration (similar to existing `vision`, `file_upload`, etc.). When enabled: - Only tools specified in the model's `toolIds` array can be toggled on - Other tools are hidden or visually disabled in the Integrations menu - Backend validates and rejects requests attempting to use unauthorized tools **UI Changes:** - Add checkbox in Model Editor → Capabilities section: "Restrict Tools" with description "Only allow tools specified in the Tools section" - In chat Integrations menu, filter available tools based on model configuration - Show visual indicator (lock icon or grayed out) for restricted models **Backend Enforcement:** - Validate tool IDs in `utils/middleware.py` before processing chat requests - Return appropriate error message if user attempts unauthorized tools - Update model schema to include new capability flag **Backward Compatibility:** - Default `restrict_tools: false` maintains current behavior - Existing models continue to work without modification ### Alternatives Considered ### **Alternatives Considered** **1. Tool-level Access Control Only** - Use existing `access_control` on tools to restrict by user/group - **Limitation:** Can't restrict based on which model is being used, only who is using it **2. Remove Tools from Workspace** - Admin removes problematic tools entirely - **Limitation:** Affects all models globally; can't have tool available for some models but not others **3. Add `allowedToolIds` or `disabledToolIds` Array** - More explicit allow/deny lists in model metadata - **Limitation:** More complex to manage, two fields to maintain, less intuitive UX **4. Capability-level Restrictions Instead of Tool-level** - Disable tool-calling capability entirely per model via `capabilities.tools: false` - **Limitation:** All-or-nothing approach, no granular control over specific tools **5. Custom Pipeline/Filter** - Create a filter function that blocks certain tools based on model - **Limitation:** Requires technical knowledge, not accessible to admins, no UI ### Additional Context **Real-World Use Cases:** 1. **Security Compliance:** Organization wants to prevent web search and HTTP tools from being used with models that process PII/confidential data, while allowing them for general-purpose models 2. **Cost Management:** Expensive MCP servers should only be available with premium models, not with standard models 3. **Model Limitations:** Some smaller/faster models don't support tool calling well and should have tools disabled entirely 4. **Regulatory Requirements:** Healthcare/financial organizations need to enforce which external services can be called based on data classification **User Expectations:** Many admins assume that configuring tools in the Model Editor restricts usage to those tools, similar to how capabilities work. The current behavior where it's only a "default" is surprising and reduces trust in the admin interface. **Similar Features:** Open WebUI already has similar restriction patterns: - `capabilities.vision: false` prevents image uploads for that model - `capabilities.file_upload: false` disables file inputs - Tool restriction would follow this same established pattern
GiteaMirror commented 2026-05-05 20:46:55 -05:00
Author
Owner
Copy Link

@silentoplayz commented on GitHub (Oct 17, 2025):

users can still manually enable/disable any available tool through the Integrations menu during a chat session.

Not sure if any of this info is helpful, but this is mostly based on my testing and to hopefully be informative.

If you toggle off Allow Chat Valves as a Default Permission in Open WebUI from your superadmin account, users OUTSIDE of any usergroup will no longer see the tools/valves controls for tools in the Integrations menu or Valves within the Chat Controls sidebar.
Image

You and other admins of your Open WebUI instance are unaffected by Default Permissions, so you and other admins will still see the tools/valves controls for tools in the Integrations menu or Valves within the Chat Controls sidebar.

If you toggle off Allow Chat Valves for both the Default Permission and a user-group permission with the admin in aforementioned user-group, the admin will still have access to the tools/valves controls for tools in the Integrations menu and Valves within the Chat Controls sidebar, also unaffected by the toggled state of the Allow Chat Valves permission in the user-group, as the Admin role bypasses this.

Proof:

Default Permissions:

Image

2 Admin accounts - G30 is my superadmin account, Ollama was promoted to Admin for the sake of this example

Image

A new user-group was created for both admins with the Allow Chat Valves toggled off

Image Image Image

The Ollama Admin account still has full access to Chat Valves in this scenario

Image Image

If I change the Ollama user from an Admin back to a User role in the user-group I have it in... I can see tools with Valves access in the Integrations menu, but not the Valves collapsible section in the Chat Controls sidebar.

Image

Lastly, if I remove the Ollama user from the user-group I had it in, then I can no longer see the tools/valves controls for tools in the Integrations menu or Valves within the Chat Controls sidebar, as expected, because the Allow Chat Valves permission has been toggled off this entire time (This loops us back to where we started from).

Image

TL;DR

If “Allow Chat Valves” is off in the global Default Permissions, non-group users simply never see the Valves panel or the per-tool toggles in Integrations; flip the same switch for a user-group and every member of that group inherits the same blindness, but anyone with the Admin role is immune—admins always keep full Valve access no matter how the permission is set at either the default or group level, so the only way an admin can “lose” the controls is by being demoted to a regular user and, at the same time, falling under a group (or the global default) that has the right disabled.

<!-- gh-comment-id:3415960407 --> @silentoplayz commented on GitHub (Oct 17, 2025): > users can still manually enable/disable any available tool through the Integrations menu during a chat session. Not sure if any of this info is helpful, but this is mostly based on my testing and to hopefully be informative. If you toggle off `Allow Chat Valves` as a Default Permission in Open WebUI from your superadmin account, users **OUTSIDE** of any usergroup will no longer see the tools/valves controls for tools in the `Integrations` menu or `Valves` within the `Chat Controls` sidebar. <img width="2306" height="1277" alt="Image" src="https://github.com/user-attachments/assets/474f4d96-1c38-41e4-927a-f7000df07fe6" /> You and other admins of your Open WebUI instance are unaffected by `Default Permissions`, so you and other admins will still see the tools/valves controls for tools in the `Integrations` menu or `Valves` within the `Chat Controls` sidebar. If you toggle off `Allow Chat Valves` for both the Default Permission and a user-group permission with the admin in aforementioned user-group, the admin will still have access to the tools/valves controls for tools in the `Integrations` menu and `Valves` within the `Chat Controls` sidebar, also unaffected by the toggled state of the `Allow Chat Valves` permission in the user-group, as the `Admin` role bypasses this. ## Proof: ### Default Permissions: <img width="727" height="514" alt="Image" src="https://github.com/user-attachments/assets/90224f37-b64f-47db-b89b-5904de1307ed" /> ### 2 `Admin` accounts - `G30` is my superadmin account, `Ollama` was promoted to `Admin` for the sake of this example <img width="420" height="192" alt="Image" src="https://github.com/user-attachments/assets/1c0315ba-e5a1-44c2-b3a7-f3f8c4408e46" /> ### A new user-group was created for both admins with the `Allow Chat Valves` toggled off <img width="701" height="506" alt="Image" src="https://github.com/user-attachments/assets/8275b038-a440-4c8c-b371-21fd4bf09310" /> <img width="701" height="506" alt="Image" src="https://github.com/user-attachments/assets/030d95d1-0e7a-4101-8704-13e502463348" /> <img width="701" height="506" alt="Image" src="https://github.com/user-attachments/assets/fdf6f93f-17ce-418b-817f-0c54e77f4cd6" /> ### The `Ollama` Admin account still has full access to Chat Valves in this scenario <img width="2559" height="1267" alt="Image" src="https://github.com/user-attachments/assets/717f2e8b-a86a-422e-92c9-aaab43457171" /> <img width="2559" height="1267" alt="Image" src="https://github.com/user-attachments/assets/6860cb99-2885-425d-b5af-b5660fd560c0" /> ### If I change the `Ollama` user from an `Admin` back to a `User` role in the user-group I have it in... I can see tools with `Valves` access in the `Integrations` menu, but not the `Valves` collapsible section in the Chat Controls sidebar. <img width="2559" height="1267" alt="Image" src="https://github.com/user-attachments/assets/ce0caa39-0438-4112-ba3a-f75e6b0b8f8c" /> ### Lastly, if I remove the `Ollama` user from the user-group I had it in, then I can no longer see the tools/valves controls for tools in the `Integrations` menu or `Valves` within the `Chat Controls` sidebar, as expected, because the `Allow Chat Valves` permission has been toggled off this entire time (This loops us back to where we started from). <img width="2559" height="1267" alt="Image" src="https://github.com/user-attachments/assets/e27cc2fc-1ec0-4173-9ce0-47ac9ce33132" /> # TL;DR **If “Allow Chat Valves” is off in the global Default Permissions, non-group users simply never see the Valves panel or the per-tool toggles in Integrations; flip the same switch for a user-group and every member of that group inherits the same blindness, but anyone with the Admin role is immune—admins always keep full Valve access no matter how the permission is set at either the default or group level, so the only way an admin can “lose” the controls is by being demoted to a regular user and, at the same time, falling under a group (or the global default) that has the right disabled.**
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#57249
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?