github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-11 10:34:13 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #24432] feat: MCP Tool Permissions Are Global Per Group Instead of Scoped Per Workspace Model #107295

New Issue
Closed
opened 2026-05-18 06:02:41 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-05-18 06:02:41 -05:00
Owner
Copy Link

Originally created by @impr3ssi0n on GitHub (May 7, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24432

Check Existing Issues

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

Verify Feature Scope

  • I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Problem Description

MCP tool permissions currently appear to be global once access is granted to a user or group in the Integration connection settings.

I added an MCP server through Integrations as a Streamable HTTP connection with OAuth 2.1 authentication and client registration.

In the connection editor, if I do not assign permissions to any group or user, the MCP tool is only available to admins.

However, if I grant access to a specific group, users in that group can enable and use this MCP tool with any model they have access to.

This creates a problem for Workspace-scoped model configurations.

For example:

  1. I create a Workspace model based on gpt-5.
  2. I grant access to this Workspace model only to a specific group.
  3. I attach/select a specific MCP tool for this Workspace model.

I would expect the MCP tool to only be usable:

  • with that specific Workspace model,
  • and only by the allowed group.

Instead, once users have permission to the MCP connection itself, they can use the MCP tool across all accessible models.

This behavior differs from how regular tools behave in Workspace model configurations and makes it difficult to enforce model-specific tool access policies.

Desired Solution you'd like

MCP tools should support permission scoping at the Workspace model level, similar to regular tools.

Expected behavior:

  • an MCP tool can be attached to a specific Workspace model,
  • only users/groups with access to that Workspace model can use the tool,
  • the tool should not automatically become available globally across all models accessible to that group.

This would allow administrators to create isolated model + tool combinations with predictable access control behavior.

Alternatives Considered

No response

Additional Context

No response

Originally created by @impr3ssi0n on GitHub (May 7, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24432 ### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description MCP tool permissions currently appear to be global once access is granted to a user or group in the Integration connection settings. I added an MCP server through Integrations as a Streamable HTTP connection with OAuth 2.1 authentication and client registration. In the connection editor, if I do not assign permissions to any group or user, the MCP tool is only available to admins. However, if I grant access to a specific group, users in that group can enable and use this MCP tool with any model they have access to. This creates a problem for Workspace-scoped model configurations. For example: 1. I create a Workspace model based on `gpt-5`. 2. I grant access to this Workspace model only to a specific group. 3. I attach/select a specific MCP tool for this Workspace model. I would expect the MCP tool to only be usable: * with that specific Workspace model, * and only by the allowed group. Instead, once users have permission to the MCP connection itself, they can use the MCP tool across all accessible models. This behavior differs from how regular tools behave in Workspace model configurations and makes it difficult to enforce model-specific tool access policies. ### Desired Solution you'd like MCP tools should support permission scoping at the Workspace model level, similar to regular tools. Expected behavior: * an MCP tool can be attached to a specific Workspace model, * only users/groups with access to that Workspace model can use the tool, * the tool should not automatically become available globally across all models accessible to that group. This would allow administrators to create isolated model + tool combinations with predictable access control behavior. ### Alternatives Considered _No response_ ### Additional Context _No response_
GiteaMirror commented 2026-05-18 06:02:43 -05:00
Author
Owner
Copy Link

@owui-terminator[bot] commented on GitHub (May 7, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

  1. 🟣 #18392 feat: Model-Specific Tool Restrictions
    This is the closest match: it asks for model-specific tool restrictions so users cannot enable arbitrary tools on a model. Your issue is about MCP tools ignoring workspace-model scoping and effectively becoming global once a group has connection access.
    by hectorc98

  2. 🟢 #23272 feat: Enabling an integration with OAuth 2.1 at the model level initializes auth flow when user starts chat without session
    This issue is about an MCP OAuth-enabled tool attached at the model level and the auth flow when using shared models. It overlaps with your concern that MCP tools behave differently when bound to a workspace model instead of remaining scoped to that model's access.
    by taylorwilsdon

  3. 🟣 #20847 issue: MCP OAuth2.1 initial auth doesn't work when a tool is enabled by default for a model
    This older issue also concerns an MCP tool enabled by default for a model, showing that MCP model-level behavior has had prior edge cases. While the specific symptom is auth failure, it is still relevant because both issues involve MCP tools attached to models rather than enabled globally.
    by Lemmons · bug

  4. 🟢 #24367 issue: Unable to use global tool server while user tool server works properly
    This report shows a related discrepancy between global and user-added tool servers: a globally defined MCP tool server is visible but not actually injected into the model request. It is not the same bug, but it concerns tool-server availability differing by where/how the MCP server is configured.
    by theFra985 · bug

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

<!-- gh-comment-id:4398175362 --> @owui-terminator[bot] commented on GitHub (May 7, 2026): <!-- terminator-bot:related-issues-reply --> 🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟣 [#18392](https://github.com/open-webui/open-webui/issues/18392) **feat: Model-Specific Tool Restrictions** *This is the closest match: it asks for model-specific tool restrictions so users cannot enable arbitrary tools on a model. Your issue is about MCP tools ignoring workspace-model scoping and effectively becoming global once a group has connection access.* *by hectorc98* 2. 🟢 [#23272](https://github.com/open-webui/open-webui/issues/23272) **feat: Enabling an integration with OAuth 2.1 at the model level initializes auth flow when user starts chat without session** *This issue is about an MCP OAuth-enabled tool attached at the model level and the auth flow when using shared models. It overlaps with your concern that MCP tools behave differently when bound to a workspace model instead of remaining scoped to that model's access.* *by taylorwilsdon* 3. 🟣 [#20847](https://github.com/open-webui/open-webui/issues/20847) **issue: MCP OAuth2.1 initial auth doesn't work when a tool is enabled by default for a model** *This older issue also concerns an MCP tool enabled by default for a model, showing that MCP model-level behavior has had prior edge cases. While the specific symptom is auth failure, it is still relevant because both issues involve MCP tools attached to models rather than enabled globally.* *by Lemmons · `bug`* 4. 🟢 [#24367](https://github.com/open-webui/open-webui/issues/24367) **issue: Unable to use global tool server while user tool server works properly** *This report shows a related discrepancy between global and user-added tool servers: a globally defined MCP tool server is visible but not actually injected into the model request. It is not the same bug, but it concerns tool-server availability differing by where/how the MCP server is configured.* *by theFra985 · `bug`* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.
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#107295
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?