# 企业知识库的权限，应该在什么时候检查？ 把文档授权落实到检索和返回过程，避免只在界面上隐藏敏感内容。 要点：权限需要在检索与返回资料时实际执行，并随人员、部门和文档状态变化更新。页面上隐藏某个文件、在提示中要求模型保密，都不能替代系统对当前用户访问范围的校验。 ![在资料室入口使用门禁卡（AI概念配图）](/images/guides/covers/knowledge-permissions-v2.png) ## 资料权限与应用权限分别确认 员工可以打开问答应用，不代表他有权查看库内所有资料。先明确公开材料、部门资料和项目资料各自面向谁，再决定哪些来源能进入当前应用。 文档的下载、引用摘要和全文读取也可能有不同要求。即使不展示原文件，答案中透露的内容仍应属于用户可访问的范围。敏感资料不应因为被改写成摘要就自动变为公开信息。 ## 在系统执行过程中校验 向检索服务传递可验证的用户身份与访问条件，并在返回内容时再次核对适用范围。文档元数据用于描述权限时，其来源与更新机制也需要受控。 权限变化应考虑已有索引、缓存和会话历史。员工调岗或离职后，仅移除界面按钮可能仍留下其他读取路径；设计时要明确失效方式，并用对应身份测试。 ## 按不同身份做边界验证 选取一组公开与受限文档，用普通员工、部门负责人和无权限用户分别提问。检查答案、引用片段、下载地址及错误提示，确认没有通过旁路返回内容。 所引 MCP 资源规范建议对敏感资源实施访问控制，并在操作前检查权限；企业仍需验证自身实现是否做到。采用某种协议或知识库产品不等于企业权限已经配置正确。具体资料能否接入，应由企业授权和实际系统能力共同确定。 ## 沿着查询链检查实际使用的身份 登录用户、应用服务账号和资料系统身份可能不同。若后台用高权限账号取得所有内容，却只在前端隐藏某些按钮，普通员工仍可能通过问答拿到受限信息。应明确每次检索依据谁的权限，以及资料访问条件怎样传到检索环节。 企业可以先按岗位和资料类别列出可读范围，再验证正向和反向情况：被授权的人能取得需要的资料，未被授权的人无法取得受限片段。不能只测试页面入口，还要检查回答引用、下载地址、缓存和日志中的内容。 | 检查位置 | 需要验证的边界 | | --- | --- | | 资料进入索引 | 访问范围随资料一起保存 | | 检索候选 | 仅返回当前身份可读内容 | | 答案与引用 | 引用可访问且不泄露受限片段 | | 日志与缓存 | 访问控制与保留范围相符 | ## 权限撤销和岗位变动也属于验收场景 权限测试不要止于首次开通。模拟员工换岗、共享撤销或文档移入受限空间，检查后续查询和旧链接的行为。已经生成的回答、缓存和导出文件可能有不同生命周期，必须按企业的资料管理要求分别处理。 当系统无法及时同步权限变化时，应限制该类资料的使用范围或先补齐同步机制。权限不能靠回答中的提醒补救，也不能把“模型不会主动泄露”作为技术控制依据。 ## 同一问题换三个身份测试 用普通员工、资料负责人和已撤权人员分别查询同一组文档，检查候选、摘要、引用、缓存与历史入口。授权撤回后应验证实际效果，不能只检查界面是否隐藏文件。 ## 参考来源 - [MCP 规范｜Resources](https://modelcontextprotocol.io/specification/2025-11-25/server/resources)：所引规范版本的资源与访问控制要求 - [秩启｜企业资料准备](/workspace)：企业资料、角色与待核事项整理；保存草案不等于形成正式业务规则 ## 权限贯穿知识问答 - 确认身份：谁在提出这个问题 - 限制检索：只搜索获准资料 - 检查返回：摘要、原文和缓存一致 ![权限贯穿知识问答](/images/guides/diagrams/knowledge-permissions.svg) ## 继续阅读 - [企业引入 AI 前，哪些准备比选工具更重要？](/guides/ai-readiness) - [MCP 能给企业 AI 带来什么？连接能力与业务权限分开看](/guides/mcp-business-tools) - [企业知识库如何更新，才能避免新旧答案混用？](/guides/knowledge-versioning) 明确授权、处理位置与双方责任；部署、接口、定制及代运维另列技术实施。 下一步：[核对数据与合作边界](/data-boundary) 原文：/guides/knowledge-permissions 内容版本：guide:knowledge-permissions:v1 [结合企业情况咨询](/intake?source=%2Fguides%2Fknowledge-permissions&articleId=guide%3Aknowledge-permissions&versionId=guide%3Aknowledge-permissions%3Av1)