多租户 RAG 为什么会串库从检索过滤到审计追踪作者元宝一个安全研发的 AI 安全观察与实践笔记多租户 RAG 最危险的地方是“回答看起来很正常”。用户问的是自己的合同条款模型返回的内容也语气流畅、引用完整只有其中一段来自另一个租户。假设一个 SaaS 平台为不同企业提供合同助手。文档入库时记录了tenant_id但检索接口为了复用缓存只按向量相似度查询拿到结果后再由应用代码尝试过滤。某个异常分支漏掉了过滤条件跨租户内容就可能进入模型上下文。这不是模型幻觉而是数据隔离失效。模型只是把已经越过边界的内容重新组织了一遍。串库的典型路径必须在召回前记录来源最后兜底租户 A 用户提问检索网关向量索引返回相似切片应用层拼接上下文模型回答租户 A 用户租户 B 文档租户与资源过滤引用与审计响应脱敏安全边界应该在“召回前”建立。越晚过滤越可能出现缓存污染、日志泄露、上下文拼接错误和异常响应差异。三个经常被混淆的概念概念说明不能替代什么租户隔离数据属于哪个企业或项目用户对单个资源的权限资源授权当前用户能否访问这份文档租户级索引隔离相似度相关性文档与问题是否语义相关任何权限判断向量相似度只是排序信号。一个跨租户文档越相关越不应该因此被召回。一个容易漏过滤条件的实现defretrieve(query,user,top_k5):filters{tenant_id:user.tenant_id}resultsvector_db.search(query,top_ktop_k)return[itemforiteminresultsifitem.metadata.get(tenant_id)filters[tenant_id]]这段代码的问题不在于“最后过滤”一定错误而在于它默认所有召回内容已经安全地进入应用内存。此时内容可能已经被写入调试日志、缓存或模型请求记录如果top_k较小跨租户文档还可能挤掉本租户真正需要的结果。更稳妥的方式是让向量数据库或检索网关在服务端执行强制过滤defretrieve_authorized(query,auth_context,top_k5):filters{tenant_id:auth_context.tenant_id,resource_acl:{$in:auth_context.groups},status:active,}returnvector_db.search(queryquery,filtersfilters,top_ktop_k,audit_contextauth_context.request_id,)字段名可以不同但执行顺序不能反过来身份和资源权限是硬约束相似度只能在约束范围内排序。缓存往往是隐藏的串库点为了降低延迟系统可能按问题文本缓存检索结果。如果缓存键只有规范化后的 Query那么租户 A 问“违约金怎么计算”租户 B 可能直接命中同一份结果。缓存键至少要绑定租户、用户权限版本、知识库版本和检索策略defcache_key(query,ctx,kb_version):return(rag,ctx.tenant_id,ctx.permission_snapshot,kb_version,normalize(query),)权限变更、文档下架和租户迁移时还要让相关缓存失效。只修向量查询而不检查缓存隔离仍然可能被绕过。权限过滤还要覆盖引用和日志有些系统检索时做了租户过滤却在回答中展示了完整的文档 URL、文件名或来源摘要另一些系统为了调试把全部召回文本写进应用日志。这些信息可能本身就是敏感数据。因此审计记录应保存“引用了哪份文档、哪个版本、哪条切片、按什么权限策略召回”但日志内容应脱敏不能为了可追溯而复制整篇合同。对高敏感字段可以保存哈希、字段级标签和受控的审计引用。评测不能只测回答质量多租户 RAG 的安全测试要固定一组跨租户对照数据租户 A 和租户 B 使用相似问题但答案中必须只出现各自的事实同一用户在权限变更前后召回集合应发生预期变化被下架文档不能通过缓存、旧索引或引用链接再次出现不存在的资源与无权限资源对外返回一致的错误语义检索、上下文、引用和工具调用都能关联到同一个请求 ID。安全评测的断言应尽量落在“返回了哪些文档 ID、租户 ID 和字段”而不是只看模型最终写出的自然语言。后者可能因为改写而掩盖了数据已经越界。一次评审我会先问七个问题租户过滤是在向量数据库执行还是在应用层补做文档级 ACL 是否和用户的实时权限绑定检索缓存键是否包含租户和权限快照文档下架、权限变更和版本切换如何触发索引与缓存失效引用、调试日志和错误响应是否可能泄露跨租户元数据测试是否验证了“召回集合”而不仅是模型回答能否从一次回答追溯到租户、用户、文档版本和检索策略如果团队只能回答“Prompt 里要求模型不要泄露”说明真正的数据隔离还没有建立。模型不应该承担租户隔离的最后责任。串库问题不能交给模型自觉多租户 RAG 的底线不是让模型“记住自己不能串库”而是让跨租户数据在进入模型之前就没有机会相遇。检索相关性决定候选顺序访问控制决定候选集合。 多租户 RAG 为什么会串库？从检索过滤到审计追踪
多租户 RAG 为什么会串库从检索过滤到审计追踪作者元宝一个安全研发的 AI 安全观察与实践笔记多租户 RAG 最危险的地方是“回答看起来很正常”。用户问的是自己的合同条款模型返回的内容也语气流畅、引用完整只有其中一段来自另一个租户。假设一个 SaaS 平台为不同企业提供合同助手。文档入库时记录了tenant_id但检索接口为了复用缓存只按向量相似度查询拿到结果后再由应用代码尝试过滤。某个异常分支漏掉了过滤条件跨租户内容就可能进入模型上下文。这不是模型幻觉而是数据隔离失效。模型只是把已经越过边界的内容重新组织了一遍。串库的典型路径必须在召回前记录来源最后兜底租户 A 用户提问检索网关向量索引返回相似切片应用层拼接上下文模型回答租户 A 用户租户 B 文档租户与资源过滤引用与审计响应脱敏安全边界应该在“召回前”建立。越晚过滤越可能出现缓存污染、日志泄露、上下文拼接错误和异常响应差异。三个经常被混淆的概念概念说明不能替代什么租户隔离数据属于哪个企业或项目用户对单个资源的权限资源授权当前用户能否访问这份文档租户级索引隔离相似度相关性文档与问题是否语义相关任何权限判断向量相似度只是排序信号。一个跨租户文档越相关越不应该因此被召回。一个容易漏过滤条件的实现defretrieve(query,user,top_k5):filters{tenant_id:user.tenant_id}resultsvector_db.search(query,top_ktop_k)return[itemforiteminresultsifitem.metadata.get(tenant_id)filters[tenant_id]]这段代码的问题不在于“最后过滤”一定错误而在于它默认所有召回内容已经安全地进入应用内存。此时内容可能已经被写入调试日志、缓存或模型请求记录如果top_k较小跨租户文档还可能挤掉本租户真正需要的结果。更稳妥的方式是让向量数据库或检索网关在服务端执行强制过滤defretrieve_authorized(query,auth_context,top_k5):filters{tenant_id:auth_context.tenant_id,resource_acl:{$in:auth_context.groups},status:active,}returnvector_db.search(queryquery,filtersfilters,top_ktop_k,audit_contextauth_context.request_id,)字段名可以不同但执行顺序不能反过来身份和资源权限是硬约束相似度只能在约束范围内排序。缓存往往是隐藏的串库点为了降低延迟系统可能按问题文本缓存检索结果。如果缓存键只有规范化后的 Query那么租户 A 问“违约金怎么计算”租户 B 可能直接命中同一份结果。缓存键至少要绑定租户、用户权限版本、知识库版本和检索策略defcache_key(query,ctx,kb_version):return(rag,ctx.tenant_id,ctx.permission_snapshot,kb_version,normalize(query),)权限变更、文档下架和租户迁移时还要让相关缓存失效。只修向量查询而不检查缓存隔离仍然可能被绕过。权限过滤还要覆盖引用和日志有些系统检索时做了租户过滤却在回答中展示了完整的文档 URL、文件名或来源摘要另一些系统为了调试把全部召回文本写进应用日志。这些信息可能本身就是敏感数据。因此审计记录应保存“引用了哪份文档、哪个版本、哪条切片、按什么权限策略召回”但日志内容应脱敏不能为了可追溯而复制整篇合同。对高敏感字段可以保存哈希、字段级标签和受控的审计引用。评测不能只测回答质量多租户 RAG 的安全测试要固定一组跨租户对照数据租户 A 和租户 B 使用相似问题但答案中必须只出现各自的事实同一用户在权限变更前后召回集合应发生预期变化被下架文档不能通过缓存、旧索引或引用链接再次出现不存在的资源与无权限资源对外返回一致的错误语义检索、上下文、引用和工具调用都能关联到同一个请求 ID。安全评测的断言应尽量落在“返回了哪些文档 ID、租户 ID 和字段”而不是只看模型最终写出的自然语言。后者可能因为改写而掩盖了数据已经越界。一次评审我会先问七个问题租户过滤是在向量数据库执行还是在应用层补做文档级 ACL 是否和用户的实时权限绑定检索缓存键是否包含租户和权限快照文档下架、权限变更和版本切换如何触发索引与缓存失效引用、调试日志和错误响应是否可能泄露跨租户元数据测试是否验证了“召回集合”而不仅是模型回答能否从一次回答追溯到租户、用户、文档版本和检索策略如果团队只能回答“Prompt 里要求模型不要泄露”说明真正的数据隔离还没有建立。模型不应该承担租户隔离的最后责任。串库问题不能交给模型自觉多租户 RAG 的底线不是让模型“记住自己不能串库”而是让跨租户数据在进入模型之前就没有机会相遇。检索相关性决定候选顺序访问控制决定候选集合。