企业 AI 接入知识后，怎样验收权限隔离和撤权同步？

把资料切分、生成索引或接入 Agent 后，原有权限不会因为“已经登录”就自动贯穿所有路径。验收要用真实角色及受控测试资料，分别检查检索结果、交给模型的内容、答案、引用下载、会话、缓存和工具动作。调岗或离职后，还要量出授权变更在各层生效的过程；撤权未确认完成时，按风险限制相关访问。

这篇文章面向已经确定资料接入范围、正在核对角色隔离的团队。目标是形成权限矩阵、拒绝用例和撤权证据，不讨论组织应该先投入哪个 AI 场景，也不把某个云产品的功能视作所有项目的现成能力。

先分清用户身份、资料范围和允许动作

从原业务权限出发，按对象和动作列矩阵。某岗位可读产品说明，不等于可读报价底价；可查看自己的客户，也不等于可检索其他团队客户；能读资料，更不等于能发送、修改或删除。用户、部门、租户和服务账号的身份应有明确来源，不能相信聊天中自称的角色。

如果同一文档包含不同可见范围的内容，先确定能否按片段表达并可靠执行权限；不能时采用更保守的整体范围或重新整理。资料被切分后，来源标识、权限与撤回关系要能关联到各片段。只在页面上隐藏文件名，无法说明后台没有读取受限内容。

权限检查要跟着内容走到答案和工具

Microsoft 的 AI 应用设计文档要求身份上下文传到知识与工具层，并将用户、租户和策略等纳入缓存设计。它是 Azure 架构参考；采用其他技术栈仍需验证自己的完整路径，不能凭托管服务名称推定安全。参阅：AI 应用分层、身份传递与缓存设计。

让拒绝用例与成功查询一起验收

使用经过允许、没有真实敏感内容的测试资料，设置容易分辨的标记，检查不同角色是否能取得不该看到的内容。成功拒绝只说明当前用例通过；它不是无限制攻击下零泄露的证明。不要为验收把真实客户机密复制到更宽的测试环境。

• 同一问题分别由有权用户、无权用户和另一个租户提出；核对检索材料、答案和引用，而不只看界面提示。
• 无权用户直接请求受限记录标识、引用地址或下载入口；结果不能绕过正常查询的权限。
• 有权用户先产生缓存答案，无权用户再问相同或相近问题；确认不会复用其无权内容。
• 修改请求里的用户、角色或租户字段，并通过工具路径请求同一对象；身份不能只由可伪造输入决定。
• 权限信息缺失、身份无法确认或策略服务失败时，观察是否按约定停止受限读取和动作，而非默许扩大。

调岗或离职后，测量的是撤权链路，不是一张后台截图

授权变更可能涉及身份系统、组成员、源资料、索引权限、会话、缓存和排队任务。先约定哪些变化由什么机制传播，无法确认传播完成时如何限制访问，再用同一受控测试身份进行演练。不要给所有技术栈承诺一个固定生效时间。

Azure AI Search 文档明确说明，查询依赖已同步到索引的权限元数据；源系统权限变化需要按具体机制同步后才会反映，部分身份与权限功能仍为预览。这里只用它说明同步需要单独核对，不推荐将预览能力直接用于所有生产项目。参阅：文档级权限与权限同步说明。

还应处理已经排队的动作：提交时有权，不代表稍后执行时仍有权。撤权后继续执行的任务，应按明确策略重新检查、取消或转人工。人工已经下载的资料、被复制到其他系统的内容也不能假定随索引更新自动收回，应分别纳入企业的管理与处置范围。

验收记录写出“谁、看什么、经过哪条路”

一条可复核记录应包含：测试角色与范围、对象和动作、权限策略版本、输入、预期允许或拒绝、实际经过的路径与结果、必要日志标识、发现的问题和关闭证据。日志不应包含口令或完整访问令牌；敏感内容按排障所需最小范围保存并限制访问。

验收结论要说明已覆盖哪些身份、数据域和路径，以及未覆盖项如何限制。发现越权后，不只是调整提示词：应定位身份、检索、缓存、下载或工具哪一层没有执行规则，修复后重做相关拒绝用例。扩展新角色、新资料源或新工具时，也要重新检查。

如果正在接入业务系统，可继续核对CRM、ERP 与旧系统的接口和授权；审批与外发动作还需各自验收。项目具体的身份链路、数据范围和撤权演练，可按企业 Agent 与 AI 项目落地范围落实，不能由“已有知识库”推定已经完成。