论文笔记：Trajectory Assurance — 安全的边界从单点变成轨迹

每步都合规，整体就有害——这是 LLM Agent 安全问题最反直觉的地方。

核心问题：单步检查为什么不够

传统的 Agent 安全方案是「每步操作前检查」：这个工具调用安全吗？这个文件写入允许吗？这个 API 请求合法吗？

这个框架在两个场景下会失效：

场景一：提示注入（Prompt Injection）
攻击者在一封邮件里埋了一段隐藏指令，Agent 读取邮件时，单步检查看到的是「读取邮件内容」——完全正常；但这封邮件里藏着一段指令序列，引导 Agent 逐步泄露敏感信息。单独看每一步都合法，合在一起是一次数据泄露。

场景二：多步骤累积危害
一个代码生成的 Agent，每步生成代码都是「合理的功能实现」；但 20 步之后，这 20 段代码组合起来引入了一个微妙的竞态条件或安全漏洞，单独看任何一步都没有问题。

Trajectory Assurance 的解法

论文的核心贡献是提出轨迹级安全保障（Trajectory Assurance）：不再逐一审视每个动作，而是将 Agent 的整个执行序列视为一个整体来评估风险。相当于从「检查每个单词的拼写」升级到「检查整篇文章的逻辑一致性」。

具体而言，轨迹级安全要处理的问题横跨多个层次：

  • 单 Agent 层：来自 prompt、记忆、检索知识、工具接口的不可信输入构成攻击面
  • 多 Agent 层：跨 Agent 委托带来身份、信任、能力控制和决策透明度的挑战
  • 基础设施层：模型路由和执行控制面本身可能被操纵，模型来源未被验证
  • 系统级：供应链完整性、可追溯性、端到端可观测性基本是开放问题

论文最核心的原则陈述：安全必须成为可验证的架构属性，而非可选的指导层。

为什么这篇论文的意义超出安全本身

它揭示了 Agent 系统的一个根本性改变：安全的边界从单点变成了轨迹。

在传统软件工程里，安全性可以通过输入验证、权限控制、API 限流等单点措施来保障。但在 LLM Agent 里，「输入」不再是一个清晰的边界——Agent 的输入是动态的、上下敏感的、嵌入在对话历史里的。安全策略必须跟着执行轨迹走，而不是跟着单个 API 调用走。

这意味着未来的 Agent 安全产品会向「轨迹审计」和「行为基线」方向演进——不是阻止某个调用，而是理解「这系列操作完成后，系统处于什么状态，是否符合预期」。

关联论文

结论：安全从「配置项」变成「架构约束」——这是 Agent 安全的范式转换。