文章摘要企业RAG最严重的故障不是答案不准确，而是用户能够通过自然语言检索到其他租户、其他部门或更高密级的文档。常见根因包括租户ID来自请求参数、过滤只在生成后执行、Top K先召回再删权限、文档Metadata缺失、缓存Key不含租户和权限、重排器接触无权限内容等。本文给出从身份、入库、检索、缓存、重排、生成和审计七层构建权限闭环的完整方案。一、权限泄露通常是怎么发生的一个典型错误链路：用户登录租户A → 提问“公司今年收入是多少” → 向量库在全量文档中召回 → Top5中包含租户B财务报告 → 应用层只检查最终答案 → 模型引用租户B数据或者系统在应用层删除无权限结果：全库Top5 → 删除4条无权限文档 → 剩1条或0条这不仅会降低召回质量，更重要的是：无权限文档已经进入检索结果、日志、Trace、重排器或大模型上下文。权限治理必须从候选集合产生之前开始。二、第一原则：租户ID不能来自用户自由输入错误接口：{"question":"查询经营数据","tenantId":"T002"}用户可以把自己的T001改为T002。正确链路：Access Token → 服务端验证签名 → 解析user_id → 权限服务查询tenant_id和角色 → 构造检索过滤器Controller示例：@PostMapping("/ask")publicAnswerResponseask(@AuthenticationPrincipalLoginUseruser,@RequestBodyAskRequestrequest){RetrievalPrincipalprincipal=permissionService.resolve(user.id());returnragService.answer(principal,request.question());}用户请求中可以有业务筛选，但不能覆盖服务端解析出的身份范围。三、权限模型不要只设计一个tenant_id企业RAG通常存在多层权限：租户 组织 部门 项目 角色 文档密级 用户白名单 有效期建议定义统一权限主体：publicrecordRetrievalPrincipal(StringuserId