Agent读得合规，组合回答仍可能泄密

检索没有越权，Agent 仍然可能泄密：它读到的每份文档都合法，却把其中的信息拼成了一条不该进入共享工单的判断。原文讨论的正是这种「组合推断」风险。

作者的结论是，文档权限必须保留，但安全检查还得覆盖生成后的句子，以及句子最终写入的地方。对正在做企业知识库、客服助手和内部 Agent 的团队，这个视角值得补上。不过，作者提出的方案仍在原型阶段，还不能当成经过规模验证的标准答案。

两份都能读的文档，为什么拼起来会出问题

作者用一个内部支持 Agent 举例：它同时检索公司 wiki 和 CRM，客户经理有权读取两份资料。

文档 A 说，价格调整从公告发布后的下个月 1 日生效。文档 B 说，Acme 的续约安排在 14 日。Agent 随后写道：「Acme 会在新价格生效两周后续约，因此可以预期一次增购沟通。」

单看资料，只有定价规则和续约日期；拼成一句话后，却出现了针对具名客户谈判处境的销售判断。更关键的是，这句话被写进了另有三个人能阅读的工单。

作者把它称为「马赛克效应」（mosaic effect）：单个碎片看起来无害，拼起来可能暴露新的敏感信息。LLM 带来的变化，是把原本需要人主动完成的拼接，变成了自动发生的生成行为。

这里需要拆开两个问题：客户经理是否可以获得这个推断，以及这个推断是否可以被写入共享工单。原文认为，两者都不能从「有权读两份文档」直接推出，但没有交代具体的业务授权规则。

能读取事实，不自动等于能把组合后的结论发布给更多人。

为什么把检索权限收得更紧，也未必解决问题

作者说，自己搭建过包含向量库 ACL、分块租户标签、SQL 工具行级安全的权限体系。他认可这些控制的必要性，质疑的是它们能否覆盖生成阶段的风险。

文档权限通常回答：某个用户此刻能不能读这个对象。组合风险回答的却是：多个对象共同支持的结论，能不能出现在某个输出位置。检查对象、检查时机和接收范围都不同。

如果为了避免组合风险，直接移除所有涉及续约日期的资料，客户经理合法的问题也可能得不到完整回答。权限收紧了，产品却不好用了。

Agent 还会把这个问题进一步放大。

首先，检索返回的是分块。原文以 400 token 的切片为例：切片可能保留一个限定条件，也可能把它切掉。文档的授权单位和模型实际看到的上下文单位，并不总是一致。

其次，组合会跨轮次积累。单轮 RAG 只需要面对一次材料组合，带会话、草稿区和六次工具调用的 Agent，则可能把第 2 轮和第 9 轮的事实联系起来。只查当前这次检索，未必能看到完整路径。

最后，提示词不能补齐缺失的权限输入。作者尝试要求模型谨慎处理敏感组合，得到的结果有时含糊无用，有时直接沉默，而且不稳定。这是作者的经验描述，原文没有提供测试集、失败比例或模型对照。

模型需要知道谁在问、允许做什么推断、答案会交给谁。只给一句「注意敏感信息」，它很难执行一套没有拿到完整条件的规则。

检查移到草稿后，具体要做哪些事

作者正在试验的流程，可以整理为五步。原文重复出现的步骤，并不是额外的校验轮次。

第一步，给分块增加知识分区（compartment）标签。ACL 描述谁能读，分区描述这段内容属于哪一类知识。一个人同时能读定价资料和客户资料，不代表这两类信息的任意组合都已获准。

第二步，建立逐句来源归因。可以要求模型为每句话标注 chunk ID，也可以在生成后增加一次较便宜的蕴含判断，寻找支持该句的分块。这里的蕴含判断，就是检查资料能否支撑这句话。作者承认，归因并不可靠。

第三步，把支持同一句话的分块标签取并集。只要涉及超过一个分区，就将其列为候选组合风险。它是筛查信号，不能直接充当泄密判决。

第四步，检查输出去向（sink）。私人聊天、共享工单、Slack 频道和外发邮件的接收范围不同，同一句话需要接受的发布约束也可能不同。

第五步，根据规则选择概括、删减或拒绝。作者倾向于保留帮助，例如改成：「Acme 的续约时间可能受到价格调整影响，请与客户负责人确认。」

全量逐句归因成本较高，作者也没有大规模运行过。因此，他提出一个节省成本的办法：持续记录会话上下文涉及的分区，出现第二个分区时，再为该会话后续输出开启严格检查。

这个办法依赖一个前提：多数会话只接触一个分区。原文没有给出相关统计，不能直接据此估算自己的系统开销。

作者还建议记录「生成的句子＋支持它的分块集合」。检索日志只能说明 Agent 读过什么，无法直接解释它为什么在工单里写出某个结论。排查组合风险，需要留下生成结果与证据之间的对应关系。

我的判断

我赞同把检查延伸到答案和发布动作。尤其是能自动写工单、发消息的 Agent，风险边界已经超出了知识库查询接口。作者把「读权限」和「输出权限」拆开，指出了一个容易遗漏的工程问题。

但原文把所有组合都归入泄密，会让判断显得过满。人类员工同样会综合资料，企业也不可能为每次普通推理单独发许可证。真正需要明确的是哪些信息组合受限、哪些接收者不能看到，而这些规则仍需要组织提供。

示例本身也有证据缺口。只知道价格调整规则和「14 日续约」，没有公告日期、续约月份，就不足以确认两件事的时间关系；「两周后」也不是已被严格支撑的表述。这里同时混有敏感推断与事实依据不足两个问题。

作者建议的改写同样仍在连接定价与续约，只是降低了确定性和可操作程度。若某种关联本身就被禁止，改成「可能受到影响」仍然不够。

跨分区适合触发审查，是否允许发布仍要看具体政策和接收范围。

与只强化检索过滤相比，逐句检查覆盖了新的风险；与所有外发内容都交给人工相比，它尝试减少审核负担。但原文没有给出误报率、漏报率、延迟或成本对照，效果仍属经验判断和原型设想。作者最后将目标定位为降低风险，而非彻底预防，这一点更符合文章提供的证据。

能拿来做什么

• 给知识库助手补一份输出去向清单，明确答案会停留在私人对话，还是进入共享工单、Slack 或外发邮件，再据此设置发布规则。
• 如果 Node 服务负责编排 Agent，可以在模型生成与写入业务系统之间加入草稿检查，传入用户身份、分区标签和目标接收范围。
• 挑选定价规则与客户续约这类真实业务组合，建立小规模评估样例，同时检查推断是否有依据、组合是否被允许、目标读者是否有权接收。
• 在现有检索日志上关联最终句子及其支持分块，并让日志遵守相应访问权限；先让一次错误输出能够被追溯，再评估是否值得扩大逐句检查。