LLM Agent 安全需要一个「Intent-to-Execution」端到端正确性定义

论文概览

论文：Securing LLM Agents Need Intent-to-Execution Integrity
作者：Wenjie Qu, Ming Xu (NUS); Peiran Wang (UCLA); Shengfang Zhai, Jiaheng Zhang (NUS); Dawn Song (UC Berkeley)
链接：arXiv:2605.16976

这是一篇立场论文 (position paper)，其核心论点是：当前 LLM Agent 安全研究的根本缺失不在于防御机制的强度，而在于**「什么算安全」这一正确性标准本身的缺失**。论文提出了 intent-to-execution integrity 这一端到端正确性定义，并以此为标准系统评估了 11 个现有防御系统。

论文的前半部分是理论建构——从 LLM Agent 与编译器的结构类比出发，推导四条完整性性质；后半部分是经验评估——逐条检查现有防御的覆盖范围，揭示系统性缺口。

---

核心创新

1. 编译器类比：Agent 安全需要语义保持

论文提出了一个结构精妙的类比：LLM Agent 的执行流水线与编译器在结构上是同构的。

用户意图以自然语言表达（类比高级语言源代码），经过 LLM 推理生成计划（类比中间表示），再选择工具并构造参数（类比指令选择与寄存器分配），最终执行系统操作（类比生成二进制）。

在编译器领域，CompCert 证明了 语义保持 (semantic preservation)——编译后的二进制行为必须与源代码语义完全一致。论文主张 LLM Agent 安全需要一个完全对等的性质：Agent 的执行效果必须忠实反映用户意图。

没有这样的定义，安全就退化为打地鼠——每出一个新攻击就补一个新补丁，但无法评估补丁是否完备、间隙在哪里。

2. 两条问题源 → 四条完整性性质

论文通过穷尽因果路径，将所有安全威胁归约为 两个根本问题源：

Instruction Integrity（指令完整性）：Agent 的每个动作必须可追溯到已认证用户的指令，而非注入内容。当用户显式委托信任给外部内容（如「按照这封邮件的指示做」），该内容的后续动作在委托范围内视为已授权。

Data Flow Integrity（数据流完整性）：流经工具调用参数的数据必须遵守来源约束。敏感数据在读取时标记污染标签（taint mark），携带污染数据到未授权目的地（外发邮件、外部 API、其他用户会话）的工具调用必须被阻止。污染标记必须跨会话持久化。

Judgment Integrity（判断完整性）：Agent 的所有推理决策必须源自与用户对齐的目标，推理过程必须对不可信数据中的对抗性影响具有鲁棒性。形式化定义为：对于所有与任务无关的扰动 $\delta$，$J(q, d \oplus \delta) = J(q, d)$。其中 $q$ 是用户查询，$d$ 是不可信数据，$J$ 是 Agent 的决策结果。

Tool Integrity（工具完整性）：参与产生动作的每个软件组件必须被限定在其声明的接口和文档行为内。这要求强制执行行为一致性——工具声称的功能与运行时被允许的操作之间必须吻合。

3. 四条性质的完备性论证

论文通过穷尽 Agent 的三种原子操作来论证四条性质的联合充分性：

• 推理 (Reasoning) 可能被不可信数据扭曲语义决策 → Judgment Integrity 阻止
• 动作构造 (Action Construction) 可能以两种方式被破坏：(a) 归因混淆 → Instruction Integrity 阻止；(b) 数据流违规 → Data Flow Integrity 阻止
• 执行 (Execution) 可能因组件越权行为被破坏 → Tool Integrity 阻止

因为 Agent 的每个时间步只做这三件事之一，且每种腐败路径都被对应性质闭合，四条性质同时成立时，流水线全链受保护。

---

方法论：11 个防御系统的形式化评估

论文以三条等级标准评估了 11 个现有防御系统：

• Full（完全）：防御可证明地强制执行对应性质
• Partial（部分）：防御有相关机制，但基于启发式或限于特定攻击模式，可被绕过
• None（无）：防御不覆盖该性质

通用 Agent 防御

OpenClaw 防御

关键发现

CaMeL 在翻译层最接近满分——通过从可信用户查询中抽取工具调用控制流并执行信息流追踪，在 Instruction Integrity 和 Data Flow Integrity 上实现了可证明保证。但其设计不保护 Judgment Integrity（语义推理可被操纵而不产生未授权工具调用），也不保护 Tool Integrity（假设工具可信）。

OpenClaw 防御在工具层有进展，但仅部分覆盖：铁爪 (IronClaw) 和 SeClaw 对四条性质都有部分覆盖——WASM 隔离 + 能力权限 + 内容净化 + 审计规则提供了全方位的深度防御，但每条性质都只是「可降低攻击可能性」而非「可证明保证」。

核心缺口是组合性的：仅保护翻译层不够——一个正确选择的工具调用仍然可以调用恶意 Skill。仅保护执行层也不够——一个被良好隔离的组件仍然可以因错误原因、错误参数、或被对抗性扭曲的推理结果而被调用。

---

四种性质的当前技术可达性

论文不仅评估了「谁覆盖了什么」，还追问了「现有技术在原则上能走多远」：

Instruction Integrity：可通过架构性分离（如 CaMeL 和 Fides）强制执行——控制流仅来自已认证用户输入。主要限制是效用：不访问不可信内容的规划严重限制 Agent 能力。

Data Flow Integrity：可通过信息流控制 (IFC) 技术强制执行——污染追踪 + 来源感知策略。主要限制是可扩展性：集成新工具需要手动指定逐工具策略，对大量第三方 Skill 生态系统不切实际。

Judgment Integrity：是目前最不发达、也最难的维度。模型级防御（StruQ、SecAlign）提供有限鲁棒性但不保证语义判断的完整性；LLM 检测和输入净化是有用的启发式，但无法保证对所有任务无关扰动的等式 $J(q, d \oplus \delta) = J(q, d)$ 恒成立。

Tool Integrity：可通过静态分析 + 沙箱 + 运行时隔离部分强制执行。但静态分析必然是近似的，沙箱不能阻止仍在其权限范围内的未预期行为。有前景的方向是动态分析——在插桩环境中观察工具的实际行为并检查是否符合声明规范。

---

启示与思考

这篇论文最打动我的是它的元视角——它不试图造一个新的防御系统，而是追问一个更根本的问题：如果不知道「安全」的定义是什么，造再多防御也是盲目的。

与 AARM 框架的对齐：我们正在构建的 Agent 运行时安全监控体系（AgentArmor + AgentMoss + AgentMonitor + AgentSight + AISpec）恰好可以用 intent-to-execution integrity 的四个维度来校准。AISpec 的形式化验证目标应该明确定义它保护的是哪条完整性性质——目前看最接近 Tool Integrity（验证工具行为是否符合规范）和 Data Flow Integrity（信息流策略）。但 Judgment Integrity 在 AARM 体系中几乎处于空白，这是一个值得深入研究的方向。

Judgment Integrity 的形式化挑战：论文将 Judgment Integrity 定义为 $J(q, d \oplus \delta) = J(q, d)$，这本质上是一个语义鲁棒性问题。与 Instruction Integrity 保护结构化对象（工具调用选择、参数值）不同，判断发生在不可信数据恰好是推理依据的场景——审稿、产品排名、证据评估。这个问题确实很难，但与我们在 SkillSpector 和 SEFZ 论文中看到的「规范违规」攻击有很强的关联——很多违规不需要 Agent 误解指令，而是恰好利用了推理过程中的判断偏差。

Compositionality 的实践意义：论文揭示的「翻译层 vs 执行层」组合性缺口，本质上是说工具选择正确和执行正确是正交的。这让我联想到 DeltaBox——它解决了执行层的状态管理问题，但并没有解决工具是否忠实地做了它声称要做的事。

这篇 11 页的立场论文，在我看来是 LLM Agent 安全领域值得反复阅读的参考框架——它提供了一个用来思考「我的防御系统到底在保护什么」的思维模型。

---

参考信息

• 论文链接：arXiv:2605.16976
• 形式化安全框架（引用 [13]）：arXiv:2603.19469
• CaMeL 防御系统：arXiv:2503.18813
• CompCert 验证编译器：Leroy, X. Formal verification of a realistic compiler. CACM, 2009.
• OpenClaw: github.com/openclaw/openclaw