RAG访问控制：AI应用中强制执行文档权限的3种方法

RAG（检索增强生成）正在成为企业AI助手的标准架构，但它也带来了一个容易被忽视却致命的问题：权限越界。当用户向AI助手提问时，检索层可能召回了该用户本无权访问的文档——合同、财报、人事记录——然后模型将这些内容"顺理成章"地生成在回答里。RAG的检索能力越强，这种泄密风险就越大。

据行业技术分析，目前主流的RAG访问控制方案可归为三种路线：代理令牌（On-behalf-of tokens）、实时ACL重查（Live ACL re-checks） 与 父级细粒度授权（Parent-level fine-grained authorization）。它们并非互相替代，而是适用于不同的系统边界和信任模型。

一、为什么RAG的权限问题比传统搜索更棘手

传统搜索的权限控制发生在"返回结果"这一刻，用户看到的就是被过滤后的链接列表。但RAG多了一层：检索到的内容会进入大模型的上下文窗口，模型可能对其进行总结、推断、改写，最终以自然语言输出。即使用户没有直接看到原始文档，模型也可能泄露其中的关键信息。

更麻烦的是，向量数据库中的embedding天然是"内容聚合"的。一份权限受限的文档被切分成多个chunk后，用户可能通过语义相似的查询命中其中某个片段。权限过滤必须发生在检索阶段，而不是生成之后——事后再审查输出，已经太晚了。

这也是为什么三种方案的核心差异在于：在哪个环节验证权限，以及验证的粒度有多细。

向量数据库与embedding：向量数据库是一种专门存储和检索高维向量的数据库，常见产品包括Pinecone、Weaviate、Milvus等。在RAG中，文档首先被切分成若干chunk（片段），再由embedding模型将每个chunk转换为一个高维向量（即embedding）。这个向量在数学上编码了该片段的语义信息，使得系统可以通过计算向量之间的相似度（如余弦相似度）来找到与用户查询语义最接近的片段。

值得注意的是，embedding本身是原始文本的语义压缩，它并不天然携带任何权限标签。因此，如果不在检索时对向量查询附加过滤条件，向量数据库会一视同仁地召回所有语义相关的片段，无论用户是否有权查看。这正是RAG权限风险的技术根源，也是为什么权限过滤必须嵌入到检索环节，而不能依赖事后的输出审查。

二、方法一：代理令牌（On-behalf-of tokens）

Databricks推行的代理令牌模式，核心思想是让检索以用户身份发起请求，而不是以一个高权限的服务账号。当用户向AI助手提问时，系统将用户的身份凭证传递到下游数据源，由数据源自身判断该用户能读取哪些文档。

这种方案的优势在于权限逻辑不必在RAG层重复实现。数据平台（如Unity Catalog）已经维护了完整的ACL，代理令牌直接复用这套权威判定。对于已经把数据治理集中在某个平台的组织来说，这是改动最小、语义最一致的路径。

代价是它对身份体系的打通要求较高。如果检索链路中涉及多个异构数据源，每个源都要支持令牌传递，工程复杂度会迅速上升。

OAuth 2.0与令牌传递：代理令牌模式在工程上通常依赖OAuth 2.0的令牌交换（Token Exchange）或On-Behalf-Of（OBO）授权流。OAuth 2.0是业界标准的授权框架，原本用于让第三方应用在用户授权下访问资源，而不必暴露用户密码。OBO流程在此基础上更进一步：中间服务（如RAG检索层）收到用户的访问令牌后，将这个令牌交换为一个“以该用户身份”访问下游数据源的新令牌。

这样，下游数据源（如Unity Catalog、Snowflake）收到的请求看起来就像是用户本人发起的，从而能利用数据源已有的ACL进行精确判定。这种机制的好处是权限验证的“单一事实来源”仍然在数据平台侧，RAG层无需维护一份可能过时或不一致的权限副本。但代价是链路中每个环节都必须支持令牌的透传与交换，对异构系统的集成能力要求较高。

三、方法二：实时ACL重查（Live ACL re-checks）

AWS所倡导的思路是：在每次检索返回结果后，即时回查权限系统，过滤掉用户无权访问的文档。相比在索引阶段做静态权限标注，实时重查能反映权限的动态变化——员工转岗、项目结束、授权撤销，都会立刻生效。

这类方案的关键在于"实时"二字。权限不是写入时的快照，而是查询时的状态。对于权限频繁变动、或合规要求严格的场景（金融、医疗、法务），实时重查能避免"权限已撤销但AI仍能读到"的尴尬。

其代价是延迟。每次检索都要额外调用权限服务，在高并发下可能成为瓶颈。工程上通常需要权限缓存与失效策略来平衡一致性和性能。

ACL与权限缓存：ACL（Access Control List，访问控制列表）是一种经典的权限模型，它为每个资源维护一个列表，记录哪些用户或角色可以对该资源执行哪些操作（读、写、执行等）。在传统系统中，ACL通常存储在关系型数据库或目录服务中，查询本身有一定开销。

实时ACL重查要求每次检索后都去查询权限系统，这在高并发场景下会带来显著的延迟和负载。为了平衡性能与一致性，工程上常引入权限缓存：将用户最近的权限判定结果缓存在内存或Redis中，并设置较短的TTL（生存时间）。当权限发生变更时，通过事件通知或主动失效机制让缓存快速过期，从而在“撤销即刻生效”和“避免每次请求都打穿权限服务”之间取得折中。理解这一点，有助于评估实时重查方案在实际系统中的可行性与调优空间。

四、方法三：父级细粒度授权（Parent-level fine-grained authorization）

第三种方案关注的是文档层级结构中的权限继承。企业文档往往不是孤立文件，而是存在于文件夹、项目空间、知识库等容器中。父级细粒度授权在容器层施加规则，子文档自动继承，避免对每份文档单独配置权限。

这种方法在知识管理场景中尤为实用。当一份文档在多个层级被引用时，权限判定沿层级向上追溯，找到最近的授权节点。它降低了权限维护的成本，但也要求系统的文档模型具备清晰的父子关系——扁平化的向量存储往往不满足这个前提。

五、三种方法如何选型

多源分析给出的共识是：三种方案不存在普遍最优，选型取决于你的信任边界在哪里。

• 如果数据治理已集中在一个平台（如Databricks、Snowflake），代理令牌最自然，复用既有ACL，一致性最好。
• 如果权限变动频繁、合规压力大，实时ACL重查更能满足"撤销即刻生效"的要求。
• 如果文档天然具有容器化的层级结构，父级细粒度授权能大幅降低配置复杂度。

实践中，不少团队会组合使用：用父级授权做粗粒度兜底，用实时重查处理动态变更，用代理令牌打通身份链路。关键在于权限判定必须发生在检索阶段，而不是交给模型去"自觉遵守"。

一个常被忽略的点是：即便检索层过滤正确，也应对模型的输出做二次校验。因为模型可能通过上下文推断出被过滤文档的存在或内容轮廓——这在多轮对话中尤其危险。RAG的安全边界，最终是一整套从身份、检索到生成的纵深防御体系。