SynSphere Italia 的 CEO Egiziago Cioffi 自己搭建的 Azure OpenAI 邮件助手通过了团队的全部评测，却在一次双账号复测中暴露越权读取：低权限账号提问，助手返回了它在 SharePoint 里根本打不开的文件。问题不在模型回答质量，而在检索权限——取数用的是服务账号的权限，不是提问者的权限。他在查询路径上加了一个过滤器堵住缺口，助手仍能自动处理约 60% 的入站邮件。
评测的盲区
Cioffi 是意大利米兰微软合作伙伴 SynSphere Italia 的 CEO 兼 IT 企业架构师。他自己写了索引任务、配置了 Azure OpenAI 检索流水线、接上 SharePoint，让邮件助手自动解决约 60% 的入站客户邮件。团队跑了准确性、相关性和任务完成度评测，单元测试也全部通过——但没有任何一项检查「取数时用的是谁的权限」。
他用低权限账号把高权限账号问过的问题重问一遍，输出对不上：助手返回了请求用户在 SharePoint 里自己无法打开的内容。检索日志显示，取数按索引器（服务账号）的权限执行，而不是按请求者的权限执行。
缺口出在默认放行
Azure AI Search 自 2025 年 5 月预览起支持基于 Entra 令牌的原生文档级 ACL 裁剪，SharePoint ACL 同步在后续预览版跟进；2026-05-01-preview API 可用 spg: 前缀摄入站点组元数据。但微软文档明确，只有 Entra 主体在查询时会被可靠执行；Azure OpenAI On Your Data 的文档级访问依赖 permitted-groups 字段映射，字段未映射访问即被禁用——这是第一方路径上的默认放行。
Cioffi 的部署走的是自定义检索流水线，完全绕过 Azure AI Search：索引以高权限服务账号运行，查询时没有任何权限检查，除非开发者自己写。这类缺口能绕过全部评测，一直存活到生产环境。
同类问题不是个案
Straiker 红队在首份 STAR Labs 威胁报告中披露了对生产智能体的 1700 多次成功利用尝试；其研究结论是，对生产力智能体的成功攻击中，91% 以无侦测的静默数据外泄告终——不需要恶意软件，也不需要横向移动，智能体直接把能触达的数据全部返回。英国 AI 安全研究所（UKASI）2026 年 7 月 25-28 日的网络评估记录了 19 起未经授权的智能体行为。两者机制不同，但共同点是运行时缺少作用域检查。
修复：查询路径上的一道过滤器
Cioffi 的修复没有引入新的身份平台。他把授权判断放进检索路径：模型看到内容块之前，先按请求用户的 SharePoint 权限过滤。过滤在查询时执行，不在索引时执行——用户打不开的内容不会进入模型上下文。代价是助手可用的内容变少，部分问题答不上来；过滤器上线后，它仍能自动解决约 60% 的入站邮件。
身份治理与检索权限是两层控制
身份治理平台管的是另一层：哪些服务账号存在、能访问什么、token 何时过期。CrowdStrike 以 7.4 亿美元收购 SGNL（2026 年 1 月 8 日宣布、2 月 20 日完成），Palo Alto Networks 以 250 亿美元收购 CyberArk（2025 年 7 月宣布、2026 年 2 月 11 日完成），身份安全已成了两大安全厂商的平台支柱。但身份治理管不到检索权限边界：凭据链每个环节都合法，服务账号干净、知识库索引正确，低权限用户提问时，助手仍可能按完整索引范围作答，全程没有任何环节报警。
Netragard 创始人兼 CEO Adriel Desautels 把这个问题说得很直接：智能体长期运行在单个持宽泛权限的非人身份（NHI）上，评测又很少覆盖提示词、输出、转录、内存和日志这些可被注入内容读取或劫持的位置。评测考的是「答得对不对」，权限边界不在考纲里。
30 分钟双账号自检
上线前问一个问题：你的 AI 检索系统取内容时，用的是谁的权限？
- 走 Azure AI Search + SharePoint 索引器 + Entra 主体的部署：确认查询时 ACL 裁剪已启用，且用户群体不依赖 SharePoint 站点组；
- 走自定义检索流水线的部署：权限检查可能根本不存在，需要自己补。
验证方法：用低权限账号重问高权限账号已问过的问题，把输出与低权限账号在底层系统直接能访问的内容对比。助手返回超出直接访问范围的内容，就说明查询时的检索权限边界没有被执行。这个测试需要两个账号、30 分钟，评测分数给不出这个结果。
结论：AI 助手答得对，不代表取数权限对。上线前跑一次双账号对比，30 分钟就能确认检索权限边界是否真的在生效。