北京
SynSphere Italia的IT与企业架构师兼CEO Egiziago Cioffi亲手搭建了一个Azure OpenAI邮件助手，用于自动处理约60%的客户来信。索引任务、检索管道、SharePoint连接，每一步都通过了团队跑的所有评估。单元测试全绿，评分干净利落——但没人问那个真正关键的问题。
直到Cioffi用一个低权限账号，去问高权限账号已经问过的同样问题。输出对不上。助手返回了提问者自己在SharePoint里根本打不开的内容。日志显示的真相，和评估分数讲的故事完全不是一回事。
评估通过，权限却漏了
问题出在检索权限上。Cioffi的检索日志记录了这次生产环境的具体故障：助手用的是索引器的权限在回答，而不是提问者的权限。这不是孤例。在许多生产级RAG（检索增强生成）部署中，代理都在用索引账号的权限回答问题，而非请求者本人的权限。
Azure AI Search自2025年5月预览版起，已经通过Entra令牌支持了原生的文档级ACL（访问控制列表）裁剪，SharePoint ACL同步也在后续预览版中跟进。能力是存在的——但它并没有出现在所有需要它的地方。SharePoint ACL预览版现在可以通过2026-05-01-preview API中的spg:前缀摄取站点组元数据，但只有Entra支持的委托方被文档明确标注为查询时可可靠执行。
默认放行的隐患
预览版走的是REST API和预览SDK，并未覆盖所有代理部署路径。Azure OpenAI On Your Data支持通过Azure AI Search安全过滤器做文档级访问控制，但微软自己的文档写明：如果permitted-groups字段未映射，文档级访问即被禁用。这是第一方路径里的一个默认放行（fail-open）设计。
Cioffi的部署走的是自定义管道路径——绕过Azure AI Search，用高权限服务账号做索引，除非开发者自己构建查询时权限校验，否则没有任何运行时检查。他的邮件助手就是在这种配置下跑的生产环境。
攻击成功后的沉默泄露
Straiker的红队对生产环境代理执行了超过1700次成功的漏洞利用尝试，结果发表在7月发布的STAR Labs威胁报告中。数据显示：在生产环境代理中，91%的成功攻击最终以未被检测到的数据静默外泄收场。报告特别指出，整个过程不需要任何恶意软件，也没有横向移动。
这个91%衡量的是漏洞利用成功之后发生了什么，而不是有多少部署在检索时权限执行不到位。但它揭示了一个现实：一旦攻击者突破了第一道防线，后续的数据窃取几乎畅通无阻。
一个过滤器加一个更窄的助手
Cioffi的解决方案没有引入新的身份平台。他加了一个过滤器，把助手的能力范围收窄。检索管道在返回结果前，先校验请求者的Entra身份与文档ACL的匹配关系，不匹配的直接过滤掉。助手本身也被限制在更小的职责范围内——只处理它被授权处理的那部分邮件类型。
这个组合拳堵住了权限越界的口子。没有大动干戈换架构，没有上新的安全产品，就是在现有管道里加了一道闸，同时让助手别管太宽的闲事。对于同样跑在自定义RAG管道上的团队，这两步值得直接抄作业。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
