面向 SharePoint、Confluence 和 Google Drive 的 RAG：权限优先架构

企业级 RAG 真正的难题是权限：助手绝不能把文档呈现给无权查看它的用户。Embedding 本身不会携带或执行源系统授权。请在生成之前执行访问控制：在每个 chunk 上记录源系统原生的访问上下文，或维护权威查询，并在结果进入模型前逐一授权。不要把直接用户、组、域、链接、继承和保护机制简化为仅基于组或 deny 优先的通用规则。

这是我们 RAG 生产就绪清单的实现配套篇，那篇文章把按用户权限点名为最难的安全问题。本文讲的是你究竟该如何解决它。各厂商专有功能和 preview 功能更新很快；在动手构建之前，请重新核对所链接的文档。

为什么权限是最难的部分

一句话概括失败模式：模型基于一份提问用户从未获准查看的文档，给出了一段流畅的回答，因为检索是按语义相似度而非按授权来匹配的。一旦文档被切成 chunk 并 embed 进共享索引，源系统的所有者、访问级别和敏感度标签就不会随向量一同传递，除非你刻意带上它们。向量存储根本没有"是谁在提问"这一概念。

Microsoft 文档说明，Microsoft 365 Copilot 只使用已登录用户有权访问的数据，并遵守 SharePoint 控制和敏感度标签加密。它仍可能让原本过度共享的内容更容易被发现。Restricted Content Discovery 是范围有限的临时 SharePoint 控制，Data Access Governance 则帮助分析权限；两者都不能替代正确的源权限。(1, 2)

告诉模型不要泄露某份文档并不构成访问控制。OWASP 当前把 prompt injection 列为 LLM01，NIST 也记录了通过检索内容进入系统的间接 injection。可信的应用或数据层逻辑必须在内容进入模型之前完成授权。(3)

原则：在检索层强制执行

向量存储一开始就绝不能返回未授权的文档，模型也绝不能处理它。做到这一点的方法是：在建索引时给每个 chunk 打上规范化、带版本的 ACL 元数据，并在检索时把权限过滤器纳入查询。在检索之后、应用层或 prompt 中过滤会以两种方式失败：它取回文档只为丢弃，白白浪费上下文窗口；而一旦应用逻辑有 bug 或被某次 injection 绕过，文档照样会流过去。后置过滤还会悄悄破坏召回率，因为把未授权的 chunk 从 top-k 集合中剔除后，若授权结果恰好落在 k 之外，模型就可能一无所获。请在搜索处做前置过滤，或者过取若干倍于 k 的结果再过滤。

各数据源的权限模型

每个数据源都有自己的 principal、继承、共享链接和保护机制。请使用权限与仓库范围都最小化的专用 connector 身份。可以为检索效率规范化字段，但必须保留足够的源系统事实，以重现有效授权。

在 Microsoft Graph 中应使用 grantedToV2 与 grantedToIdentitiesV2，旧字段已弃用。请选择满足 connector 所需的最小委托或应用权限；可行时优先使用资源范围的 Selected 权限，而不是 tenant 级读取。(4)

经得起考验的实现模式

• 存储稳定的源系统原生 principal。组可降低基数，但直接用户、域或 anyone 链接、继承限制与保护状态也可能决定访问。
• 把每次查询绑定到已登录用户。使用不可变的 subject 与 tenant ID，并解析有效权限或查询源系统。Microsoft On-Behalf-Of 流传递用户委托权限，而不是 application role；Google 和 Atlassian 需要各自的委托设计。(8)
• 让检索授权成为强制步骤。对加法型规则使用集合过滤，并对祖先限制、limited access、链接和加密显式检查。这些产品之间不存在安全的通用 deny 优先规则。
• 处理 Entra 的 groups-overage。Microsoft 对 JWT 组 claim 的上限是 200，对 SAML 是 150。超过上限时 token 会省略列表并给出 overage 指示；必须在授权前取得完整成员关系。(7)
• Postgres RLS 可在靠近 pgvector 数据的位置执行谓词，但并非无法绕过。Superuser、带 BYPASSRLS 的角色以及通常情况下的表所有者会绕过它。应使用无特权应用角色、经过测试的 policy 和事务本地请求身份。(9)

有一处真实的分歧值得点明。一派（包括 AWS）主张，仅靠查询时的元数据过滤还不够，你应当在检索时对照源系统重新核验授权，因为同步来的元数据会变陈旧。另一派（包括微软的参考模式）则把 ACL 同步进索引，并在查询时用用户的 token 强制执行，以追求吞吐量。这是一个真实的权衡：新鲜度对延迟。请按数据的敏感程度来抉择。

没人为之预留预算的新鲜度问题

物化权限不会自动把源端撤权反映到索引。Change feed 是信号，不代表所有后代的有效访问都已重新计算。Google 文档指出，用户 change log 中的 ACL 变化仅面向所有者、列在 ACL 上的服务账户或直接受影响用户；shared drive 应使用对应日志。请结合增量事件、定期核对和 fail-closed 新鲜度阈值。(10)

删除是另一半。如果 GDPR 删除义务适用，且派生 chunk、embedding、缓存或日志仍属个人数据，就应在遵守法定理由与例外的前提下删除或匿名化。Embedding 并非一概属于个人数据。一项已发表攻击在针对两个模型的特定 white-box 设置中，精确恢复了 92% 的 32-token 输入。这证明风险真实存在，但不是通用恢复率。(11, 12)

GDPR 与数据驻留

GDPR 的数据最小化与存储限制支持限定索引范围并缩短派生数据保留期。检索审计日志有助于问责和事故调查，但日志本身也可能含个人数据，必须最小化、保护并到期删除。若模型提供商是处理者，第 28 条要求适当合同；第五章规范第三国传输。仅使用欧盟推理端点不能证明所有处理与存储都留在欧盟，还应核实数据流、支持访问、存储和分处理者。参见2026 年 AI 应用的欧盟数据驻留。(11)

参考架构，以及反模式

端到端：用一个能读取全部内容和 ACL 的身份摄取每个数据源；逐条目提取有效 ACL（尊重被打断的继承、遍历 Confluence 的祖先、读取 Drive 的继承）；切分、embed，并把规范化、带版本的 ACL 作为可过滤元数据附加到每一个 chunk 上；用最终用户身份加一个强制权限过滤器进行检索；仅从授权 chunk 生成；记录每一个决策；并基于源端变更 feed 运行一个新鲜度循环，对继承变更做显式重新同步，并级联删除到 chunk 和 embedding。

反模式包括：共享索引没有强制授权；只在 prompt 中过滤；以广泛授权的服务账户查询；只保存组而丢弃直接用户或链接；把所有产品简化为一条 deny 或 grant 规则；把 Confluence 直接 restriction 当作有效访问；假定 Drive 只会扩大权限；忽略 SharePoint 标签加密；无限期接受陈旧授权；以及无合法依据保留个人数据派生物。

"模型不是你的访问控制，prompt 也不是你的安全边界。如果某个用户无权读取一份文档，向量存储就绝不能返回它。其余的一切，标签、新鲜度、审计日志，都是在服务于这一条规则。"