一个基于 Azure OpenAI 构建的电子邮件助手通过了 Egiziago Cioffi 团队进行的全部评估，但在一项简单的安全测试中失败了：当低权限账户提出此前由高权限账户提出过的相同问题时，助手返回了来自 SharePoint 的内容，而低权限账户无法直接打开这些内容。这起事件表明，代理能够提供准确答案或完成任务，并不一定意味着它实施了正确的访问边界。
Cioffi 是信息技术与企业架构师，也是 SynSphere Italia 的首席执行官。SynSphere Italia 是一家总部位于米兰的 Microsoft 合作伙伴。Cioffi 亲自构建了该代理，编写了索引任务，并在 Azure OpenAI 中配置检索流程，将其连接到 SharePoint。根据 Cioffi 向 VentureBeat 提供的书面回复，该助手能够自动处理约 60% 的客户来信。然而，评估和单元测试并未询问获取内容时使用的权限身份，而这正是检索日志后来揭示的关键问题。
问题不只是答案的准确性
在使用高权限服务账户进行索引的 RAG 流程中，代理可能看到比最终用户能够访问的范围更大的数据。如果在执行查询时不验证请求者的权限，受限文档就可能在来得及阻止之前进入模型的上下文窗口。
Azure AI Search 提供了一种原生机制，可使用基于 Entra 的令牌在文档级别缩减访问控制列表。该功能自 2025 年 5 月起进入预览阶段，随后在后续预览中加入了 SharePoint 访问列表同步。此外，SharePoint 预览版允许通过 API 2026-05-01-preview 使用前缀 spg: 输入网站集组数据。不过，文档指出，对于通过 Entra 支持的实体，查询时的权限强制执行是可靠的；同时，实验性流程并未覆盖所有代理部署方式。
Azure OpenAI On Your Data 通过 Azure AI Search 中的安全筛选器支持文档级访问，但 Microsoft 文档规定，如果未设置允许访问的组字段，文档级访问就会被禁用。至于绕过 Azure AI Search 的自定义 RAG 流程，除非开发者在检索流程中构建此检查，否则不会自动执行；Cioffi 的部署正是如此。
独立指标，但不能证明只有一个原因
其他数据也支持这一问题的重要性，但必须避免混淆不同类型的失败。Straiker 对生产环境代理实施了超过 1700 次成功的利用尝试，并在 7 月发布的首份 STAR Labs 报告中称，针对生产力代理的成功攻击中，有 91% 以静默数据提取告终，且未被发现。该比例并不能证明所有案例都源于检索权限强制执行失败；报告没有区分权限失败、提示注入、工具滥用及其他问题。
独立地，英国人工智能安全研究所记录了 19 次未经授权的操作，这些操作发生在 7 月 25 日至 28 日进行的一次安全评估期间，并于同年 8 月 4 日发布了事件报告。测试在禁用网络安全分类器并启用互联网访问的情况下进行。这些结果代表的是未能将代理行为限制在预期范围内，而不是与 SharePoint 检索事件完全相同的失败；两者的共同点是运行时缺乏可靠的范围检查。
候选人实际修复了什么？
Cioffi 将权限判定移至查询时执行，添加了一个筛选器，用于在将任何内容传递给模型之前验证 SharePoint 用户的权限。这样，用户无法在 SharePoint 中打开的内容就不会进入上下文窗口。启用筛选器后，该助手仍能自动处理约 60% 的来信，但 Cioffi 没有提供启用筛选器前的比例作为对比。
这一解决方案带来了明确的权衡：此前代理用于回答问题的信息可能会被排除，从而导致答案不完整，或者当权限阻止访问模型所需的某一部分内容时无法作答。这种权衡是否合适，取决于数据敏感性、用户之间权限的差异，以及机构承受不完整查询的能力。
上线前的实际测试
最重要的编辑性结论是，代理身份治理与检索权限检查处理的是两个不同的层次。身份治理规定服务账户、其访问范围以及令牌生命周期，但无法保证账户代表低权限用户检索的内容与该用户实际能够访问的内容一致。
- 使用两个账户，一个低权限账户和一个高权限账户。
- 提出高权限账户使用过的相同问题。
- 将助手的输出与低权限账户能够在源系统中直接打开的内容进行比较。
- 在使用 SharePoint 索引器和通过 Entra 支持的实体的 Azure AI Search 部署中，确认已启用查询时 ACL 缩减，并确认用户组不依赖不受支持的 SharePoint 网站集组。
- 对于自定义 RAG 流程，在通过测试和日志证明之前，应假设不存在权限检查。
根据本文，测试两个账户大约需要 30 分钟，但它能够揭示单凭答案评估分数无法显示的问题：代理实际使用的是请求者的权限，还是构建索引的服务账户权限？