泄露是数据流缺陷
当 agent 发布了作为输入提供的产物时，失败并不在于模型学会了泄露。而在于系统没有任何机制来区分输入与输出，也没有要求在内容跨越该边界之前做出明确的导出决策。模型做了模型该做的事：从上下文中生成文本或选择媒体。缺陷在于流水线默认将生成输出视为安全，并且对进入其中的数据没有污点追踪。
这一区分很重要，因为它改变了修复方式。如果问题被框定为对齐失败，团队就会诉诸行为干预：prompt 指令、拒绝训练、输出分类器。这些对某些类别的危害有用，但对溯源而言是错误的层级。它们检查的是模型的行为，而非数据的旅程。一个模型可以完全对齐，却仍然在流水线把用户图像附加到外发消息上而不询问任何人时将其发出。
关于 agent 在实验室不知情的情况下发布用户图像的报道说明了这一模式：图像是工作流的输入，而失败在于它们在没有任何地方做出导出决策的情况下变成了输出。这是一个可处理的数据流缺陷。它可以通过标签、传播规则和出口闸门来修复。对齐式的解释掩盖了这种可处理性。
agent 流水线的污点追踪
污点追踪是来自操作系统和安全信息流的成熟理念：在数据进入系统时标记它，在每一次转换中传播该标记，并阻止那些会将标记数据发送到不受信任的接收端而没有明确释放的操作。agent 流水线需要同样的纪律，并适配于文本、图像、embedding 和 tool call。
入口处打标签
每一个进入上下文窗口的产物都应至少携带两个字段：
- 敏感度类别（例如：公开、内部、机密、个人数据）
- 来源标识符（哪个用户、哪次上传、哪个连接器、哪次 retrieval 命中）
这些标签应在产物进入运行时的边界处附加，而不是事后从内容中推断。推断是有损且可被对抗的。文件描述符、数据库行或上传事件知道数据来自哪里；摘要器则不知道。
在转换中传播
标签必须在摘要、embedding、重新生成和改写中存活。这正是大多数实现失败的地方，因为让 agent 有用的转换同时也是剥离元数据的转换。一个具体的机制：将上下文表示为带类型 span 的列表，每个 span 携带其文本或媒体引用以及其溯源集合。当模型生成摘要时，该摘要的溯源是其作为条件所依赖的 span 溯源集合的并集。当该摘要被 embedding 时，embedding 继承该并集。当该 embedding 被检索并用于生成新段落时，该段落再次继承它。
这一并集规则是保守的：它会过度污染。如果一份公开文档和一份机密文档都在上下文中，生成的输出就是机密的。这是安全方面的正确默认值，但这是一个真实的权衡。过度污染会降低 agent 的效用，因为本可释放的输出会被阻止或需要审查。团队可以通过溯源感知的 prompting（仅以任务所需的 span 为条件）以及明确且被记录、而非隐含在模型判断中的解密规则来缓解这一点。
出口闸门
每一条可以将内容发出运行之外的路径都应查询所发出内容的溯源。出口路径包括：
- 发往外部渠道的消息
- 写入共享存储的文件
- 向第三方 API 发送内容的 tool call
- 渲染的页面或附件
- 被发送到外部可观测性服务的日志和 trace
如果内容的污染程度高于目标所允许的敏感度，则除非存在释放决策，否则出口被阻止。释放决策应指明产物、目标、允许它的策略以及授权的主体。它应被记录在可稍后查询的存储中。
一个最小的执行点可以表达为策略检查：
def can_export(artefact, destination):
if destination.allowed_sensitivity < artefact.sensitivity:
return require_release(artefact, destination)
return True
重要的特性是这一检查运行在出口路径上，而非模型内部。不能信任模型记住哪些输入是敏感的；流水线可以。
将 retrieval 视为只读、将生成视为安全
一种常见的心智模型将流水线分为读阶段（retrieval、tool call）和写阶段（生成、发布）。读阶段被假定为安全，因为它只读取。写阶段被假定为安全，因为它只写入新内容。两者由上下文窗口连接，而这一连接正是溯源丢失之处。如果
修复方法是将上下文窗口视为带有溯源的数据结构，而非不透明的字符串。这意味着 agent 框架——而不仅仅是应用——需要在其消息类型中携带标签。
依赖只检查文本而不检查附加媒体的输出过滤器
输出过滤器通常扫描生成文本中的模式：PII、密钥、违禁字符串。它们很少检查附加的图像、音频或文件。一个将用户图像附加到消息上的 agent 可能通过所有文本过滤器，同时泄露该图像。过滤器看到的是无害的说明文字；附件则未被检查。
媒体出口需要与文本相同的溯源检查。作为用户上传进入运行的图像应携带敏感度标签和来源标识符，任何将其附加到外发消息的尝试都应查询该标签。基于内容的媒体分类器可以对此补充，但它们不能替代溯源，因为它们无法知道用户是否同意这一特定导出。
一份最小契约
一份可行的 agent 运行契约小到可以用几行陈述：
- 任何产物离开运行都必须带有溯源记录，指明其来源以及允许释放的策略。
- 溯源记录在事后可查询，而不仅仅写入日志接收端。
可查询性是团队跳过的那部分。将溯源写入仅追加日志是必要的，但不充分。当事件发生时，问题不仅是“发生了什么”，而是“哪些来源的哪些产物在哪些策略下到达了哪些目标”。那是一个查询，它应当无需从原始日志重建运行即可回答。一个包含产物标识符、来源、敏感度、转换历史、目标、策略和授权主体字段的溯源存储，使事件审查成为一次查找，而非一项考古工程。
权衡是运营成本和摩擦。溯源追踪为每个上下文 span 增加元数据，这增加了 token 用量和工程复杂度。出口闸门增加延迟，并可能阻止合法工作流。解密工作流增加人工审查。这些成本是真实的，团队应界定其执行的敏感度类别和出口路径，而不是在第一天就尝试完整的信息流控制。在重要的路径上执行一份狭窄而强制的契约，比一份宽泛而未执行的契约更有价值。
替代方案是继续将泄露视为对齐失败，并继续以无法看到数据历史的 prompt 更改和输出过滤器来应对。这种方法将持续错过那一类失败——模型根本没有行为不当：它只是发出流水线放在它面前的东西，因为流水线中没有任何东西知道输入与导出之间的区别。
封面照片：panumas nikhomkhai / Pexels。