研究者提出 Agent 检查点回滚的五类安全失效，并在 Hermes、Cline、LangGraph 上实现三种攻击

检查点与回滚（C/R）在忠实恢复记录状态的同时，如何因状态依赖断裂而破坏智能体的执行连续性（execution continuity）并引入安全风险。

• 场景与重要性：AI 智能体正迈向持久、有状态的自主执行，重头重跑的成本随状态与外部效应累积而大幅增加，使 C/R 成为关键的基础恢复机制；但 2026 年企业调查显示 79% 的受访者曾逆转智能体动作，42% 报告过因智能体故障导致的收入损失。
• 现有机制的不足：现有 C/R 系统仅关注恢复状态本身的正确还原，未考虑恢复边界之外的依赖；作者指出正确的回滚并不等同于安全的恢复，合法恢复的检查点可能将执行恢复至状态、假设与外部效应从未共存过的状态。
• 核心观察与执行连续性：恢复会将前期确立的安全事实向后传递，但这些事实的有效性依赖跨框架、工作区、随机决策与外部世界的异构依赖；作者提出执行连续性（execution continuity）要求安全相关状态、决策、假设和效应在恢复后必须与合理的持续执行历史保持一致。
• 论文的解决方案：作者系统形式化了智能体恢复模型，提炼出 5 种破坏执行连续性的安全故障模式（SF1–SF5），实现了基于多智能体的自动化检测与验证管线，并在真实框架上完成了端到端攻击与大规模实证测量。
• 威胁模型：
  • 攻击者目标：利用 C/R 破坏执行连续性，使智能体从无效恢复状态恢复（invalid recovered state）或产生无效恢复转换（invalid recovery transition），无需篡改检查点内容或破坏恢复机制本身。
  • 攻击者知识：知晓任务工作流以及目标系统公开记录的 C/R 行为特性。
  • 攻击者能力：可影响智能体输入、工作流指令（如通过恶意 skill）或工具与服务响应（如恶意 MCP 服务器），以此诱发可恢复故障触发系统回滚；在回滚接口直接暴露时可直接调用。
  • 受害系统与可信边界：受害系统为集成 C/R 机制的智能体框架；检查点存储、C/R 实现语义及受信任第三方的安全判定被视为不可被攻击者直接篡改的可信组件。

相关研究主要分布在以下领域：

传统检查点与防回滚安全

• 分布式恢复机制：Chandy & Lamport (1985)、Elnozahy 等人 (2002) 研究了分布式快照、协调/非协调检查点与基于日志的恢复协议，关注执行能否恢复到一致全局状态。
• 防回滚系统安全：Parno 等人 (2011, Memoir)、Niu 等人 (2022, Narrator) 等研究了受保护模块与可信执行环境下的状态连续性，防止系统状态被非法恢复到陈旧但真实的历史版本。

智能体检查点与恢复系统

• 智能体状态恢复系统：CRAB (Wu 等人, 2026)、DeltaBox (Dong 等人, 2026) 和 AgentRewind (Zhuang 等人, 2026) 分别基于 OS 可见效应、毫秒级沙箱快照或上下文与环境联合快照优化恢复性能；作者指出这些工作侧重于状态的捕获与恢复机制，而本文关注恢复后安全相关事实是否依然有效。
• 智能体恢复语义与回滚安全：Resume Means Resume (Khan, 2026) 形式化了工作流恢复契约；DART (Yang 等人, 2026) 形式化了语义可恢复性；ACRFence (Zheng 等人, 2026) 展示了涉及重放与已消耗权限的回滚攻击；Atomix (Mohammadi 等人, 2026) 与 Cordon (Chen 等人, 2026) 探索了工具智能体的事务安全。作者指出这些工作未对检查点和回滚开展全面的安全分析。

智能体系统安全与评测

• 恶意组件与交互威胁：Greshake 等人 (2023)、Debenedetti 等人 (2025) 研究了提示注入；Wang 等人 (2026, MCPTox) 与 Schmotz 等人 (2026, Skill-inject) 研究了恶意工具与恶意 skill 注入。
• 评测框架与基准：实验基于 5 款代表性智能体 C/R 系统（LangGraph、CrewAI、Hermes、Cline、E2B），并在 TerminalBench（命令行任务）、AgentBench（OS、DB、ALFWorld 环境）、SWE-bench、OSWorld-Human 和 AgentDojo 上展开评估。

作者称这是针对现有智能体系统检查点与回滚机制的首个系统性安全研究，明确指出了正确还原状态与保证恢复安全之间的鸿沟，从跨状态边界依赖的视角刻画安全故障。

作者通过形式化建模、模式提炼与自动化分析管线解决该问题，整体依托多智能体分析框架与原生回滚验证。

执行模型与执行连续性形式化

作者将智能体系统建模为逻辑进程集合 P = {P1, P2, ..., Pn}，每个进程独立演化；事件 e = (a, ξ) 包含操作 a 与非确定性因素 ξ；检查点 CK 覆盖进程子集 K ⊆ P；外部世界 W 包含不受智能体回滚控制的远端服务与环境状态。回滚在时刻 tr 重构的配置为：

该公式表示回滚后的全局配置由被检查点覆盖的恢复进程状态、未被覆盖进程的恢复状态以及回滚时外部世界的当前状态共同组合而成。作者指出恢复可能通过两种方式违反执行连续性：恢复出在任何合法连续执行中均不可能共同出现的无效恢复状态，或允许合法连续执行所禁止的无效恢复转换。

五种安全故障模式（SF1–SF5）

• 内部状态覆盖不全（SF1）：检查点遗漏了安全恢复所需的内部进程状态，恢复后未覆盖进程可能保留回滚后的较新状态（newer-state carryover）或回落到初始陈旧状态（older-state fallback）。
• 内部状态不一致（SF2）：检查点捕获的状态虽然齐全，但各个组件的状态无法构成单一因果一致割集（causally valid cut），例如包含了对某事件的消费记录却未包含该事件的生成状态。
• 外部状态不匹配（SF3）：检查点内捕获的状态依赖外部世界，但在恢复时刻 tr 外部世界状态已发生改变：

该公式表示在恢复时刻外部世界状态发生改变，导致检查点中捕获的内部状态所依赖的前提假设或安全判定不再成立。

• 无约束非确定性重放（SF4）：回滚重新执行后续操作时，模型采样或外部随机性导致分叉，体现为安全决策跨路径复用（cross-path reuse）或重试放大（retry amplification）。
• 未记录的外部效应（SF5）：检查点后的操作在外部产生了持久修改，但回滚抹除了内部记录，导致外部效应孤立失控（orphaned effect）或非幂等操作重复执行（effect replay）。

自动化检测与验证多智能体管线

• 数据收集（Collector）：执行目标任务，捕获运行时轨迹（模型与框架操作、检查点内容、状态演化）以及任务代码和 C/R 配置等程序静态上下文。
• 语义重构（Analyzer）：将轨迹规范化为语义事件 ei = ⟨opi, Ini, Outi, NDi⟩，构建事件与状态间的因果与包含依赖；在回滚验证前，基于任务目标将改变会导致成败变动的状态和持久外部修改标注为安全相关。
• 候选筛选（Checker）：基于 SF1–SF5 对应的规则评估结构化事件轨迹，扫描依赖断裂的候选故障。
• 原生回滚验证（Validator）：调用目标系统的原生恢复机制恢复选定检查点，并重新执行后续操作（针对 SF4 候选独立重复重放 3 次），根据安全相关事实是否被打破确认最终漏洞。

实验设置

• 被测系统与模型：测试 5 款代表性 C/R 框架（LangGraph、CrewAI、Hermes、Cline、E2B）；统一使用 DeepSeek-v4 作为智能体执行、工作流构建与语义事件重构的后端大模型。
• 评测数据集与规模：包含来自 TerminalBench 的 241 条命令行轨迹（涵盖软件工程、系统配置、机器学习与安全等），以及来自 AgentBench 的 106 条轨迹（涵盖 OS、DB、ALFWorld 环境），共计 347 条基准轨迹、1735 次框架-任务执行。
• 检查点生成机制：LangGraph 在每个 superstep 自动保存；CrewAI 在任务完成时创建；Hermes 在文件写入或破坏性命令前自动创建；Cline 在文件修改和终端命令后自动快照；E2B 在每次工具调用完成后显式调用快照 API。
• 指标与判定定义：以执行级发生率（Prevalence）作为主要指标，记录执行与回滚中各 SF 是否至少出现一次；在人工核验中评估检测 Precision、Recall 和 Accuracy。
• 样本量与重复设置：在每条轨迹中随机选取一个检查点作为固定恢复点；对于 SF4 的非确定性重放候选，保持环境状态不变独立重复执行 3 次以验证路径分叉。

主结果

下表展示任务量更大的 TerminalBench 各框架表现及全部 1735 次执行的总计结果（据 Table II，因篇幅未单独展示包含 106 个任务的 AgentBench 分行）：

表格较宽，可左右滑动

• 五类故障发生频率不同：作者指出 SF1（67.2%）与 SF4（67.7%）最为普遍，SF1 因检查点常遗漏工作区或运行时等内部状态，SF4 源于模型采样与工具的随机分叉；SF5 仅占 2.3%，作者解释是由于现有基准大多操作本地文件与环境，较少调用外部服务产生持久非幂等效应。
• 恢复边界决定故障特征：作者指出 E2B 凭借沙箱文件系统与内存的系统级快照未出现 SF1 与 SF2；LangGraph 和 CrewAI 仅保存框架状态而排除工作区导致 SF1 高发但无 SF2；Hermes 和 Cline 因独立恢复工作区与对话/任务历史导致大量 SF2（两基准分别出现 240 次与 249 次）。
• 前置条件影响发生分布：作者指出 CrewAI 未出现 SF3，因其在任务启动阶段创建检查点，此时外部依赖尚未建立；SF2 与 SF3 需要更特定的状态依赖关系，因而发生率低于 SF1 与 SF4。

端到端攻击案例与可利用性验证

• 测试内容：针对 3 个典型场景构建端到端攻击（Hermes 恶意代码验证绕过利用 SF1、Cline 未授权邮件转发利用 SF3、LangGraph 单次审批双重支付利用 SF5），并从验证的故障中随机抽取 30 个样本构建恶意 skill 攻击。
• 测试结果：3 个端到端案例均在不篡改检查点与恢复机制的前提下成功触发越权或绕过；抽取的 30 个攻击样本全部在真实框架上成功执行，且使用的恶意 skill 均未被现有的恶意 skill 检测工具（Wang et al., 2026）识别。
• 作者解读：作者指出正确的 C/R 仍然会打破执行连续性并被攻击者利用，将合法的安全决策重新绑定到无效的上下文（未验证工件、非预期资源或重复效应）。

外部动作提交顺序微基准评测

• 测试内容：基于 TerminalBench 常见外部动作模式构建包含 96 个持久外部动作的工作流（涵盖支付 30 个、消息 31 个、资源变更 35 个），在执行与检查点之间注入可恢复故障，对比先执行后提交（execute->commit）与先提交后执行（commit->execute）两种顺序。
• 测试结果（据 Table IV）：execute->commit 出现 90 次故障（失败率 93.8%），commit->execute 出现 93 次故障（失败率 96.9%）；支付类分别失败 28 次与 29 次，消息类分别失败 29 次与 30 次，资源变更类分别失败 33 次与 34 次。
• 作者解读：作者指出仅靠调整检查点与外部动作的执行顺序无法消除恢复鸿沟，前者导致效应已持久化但记录丢失（触发重复执行），后者导致记录已持久化但效应未执行（导致动作遗漏），必须依赖幂等机制或分布式事务等外部协调机制。

检测管线的人工验证精度

• 测试内容：人工检查所有轨迹与恢复点样本并独立标注真实标签，评估检测管线对五类安全故障的判定表现（据 Table V）。
• 测试结果：整体检测精度达到 Precision 98.7%、Recall 99.9%、Accuracy 99.5%；其中 SF2、SF3、SF4 均实现 100.0% 的 Precision、Recall 和 Accuracy；SF1 的 Precision 为 96.6%、Recall 100.0%、Accuracy 97.8%；SF5 的 Precision 为 100.0%、Recall 90.0%、Accuracy 99.8%。
• 作者解读：作者指出检测管线能够准确识别五类安全故障，误差仅存在于 SF1 的极少数误报以及 SF5 的个别漏报。

其他消融与分析

• 语义外部引用频率分析：在 1735 次执行中共识别出 1357 个依赖外部上下文的语义引用，最高频词为 now（222 次）、current state（178 次）、this environment（87 次）和 currently（83 次）（据 Table III）。
• 重放非确定性来源：作者分析指出重放分叉源于三类欠规范状态，即缺失执行顺序步骤、缺失完整成功校验条件、以及缺失相关依赖环境细节。

作者指出的局限与后续方向

• 故障模式的覆盖范围：作者指出该研究聚焦于由检查点与回滚恢复引入的安全违规，五种故障模式刻画了在其模型下破坏执行连续性的常见方式，但并未旨在覆盖智能体系统中的所有安全故障（Section VII）。
• 测试方法的目标定位：作者指出其实验分析识别的是恢复风险隐患，其实际可利用性取决于外围应用与攻击者能力；因此该测试方法旨在暴露和验证恢复违规，而非认证智能体系统的安全性（Section VII）。
• 安全恢复的多维度依赖：作者指出安全恢复需要超越单纯扩大快照范围，必须在跨内部状态、外部假设、持久效应和重放结果之间维护或重建安全相关依赖（Section VII）。
• 异构状态域的恢复边界：作者指出智能体执行日益跨越框架、子智能体、运行时、工作区和外部服务，恢复机制应被视为跨组件的安全边界，而非仅仅恢复单个组件状态（Section VII）。
• 外部持久效应的协调支持：作者指出仅靠调整检查点顺序无法解决外部效应一致性，智能体 C/R 需要依托事务、幂等保证或持久效应记录等外部协调机制以防止 SF5（Section VI-D）。

实验覆盖范围

• 后端模型：实验使用 DeepSeek-v4 作为后端大模型，论文未报告其他商业或开源 LLM 作为后端的对比实验。
• 被测框架：覆盖 LangGraph、CrewAI、Hermes、Cline、E2B 共 5 款代表性智能体 C/R 系统。
• 任务轨迹与基准：评估基于 TerminalBench（241 条命令行轨迹）与 AgentBench（106 条涉及 OS、DB、ALFWorld 轨迹），共计 347 条轨迹、1735 次框架-任务执行。
• 外部动作微基准：受控评测包含 96 个涉及持久外部动作的工作流，覆盖支付（30 个）、消息（31 个）和资源变更（35 个）。
• 恢复点与重放设置：对每个执行轨迹随机选取 1 个检查点作为固定恢复点进行原生回滚；对非确定性重放验证设定为独立重复重放 3 次。

• 研究定位：该研究针对持久状态化 AI 智能体的检查点与回滚（C/R）机制，探讨了状态还原过程中的系统安全性。
• 核心问题：随着智能体运行周期延长，C/R 成为从故障中恢复的关键手段；但现有机制仅关注状态本身的正确恢复，忽略了跨越恢复边界的安全依赖，导致恢复后的执行可能进入历史中从未合法共存的状态。
• 方法要点：作者将现有 C/R 归纳为框架、工作区和 OS/VM 三类恢复边界，提出了包含多进程与外部世界的执行模型；形式化定义了执行连续性概念，提炼出内部覆盖不全（SF1）、内部状态不一致（SF2）、外部状态不匹配（SF3）、无约束非确定性重放（SF4）和未记录外部效应（SF5）五类故障模式；并设计了集收集、分析、检查与原生验证于一体的多智能体分析管线。
• 关键实证结果：
  1. 在 TerminalBench 与 AgentBench 的 1735 次执行中，SF1 和 SF4 最普遍，出现率分别达 67.2%（1166 次）与 67.7%（1174 次）；SF5 因评估任务多为本地操作仅占 2.3%（40 次）（据 Table II）。
  2. 针对系统级沙箱的 E2B 未观察到 SF1 与 SF2；而仅恢复工作区文件的 Hermes 和 Cline 暴露出大量 SF2 故障，在两基准上分别出现 240 次与 249 次（据 Table II）。
  3. 在包含 96 个持久外部动作的微基准中，调整执行与提交顺序均无法解决恢复鸿沟，先执行后提交与先提交后执行的失败率分别为 93.8%（90 次）和 96.9%（93 次）（据 Table IV）。
  4. 构建的 3 个真实端到端攻击与 30 个基于恶意 skill 的测试用例均攻击成功，且未被现有恶意 skill 检测工具拦截。
• 作者结论与启示：作者指出正确恢复检查点内容并不等同于安全的执行恢复，回滚极易破坏支撑安全决策的上下文与依赖关系；未来的智能体恢复机制必须将恢复视为跨组件的安全边界，通过显式状态绑定、事务一致性与幂等协调机制保障恢复安全性。