检索页面没有显示，敏感片段就算安全了吗

一次检索从全库召回 50 个片段，权限模块在返回页面前删掉 45 个，用户最终只看到 5 个。很多系统会把这次请求记为“权限校验通过”。

问题出在被删掉的 45 个片段已经走过哪里。它们可能进入重排模型，可能写进共享缓存，也可能被拼入大模型上下文。页面没有显示，只能证明最后一层挡住了结果，无法证明前面的组件没有接触敏感内容。

档案检索的权限测试因此要沿着整条数据路径进行。用户身份怎样转换为过滤条件，过滤条件在哪一层执行，候选集何时缩小，缓存键是否包含权限版本，模型输入保存了哪些审计信息，这些问题共同决定暴露面。

权限前置的核心是减少模型和检索器接触不该接触的数据。

只在回答前过滤，不能消除召回阶段已经接触敏感片段的风险。

把一次查询拆成四个检查点

第一个检查点是身份解析。用户、岗位、部门、授权范围和当前有效期应生成一次可审计的权限上下文，而不是由前端临时拼接。第二个检查点是候选检索，向量库或全文索引必须使用这份上下文过滤。第三个检查点是模型输入，重排器和生成模型只能收到过滤后的片段。第四个检查点是结果返回，再做一次资源状态与权限版本校验，用来处理查询期间发生的权限变化。

日志可以保存 request_id、user_id、policy_version、filter_hash、candidate_count、allowed_count 和 context_doc_ids。无需保存敏感正文，也能在事故复盘时回答：当时执行的是哪版规则，多少候选被挡住，哪些文档进入过模型。

一个最小过滤条件应当可重放

下面的结构只表示思路，字段名称应服从本单位的权限模型：

{
  "must": [
    {"open_state": "open"},
    {"resource_status": "active"}
  ],
  "any": [
    {"dept_id": "D017"},
    {"authorized_users": "U2048"}
  ],
  "policy_version": "2026-08-16.3"
}

把 policy_version 和过滤条件摘要写入查询日志，同一请求便可以在测试环境重放。权限规则更新以后，旧请求应按新旧两版分别执行，差异由安全人员和档案人员确认，不能只看最终答案像不像。

payload 字段决定能不能前置过滤

向量库要做权限前置，前提是 payload 里有可过滤字段。只存文本和 embedding，后面就只能召回后再补权限。最小字段应包含用户权限能判断的内容：全宗、部门、开放状态、密级或安全级别、档案门类、保管期限、资源状态。

不同系统字段名称可以不同，但规则要在召回前可执行。例如普通用户只能查 open 状态，某部门用户只能查本部门形成或授权范围内材料，涉密资源不进入非涉密索引。模型不应该先看到再自觉不说。

两种过滤位置的风险完全不同

召回前过滤，是把用户无权访问的内容挡在检索引擎之外。召回后过滤，是先让系统拿到候选，再删掉不该展示的结果。对于普通搜索，两者有时看起来结果相同；对于大模型，上下文风险完全不同。

如果不开放片段进入模型上下文，即使最终答案删掉，也已经发生了越权暴露。权限前置的目标是让无权内容从一开始就不参与召回、排序和生成。

回归测试要包含越权样本

权限测试不能只测“有权限能看到”。还要测“没权限看不到”，而且要通过 API、检索引擎和模型上下文三层验证。可以准备一组 closed 样本，用普通用户请求相似问题，检查召回 hit、模型输入和最终答案都没有这些文本。

新增数据、重建索引、调整切片、更换向量库时，都要复跑这些越权样本。权限一旦退化，比准确率下降更严重。档案 AI 项目宁可少答，也不能把不该看的材料带进模型。

权限变更要触发索引处理

开放状态或权限规则变化后，索引不能继续使用旧 payload。系统要么在查询时实时查权限，要么在权限变化后更新索引 payload。哪种方式取决于性能和复杂度，但不能假装权限不会变。

尤其是开放鉴定、密级变更、用户岗位调整后，旧索引可能产生越权风险。权限前置是要和数据变更流程绑定。

过滤日志要记录数量变化

一次查询可以记录三组数量：原始候选数、权限过滤后候选数、最终返回数。数量变化能帮助排查问题。比如原始候选很多，过滤后为零，可能是权限太窄，也可能是 payload 写错；原始候选为零，则要检查切片和索引。

这些日志不需要保存敏感原文，但要保存规则版本和过滤条件。安全问题出现时，团队能知道当时系统按哪一套规则执行。

越权样本要保留到回归测试里

权限前置做完后，要把越权样本长期保留下来。每次重建索引、调整切片、替换向量库，都用同一批样本测试普通用户是否能召回受控内容。

越权测试不应只看最终页面，还要看模型上下文。受控片段只要进入上下文，即使最后没有展示，也说明过滤位置存在风险。

缓存和重排器是最容易漏测的两层

共享缓存必须把权限上下文纳入键空间。仅使用问题文本做缓存键时，高权限用户查询产生的候选集或答案可能被低权限用户命中。较稳妥的做法是使用用户可访问范围摘要、策略版本、索引版本和查询摘要共同生成缓存键，并在岗位、开放状态或授权关系变化时使相关缓存失效。

重排器也要单独检查。很多架构在向量召回后把较大的候选集交给重排模型，再截取前几条给生成模型。如果权限过滤发生在重排之后，敏感片段仍然进入了模型。测试记录应分别保存召回前、重排前和生成前三个文档编号集合，三组集合一对比，过滤位置是否正确便很清楚。

撤权测试比初次授权更容易暴露问题。先让用户合法访问一份材料，使检索缓存、会话上下文和查询历史都产生记录；随后撤销权限，再用原问题、改写问题和同一会话分别查询。受控片段若仍从缓存或历史上下文返回，说明权限只作用于新检索，没有覆盖已经形成的中间状态。

离线部署也不能省掉这条链。档案行业不应把受控原文和模型上下文发送到在线公共模型，但模型放进内网，只解决了数据传输边界。内网中的向量库、重排器、推理服务和日志平台仍是不同组件，每层都要按最小权限访问，并记录文档编号和策略版本。

权限服务不可用时，检索接口应采用明确的失败策略。高风险档案场景宜拒绝请求或降级到无敏感内容的公开集合，不能因为权限接口超时就去掉过滤条件继续查询。故障演练要主动停止权限服务，检查 API 返回、候选数量、缓存命中和告警记录，确认系统确实按预期收紧。

领至科技在档案 AI 检索项目中，会把越权样本和撤权样本放进发布前回归。模型升级、切片调整或索引重建都可能改变候选集合；只有受控文档在召回、重排、上下文和最终回答四处都不出现，权限边界才经得住复测。

一个系统先从全库召回 50 条，再按用户权限删掉 45 条；日志里虽然只显示 5 条结果，但模型重排阶段已经见过被删掉的片段。

在向量库、全文索引或数据库查询阶段就带入 open_state、dept_id、role_id、security_level，可以避免敏感数据进入后续排序和模型上下文。

日志应记录候选数量、过滤数量、返回数量和过滤原因。这样才能发现权限配置异常或用户越权尝试。

技术辩论要回到边界条件。 这里的边界条件就是：档案 AI 与通用企业检索安全：数字档案馆/室场景坚持开放控制和权限审计。 在这个前提下，召回前/召回后过滤对比表 能帮助项目组判断什么时候必须前置、什么时候可以后置、什么时候需要双重校验。

很多项目只保留成功样本，这是后期返工的来源。AI 检索权限前置过滤 至少要准备一组反例：权限不允许、状态不完整、对象不存在、日志缺失、校验失败、人工复核未通过。反例用于确认系统边界，避免错误路径被当作正常能力。

如果不开放片段进入模型上下文，即使最终答案删掉，也已经发生了越权暴露。权限前置的目标要看让无权内容从一开始就不参与召回、排序和生成。

尤其是开放鉴定、密级变更、用户岗位调整后，旧索引可能产生越权风险。权限前置要看要和数据变更流程绑定。

[阅读原文](https://www.lingzh.cn/index.php?c=show&id=160)

AI 检索为了提速，可能会缓存召回结果、重排结果、上下文片段或模型回答。如果缓存没有绑定用户、角色、部门、开放状态和权限版本，就可能出现 A 用户的问题结果被 B 用户复用。

如果权限字段只在首次建库时写入，后续开放鉴定、部门调整、密级变更没有同步，召回前过滤就会使用旧规则。

因此，权限前置要配套数据同步机制。目录库权限字段变化后，索引层要更新；更新失败要报警；更新记录要能审计。

脱敏适合降低字段暴露风险，比如隐藏手机号、身份证号、个人住址。权限过滤解决的是用户是否有权接触材料。无权材料即使脱敏，也不应随意进入模型上下文。

同一项目不同年度，同一工程不同标段，同名人员不同部门，公开材料和内部材料题名相近，审批通过材料和未审批材料正文相似。

档案人员负责开放状态和利用规则口径。安全人员负责角色、部门、账号和审计要求。技术人员负责索引字段、过滤位置、缓存隔离和日志记录。

很多项目想做权限前置，落地时才发现索引里没有可过滤字段。向量库里只有 chunk_id、text 和 embedding，全文索引里只有正文，权限字段仍留在业务库里。

这时检索服务很难在召回前过滤，只能先召回再回业务库校验。要补回来，就要重建索引和同步链路。

所以，做 AI 检索前就要确认：每个片段是否知道自己的档号、所属部门、开放状态、密级、审批范围和资源类型。

日志里如果只有用户 ID 和查询词，后面无法解释当时为什么能看或不能看。更稳的做法，是记录权限版本或过滤条件快照。