元数据过滤常被当成检索精度优化：按部门、语言或日期缩小范围。但当字段代表访问权限时，它首先是安全边界。
考虑两份同名报价文件：一份属于当前用户所在项目，另一份属于其他客户。若先从全库检索，再让模型看完候选片段后要求它“不提及无权内容”，敏感信息已经进入了模型上下文。即使最终页面没有显示，也不能把这种做法当作权限控制。
把授权条件带进检索
查询时根据已验证的身份构造可访问范围，在取候选之前限制文档集合。切块入库时保留文档标识、版本和权限继承关系；权限变化后，要能更新或撤销相关片段。最终引用链接也必须再次校验访问权限，不能只保护回答文字。
不同索引对过滤的执行时机和性能支持不同，需要用真实数据验证召回。如果过滤后没有足够证据，就明确返回证据不足，而不是悄悄退回无权限的全库搜索。精度可以调参补救；越权的候选集不能靠提示词补救。
过滤条件从哪里来
不能让模型从用户问题里猜部门或租户，更不能直接信任前端传来的 tenant_id。检索服务应从已验证的会话取得主体身份，再由权限服务计算可读范围。片段既要有文档 ID，也要能关联文档的授权状态；如果权限继承发生变化，旧索引不能继续按过期标签开放。
有些系统为了降低延迟，先全库向量召回再在应用层过滤。这种做法可能导致两个问题：候选不足时返回空结果，以及未授权片段在日志或后续组件中短暂出现。若检索引擎支持授权前过滤，应优先验证其执行语义；若无法保证，至少要把受限数据隔离到独立索引，并在进入重排器和模型前强制校验。具体方案取决于索引能力和租户规模。
用负例测安全边界
测试不能只用管理员账号。构造两个用户、两份语义相近但授权不同的文档，询问同一个问题；再撤销其中一人的权限，检查旧链接、缓存答案、引用地址和增量索引是否同时失效。另一个用例是用户显式要求“忽略权限”，系统也不能把这句话变成过滤条件的例外。
权限正确性和检索质量是两个独立指标。一个安全但常常找不到答案的系统需要改善索引；一个回答精准却跨越授权边界的系统则不能上线。
缓存与引用也属于同一边界
即使检索时正确过滤，缓存仍可能把 A 用户的答案直接交给 B 用户。缓存键至少要包含会影响可见范围的主体或授权范围版本；权限变更后，旧答案还要失效。引用地址也不能是一个所有人都能直接打开的静态文件 URL，应在用户点击时再次验证身份与文档权限。
排障日志同样需要约束。可以保存片段 ID、过滤规则版本和拒绝原因来定位问题，但不要让低权限运维页面展示被过滤片段的正文。一次真正的权限测试应覆盖“检索、生成、缓存、引用、日志”整条路径，而非只检查向量库的一次过滤调用。
过滤过严时怎么排障
系统返回空结果，可能是资料确实不存在，也可能是权限标签漏写，或过滤语法让候选全被排除。面向普通用户，这些原因不一定可以全部公开；面向有权限的维护人员，则需要看到“候选阶段数量、过滤后数量、规则版本和索引更新时间”。这样能在不暴露正文的前提下判断故障点。
若某个授权用户本应看到文档却未召回，不应临时关闭权限过滤做对照并把结果展示给他。可以在受控测试环境以明确授权身份复现，核对文档标签与权限服务计算结果。安全边界出问题时，调大 Top-K 不是修复；先厘清哪个系统是授权的权威来源。