[GH-ISSUE #17957] feat: Align Model Configuration Logic for External Tools and Internal Features/Capabilities (WebSearch, Code Execution, Image Generation.) #18447

New Issue

GiteaMirror · 2026-04-20T00:40:11-05:00

GiteaMirror commented

2026-04-20 00:40:11 -05:00

Originally created by @Maximilian-Pichler on GitHub (Oct 1, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/17957

Check Existing Issues

I have searched the existing issues and discussions.

Problem Description

Currently, internal features such as WebSearch, Image Generation, and Code Interpreter support a permission and model-based activation logic:

If a user has access to a feature (e.g., WebSearch) but the feature is disabled for a particular model, the user cannot activate or use that feature with this model, even if they have global permission.
For external tools (e.g., custom integrations like MCP server, Confluence access, etc.), the behavior is different:

If a user has permission for an external tool, they can use it with any model, regardless of model configuration. This means external tools are not limited or managed at the model level like internal features.

Desired Solution you'd like

Introduce logic at the model level that enables admins to:

Model-level Enable/Disable: Admins should be able to enable or disable external tools for each model, just as they currently do for internal features.
Default Activation: It should be possible to configure external tools to be enabled or disabled by default per model, but always subject to both the user’s global permission and the model configuration.
Consistent Permission Enforcement: If a user has global permission for an external tool, but the tool is disabled for a specific model, the user should NOT be able to use that tool with this model.
Central Management: Admins should have a clear overview and central control over which internal and external tools are available for which models, including the ability to set defaults.

Benefits:

Brings clarity and consistency to feature/tool governance.
Prevents users from bypassing tool limitations imposed by model configurations.
Supports compliance and security requirements for sensitive or powerful integrations.
Simplifies user expectations: “If it’s not enabled for the model, it’s not available, even if I have access.”

Implementation Suggestions:

Extend the model configuration UI and backend logic to support external tool assignment and defaults, similar to internal features.
Update the tool availability logic to require: (user has permission) AND (tool is enabled for the chosen model).
Optional / For Backwards Compatibility:
- Implement a general tools_allowed attribute/option for models.
- If this is set, the system behaves as it does today (all tools allowed based on user permission).
- If absent, only tools that are checked are allowed.

Examples:

User X has permission for Tool A (external), WebSearch, and File Upload.
Model “Standard” allows WebSearch and Tool A, but disables File Upload.
Model “Internal Only” allows File Upload but not Tool A or WebSearch.
User X can only use Tool A with “Standard”, not with “Internal Only”, regardless of global permission.

Alternatives Considered

As an alternative, we have considered implementing this functionality via custom pipelines that could enforce the described logic. However, integrating these rules natively at the model configuration level would lead to a more user-friendly, maintainable, and transparent solution, reducing the complexity and potential for configuration errors.

Additional Context

No response

Originally created by @Maximilian-Pichler on GitHub (Oct 1, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/17957 ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description Currently, internal features such as WebSearch, Image Generation, and Code Interpreter support a permission and model-based activation logic: If a user has access to a feature (e.g., WebSearch) but the feature is disabled for a particular model, the user cannot activate or use that feature with this model, even if they have global permission. For external tools (e.g., custom integrations like MCP server, Confluence access, etc.), the behavior is different: If a user has permission for an external tool, they can use it with any model, regardless of model configuration. This means external tools are not limited or managed at the model level like internal features. ### Desired Solution you'd like **Introduce logic at the model level that enables admins to:** - Model-level Enable/Disable: Admins should be able to enable or disable external tools for each model, just as they currently do for internal features. - Default Activation: It should be possible to configure external tools to be enabled or disabled by default per model, but always subject to both the user’s global permission and the model configuration. - Consistent Permission Enforcement: If a user has global permission for an external tool, but the tool is disabled for a specific model, the user should NOT be able to use that tool with this model. - Central Management: Admins should have a clear overview and central control over which internal and external tools are available for which models, including the ability to set defaults. **Benefits**: - Brings clarity and consistency to feature/tool governance. - Prevents users from bypassing tool limitations imposed by model configurations. - Supports compliance and security requirements for sensitive or powerful integrations. - Simplifies user expectations: “If it’s not enabled for the model, it’s not available, even if I have access.” **Implementation Suggestions:** - Extend the model configuration UI and backend logic to support external tool assignment and defaults, similar to internal features. - Update the tool availability logic to require: (user has permission) AND (tool is enabled for the chosen model). - Optional / For Backwards Compatibility: - Implement a general tools_allowed attribute/option for models. - If this is set, the system behaves as it does today (all tools allowed based on user permission). - If absent, only tools that are checked are allowed. **Examples**: - User X has permission for Tool A (external), WebSearch, and File Upload. - Model “Standard” allows WebSearch and Tool A, but disables File Upload. - Model “Internal Only” allows File Upload but not Tool A or WebSearch. - User X can only use Tool A with “Standard”, not with “Internal Only”, regardless of global permission. ### Alternatives Considered As an alternative, we have considered implementing this functionality via custom pipelines that could enforce the described logic. However, integrating these rules natively at the model configuration level would lead to a more user-friendly, maintainable, and transparent solution, reducing the complexity and potential for configuration errors. ### Additional Context _No response_

GiteaMirror closed this issue

2026-04-20 00:40:12 -05:00

GiteaMirror commented

2026-04-20 00:40:13 -05:00

@tjbck commented on GitHub (Oct 2, 2025):

Intended behaviour here. Model config will always supersede user level permissions.

@tjbck commented on GitHub (Oct 2, 2025): Intended behaviour here. Model config will always supersede user level permissions.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#18447