Feat/Unexpected behavior/data leakage: Make knowledge retrieval opt-in; no selection should mean no access

快速结论：在启用内置知识库工具（native/builtin knowledge tools）时，模型调用 query_knowledge_files 可以检索“你本人有权访问”的全部工作区知识库，即使界面上没有附加任何知识库。维护者确认这是设计行为（”no selection means the AI has access to everything YOU, the user, has access to”），因此这不是配置错误，而是能力边界与 UI 语义不一致的问题。

适用环境：Open WebUI v0.11.3（Issue 报告者版本）；维护者表示 current 与 dev 分支同样如此。Issue 中未给出操作系统、Python、CUDA、显卡或具体依赖版本信息。涉及功能为内置知识工具 query_knowledge_files 与“+”菜单中的知识库选择器。

最快修复方案：暂无确认的一步修复方案。该 Issue 以 enhancement 关闭，维护者未提供开关或补丁。若要严格控制检索范围，只能采用 Issue 中列出的临时规避手段（见“解决步骤”），并在部署层面限制用户可见的知识库范围。

注意事项：Issue 正文中给出的“加一个默认开启的 Only explicitly attached knowledge 设置”仅是需求建议，并未被确认实现；请勿据此假设存在对应配置项。另外，维护者指出“+”菜单中的知识库选择器属于旧版工具调用（legacy tool calling）体系，在 native tool calling 成为默认后已不推荐使用，因此在该体系下“空选择 = 无访问”的预期不会成立。具体权限与工具可及范围请以你所部署版本的实际行为为准。

问题场景

用户在 Open WebUI v0.11.3 中启用了内置知识工具（built-in knowledge tools），然后在聊天中未附加任何知识库，或使用了“+”菜单的知识库选择器后留空。此时模型仍可主动调用 query_knowledge_files，检索该用户在 workspace 中有权访问的知识库内容。

报告者担心两类后果：一是无关知识库的内容被意外混入回答；二是本应仅供本地/私有模型使用的机密内容，可能随检索结果被发送到外部商用模型提供方——即使用户级别权限本身工作正常。

报告者希望的行为是：未选择知识库时不允许检索；选择了知识库时检索仅限该选择；全量检索必须显式开启（opt-in）。维护者回应称现有行为是“as intended”，并指出内置 native tools 的设计目的正是让模型自行检索信息，无需手动添加知识库。

报错原文

Feat/Unexpected behavior/data leakage: Make knowledge retrieval opt-in; no selection should mean no access

with built-in knowledge tools enabled, a model can call `query_knowledge_files` and search user-accessible workspace knowledge bases even when none are attached.

Incorrect, no selection means the AI has access to everything YOU, the user, has access to.

原因分析

最可能的原因：这是一个有意的功能设计，而非 bug。维护者明确表示，启用内置知识工具后，模型通过 query_knowledge_files 检索的范围是“当前用户可访问的全部知识库”，空选择并不等同于关闭检索。内置 native tools 的存在目的就是让模型具备 agentic 检索能力。

第二个可能原因：UI 语义与后端行为不一致造成误解。聊天界面提供了显式的知识库选择入口，容易让人推断“空选择 = 不访问知识库”；但该选择器属于旧版工具调用体系（legacy），在 native tool calling 成为默认后已不再是控制检索范围的主要机制。当模型上“已附加知识库”时，检索理论上会被收窄到这些知识库，但报告者观察到的场景是不附加任何知识库时仍可全量检索。

需要说明的是：Issue 中并未给出该行为与数据外泄之间的实际复现证据，因此“敏感内容被发送到外部模型”应视为可能风险，而非已确认结论。相关 Issue（如 #32260、#28217）反映的是 knowledge_ids 参数在已附加知识库时被忽略的问题，与本 Issue 的“空选择仍可检索”属于相邻但不同的行为，不能直接当作同一根因。

环境排查

确认 Open WebUI 版本：报告者环境为 v0.11.3，维护者称 current 与 dev 分支行为一致。
确认是否启用了内置/native 知识工具（knowledge tool category），以及是否在使用 native tool calling（默认）还是旧版工具调用。
确认发起对话的用户账号在 workspace 中有权访问哪些知识库——可用知识库范围直接决定模型可检索的上界。
确认模型本身是本地/私有部署还是外部商用 provider，以评估检索内容外发的实际路径。
确认是否在“+”菜单中附加了知识库，以及附加后检索结果是否确实被收窄（Issue 中未给出验证结果，需自行测试）。
Issue 未涉及 Python、CUDA、PyTorch、显卡或具体依赖版本，无需据此排查。

解决步骤

先明确认知：当前版本下这是预期行为，不是配置错误。不要期望通过某个“空选择即无访问”的开关来消除它——issue 中不存在该开关。
临时规避（可优先尝试）：在“+”菜单中仅为该对话添加一个几乎为空的知识库；这样模型即使检索，也只会命中该 KB 的内容。报告者本人指出此方法“error prone”，需靠流程纪律保证每次都不遗漏。
在部署层面收窄暴露面：让使用外部模型的用户账号只能访问到允许外发的知识库，把机密知识库只分配给使用本地/私有模型的账号。这是权限侧的隔离，而非检索模式开关。
若某类场景完全不能接受自动检索，可选择禁用知识库搜索工具——但维护者和报告者均认为此做法粒度过粗，会一起废掉所需的知识库能力。
若需要精细控制，可关注并跟进相关请求与问题：#28163（用户级关闭 query_knowledge_files/search_knowledge_bases）、#32260 与 #28217（knowledge_ids 被忽略）、#28553（tool calling 为 default 时 RAG 行为异常），但不要把它们的结论直接套用到本 Issue 的“空选择”场景。
如果“空选择仍全量检索”这一行为会在你所在环境造成不可接受的数据外发，需要在发布侧提出明确需求或自行评估代码修改，并注意维护者已将其定性为 intended，任何补丁都应与维护者先对齐。

验证方法

用一个只有权访问知识库 A 和 B 的测试账号，启用内置知识工具，在未附加任何知识库的对话中让模型检索某个只有 A 中存在、B 中不存在的标志性字符串：若能命中，说明“空选择仍可全量检索”的行为存在，符合维护者的说明。随后在同一对话附加仅包含 B 的知识库后重复提问：若结果被限制在 B 的范围，说明附加选择收窄范围生效；若仍命中 A 的内容，则属于邻近 Issue（#32260/#28217）所述的 knowledge_ids 被忽略问题，应转到对应 Issue 跟踪。