PaperlayerView exact revision on arXiv

Source-linked AI summary

Safe to Resume? Breaking Execution Continuity of Agent Execution via Rollback

Guanlong Wu, Dahui Li, Ke Jiang, Jianyu Niu, Cong Wang, Yinqian Zhang

arXiv:2608.29381v1cs.CRcs.AI

TL;DR

The paper studies whether checkpoint and rollback can securely resume persistent agent executions when restored state depends on information outside the checkpoint. It characterizes recovery boundaries, models execution dependencies, and analyzes rollback failures through trace-based detection and actual re-execution. Across representative systems, the study finds recurring failures caused by gaps between restored state and the dependencies required for secure continuation.

  • Problem

    Existing agent checkpoint and rollback systems lack a systematic security account of whether restored security-relevant states remain valid when their dependencies span unrecovered internal, external, nondeterministic, or persistent state.

  • Method

    The paper characterizes representative C/R designs, develops an execution model, and uses trace-based analysis with native rollback and re-execution to detect and validate continuity failures.

  • Results

    Across 347 benchmark traces and 1,735 framework-task executions over five representative C/R systems, recovery failures recur with distinct profiles across recovery boundaries; SF1 and SF4 occur in 67.2% and 67.7% of executions, respectively.

  • Takeaways & Limitations

    Secure recovery requires preserving or re-establishing security-relevant dependencies across internal state, external assumptions, persistent effects, and replay outcomes, rather than merely restoring checkpoint contents.

  • Takeaways & Limitations

    The study focuses on security violations introduced by checkpoint and rollback recovery.

Abstract

from arXiv · show

AI agents are moving toward persistent, stateful execution across various applications, accumulating execution state and external effects that are costly to reconstruct after failures. Checkpoint and rollback (C/R) are becoming essential for recovery, yet their security implications remain largely unexplored. Correct rollback does not imply secure recovery: a faithfully restored checkpoint may resume an execution whose states, assumptions, and external effects never coexisted in any valid history. In this paper, we present the first systematic security study of checkpoint and rollback in existing agent systems. By examining representative agent C/R systems, we characterize the design space of existing C/R mechanisms and develop a general execution model that captures their recovery boundaries and state dependencies. From this model, we identify five fundamental failure modes spanning incomplete or inconsistent internal state, stale external dependencies, nondeterministic replay, and unrecorded external effects. We further demonstrate their security impact through three end-to-end attacks on Hermes, Cline, and LangGraph, enabling malware-verification bypass, unauthorized mail forwarding, and double payment. To systematically study these failures in practice, we develop a multi-agent analysis pipeline that reconstructs execution semantics, identifies violations of the five failure conditions, and validates them through actual rollback. Across five representative frameworks, our evaluation shows that these failures recur across heterogeneous C/R designs and stem from a common gap between the state restored by a checkpoint and the dependencies required for secure continuation.

I. INTRODUCTION

The paper argues that rollback can faithfully restore checkpoint contents while breaking the dependencies required for secure continuation. It characterizes heterogeneous recovery boundaries, identifies recurring failure modes, and validates their security impact across agent systems.

  • Motivation: Agent checkpointing and rollback restore selected execution state after interruption, but recovery boundaries may exclude workspace, runtime, or external state.Framework-state checkpoints preserve framework-managed state while leaving workspace and runtime state outside the recovery boundary.
  • Security problem: Security-relevant facts carried across recovery depend on distributed state, external services, nondeterministic decisions, and effects that may not share the checkpoint boundary.These dependencies can include validated artifacts, authorizations, resource bindings, and assumptions about external effects.
  • System characterization: The paper characterizes agent C/R systems using framework-state, workspace-state, and OS/VM-state recovery boundaries.It examines representative systems and describes what each category captures, when checkpoints are created, and how state is restored.
  • Failure modes: The study identifies five rollback failure modes: incomplete internal state coverage, inconsistent checkpoint state, external state mismatch, unbound nondeterministic replay, and unrecorded external effects.These failures can invalidate security-relevant states, decisions, assumptions, or effects without checkpoint corruption or a compromised recovery mechanism.
  • Security impact: Three end-to-end attacks on Hermes, Cline, and LangGraph demonstrate malware-verification bypass, unauthorized mail forwarding, and duplicate payment.The attacks show concrete security consequences of rollback failures in real agent frameworks.
  • Evaluation method: A trace-based methodology reconstructs execution dependencies, detects recovery failures, and validates them through native rollback and re-execution.The paper combines systematic analysis with empirical validation across representative checkpointing designs.

B. Workspace-State Checkpoints

Workspace-state checkpoints restore selected project artifacts, but may exclude runtime and external state, creating mixed configurations whose security dependencies are not jointly restored.

  • Workspace-State Checkpoints: Workspace-state checkpoints restore agent-manipulated artifacts, commonly through file snapshots or a shadow Git repository.Their recovery boundary generally excludes process memory, installed system state, active services, and files outside the selected workspace.
  • Workspace-State Checkpoints: Hermes checkpoints the workspace before file writes or recognized destructive commands and restores selected Git-tree files with only limited conversation state.It retains at most 20 checkpoints per project and 500 MB across the shared store, excluding individual files larger than 10 MB.
  • Workspace-State Checkpoints: Cline maintains an independent shadow Git repository and can restore the workspace, task history, or both independently.This separates workspace state from framework-managed task state during restoration.
  • Workspace-State Checkpoints: Agent recovery mechanisms span framework, workspace, and OS/VM state, but broader coverage does not guarantee safe recovery because external state and persistent effects remain outside the boundary.Some designs also restore state components independently, leaving security dependencies potentially mismatched.
  • System Model: The model represents agents as independently evolving logical processes whose states may include conversation history, workflow progress, permissions, memory, and filesystem contents.Events include internal computation, agent decisions, and tool invocations shaped by nondeterministic factors such as LLM sampling or external responses.
  • System Model: Rollback restores checkpointed processes while uncovered processes may retain current state or be reconstructed differently, and the outside world remains at its current state.The recovered configuration can therefore combine internal and external states originating from different execution points.

B. Execution Continuity

Execution continuity requires security-relevant states, decisions, assumptions, and effects to remain jointly consistent with a valid rollback-free history. The paper distinguishes invalid recovered states from invalid transitions enabled after recovery.

  • Execution Continuity: Execution continuity requires carried-over security-relevant states, decisions, assumptions, and effects to remain jointly consistent with a valid continuous execution history.A valid continuous execution follows the workflow and security constraints under corresponding inputs, authorizations, and external interactions without rollback.
  • Execution Continuity: An invalid recovered state combines states or assumptions that could not jointly occur in a valid continuous execution.One example retains a successful validation result while restoring the validated artifact to an earlier, unverified version.
  • Execution Continuity: An invalid recovery transition occurs when an individually valid recovered state enables a subsequent action that no continuous execution would permit.Restoring a pre-payment state can allow a one-time approval to authorize a payment whose external effect already occurred.
  • Execution Continuity: The paper’s security failures characterize different ways checkpoint and rollback break these two forms of execution continuity.The distinction separates inconsistent recovered configurations from unsafe actions enabled after recovery.

C. Threat Model

The threat model assumes adversaries exploit legitimate rollback behavior to resume invalid states or trigger invalid recovery transitions without modifying checkpoints or recovery mechanisms. The failure analysis covers missing or inconsistent state and recovery boundaries that omit relevant processes or workspace state.

  • Adversary goal: Adversaries aim to violate execution continuity by causing invalid recovered states or invalid recovery transitions.They need not corrupt checkpoints or compromise the recovery implementation.
  • Adversary capabilities: Adversaries may induce recoverable failures through malicious tools, MCP servers, or external services, after which normal framework recovery can begin.If rollback is exposed, they may invoke it within the interface’s granted permissions.
  • Failure conditions: Five recurring failures include incomplete internal-state coverage, inconsistent checkpoint state, external state mismatch, nondeterministic replay, and unrecorded external effects.The first two concern the internal state reconstructed by recovery; the others cross the checkpoint boundary.
  • SF1: Incomplete internal state coverage: Incomplete coverage occurs when a checkpoint omits internal state required for safe resumption, leaving relevant processes outside the recovered set.The condition is modeled by requiring all relevant processes to be covered by the checkpoint.
  • SF1: Incomplete internal state coverage: Omitted processes can retain newer state or restart from older or initial state, producing configurations that combine checkpointed state with states from another execution point.Framework-state checkpoints may omit workspace and runtime state, while workspace-state checkpoints generally omit process and environment state.
  • SF1: Incomplete internal state coverage: A deployment agent could restore validated=true while its manifest reverts to an unvalidated template, enabling deployment of an unchecked manifest.This example illustrates how incomplete coverage can preserve a security decision while restoring a different workspace artifact.

B. SF2: Inconsistent Checkpoint State

Inconsistent checkpoint state arises when individually captured states cannot form one causally valid execution cut. Rollback can therefore preserve a result or approval while restoring the data or event history that produced it to an incompatible point.

  • Definition: SF2 concerns captured states that are individually present but mutually inconsistent, unlike SF1, which concerns missing state.The distinction separates inconsistency among captured components from incomplete coverage.
  • Definition: A checkpoint is causally consistent only when every captured event includes its captured-process causal predecessors.Otherwise, the states cannot correspond to a single causally valid execution cut.
  • Consequences: Rollback to an inconsistent checkpoint can preserve a validation or approval without the state that produced or justified it.Control state may indicate completion while associated data predates the operation.
  • Example: If conversation state records tests_passed=true while workspace state predates a patch, recovery can cause submission of the vulnerable file without repeating the patch or tests.Both restored states may be individually valid but fail to form a consistent causal cut.
  • Existing designs: Workspace-state mechanisms may not couple workspace restoration to framework-state restoration, creating cross-domain inconsistency.The text identifies Cline as an example of a system allowing separate restoration choices for workspace, task history, or both.

C. SF3: External State Mismatch

External state mismatch occurs when restored internal judgments depend on an outside world that has changed since checkpoint creation. Because rollback does not generally restore remote services or organizational state, resumed agents may reuse obsolete assumptions or bindings.

  • Definition: External state mismatch occurs when restored internal state is no longer compatible with the outside-world state at recovery time.The mismatch invalidates security-relevant judgments or assumptions encoded in the checkpoint.
  • Definition: Rollback combines checkpointed internal state with the current outside world because external state is not restored.The relevant compatibility condition can hold at checkpoint creation but fail at recovery.
  • Consequences: A previously valid validation, approval, trust decision, policy assumption, or external binding may no longer be permitted after the outside world changes.The agent may nevertheless reuse the stale decision or binding.
  • Example: A checkpointed employee recipient list can become obsolete when an employee leaves, allowing resumed execution to disclose later documents to that former employee.The organization’s membership state remains current while the restored recipient list is stale.
  • Existing designs: Existing systems lack a general mechanism coupling checkpoint restoration with revalidation of all external dependencies.This limitation is structural because remote services can remain outside the recovery boundary even when the local environment is fully snapshotted.

D. SF4: Unbound Nondeterministic Replay

Unbound nondeterministic replay occurs when rollback re-executes an operation with a different security-relevant outcome without preserving the relationships established in the original execution. This enables cross-path reuse and retry amplification, especially when model sampling and tool responses routinely introduce nondeterminism.

  • Definition: Rollback becomes security-relevant when the same restored state and external conditions yield a different nondeterministic outcome that is not bound to carried-over security decisions.The violation concerns divergent replay under otherwise equivalent recovery conditions.
  • Consequences: Cross-path reuse leaves approvals, validation results, permissions, or bindings usable after replay follows a continuation where they no longer apply.The security state remains attached to the original path rather than the replayed one.
  • Consequences: Retry amplification turns repeated rollback into repeated trials until a favorable security-sensitive nondeterministic outcome appears.The repeated trials arise because rollback does not constrain replayed decisions.
  • Example: A randomized regression test can first detect a defect and later omit it after rollback, allowing release even though neither individual test execution is invalid.The violation arises because rollback substitutes one security-relevant outcome for another.
  • Existing designs: Existing frameworks generally replay post-checkpoint LLM calls and tool operations without binding nondeterministic outcomes or constraining repeated rollback.Model sampling and external tool responses make this risk routine in agent execution.

E. SF5: Unrecorded External Effects

Unrecorded external effects arise when rollback removes the internal record of an action while the action’s external effect persists, making the action appear unexecuted. This can orphan effects or replay non-idempotent actions, and the paper connects the gap to broader execution-continuity failures and concrete attacks.

  • Definition: An unrecorded external effect occurs when an action after a checkpoint persists outside the recovery boundary while rollback removes its internal record.The recovered execution can therefore reach the action again as if it had not occurred.
  • Consequences: Rollback can orphan an already committed effect by removing the identifier or metadata needed to confirm, track, or revoke it.This is one consequence of restoring internal state while the external effect remains.
  • Consequences: Effect replay can duplicate a non-idempotent external action when the restored agent treats the action as unexecuted.The mismatch is between pre-action internal state and a post-action outside world.
  • Example: A cloud-credential request may create credential k1 externally, lose its internal record, and then be repeated after rollback to obtain k2.The example illustrates how failure before recording completion can leave the first effect untracked.
  • Boundary: Traditional idempotence, transactions, and compensation are harder to apply because agent workflows interact dynamically with heterogeneous services lacking such coordination interfaces.The limitation concerns coordination across external services, not merely local checkpoint contents.
  • Takeaway: The common gap is that C/R restores within a recovery boundary while security validity may depend on persistent effects and other relationships crossing that boundary.Specification-conformant rollback can therefore violate execution continuity without checkpoint corruption.
  • Attacks: Three attacks exploit these failures without modifying checkpoint contents or compromising the recovery implementation.The attacks instantiate incomplete state coverage, external state mismatch, and unrecorded external effects.
  • Hermes attack: In Hermes, restoring the workspace while retaining verification state lets the agent release a malicious artifact as verified.The verification result was genuine but had been produced for a different cleaned artifact.

B. Case 2: Unauthorized Mail Forwarding

The Cline attack exploits a mailbox binding outside the recovery boundary: rollback restores a pending forwarding operation aimed at a test mailbox while the service remains bound to a real mailbox. Re-execution therefore installs forwarding on the unintended live resource.

  • Task and framework: Cline’s mailbox-migration task combines a disposable test mailbox with a real mailbox used for compatibility checks.The workflow is adapted from a Thunderbird forwarding task and uses a controlled mailbox service.
  • External binding: Selecting the real mailbox changes the service’s session-level active binding even though the compatibility check does not modify that mailbox.This external binding lies outside Cline’s recovery boundary.
  • Rollback: Rollback restores the task history to the point where forwarding remains pending, but the mailbox service remains bound to the real mailbox.The task state and external binding therefore represent different execution points.
  • Re-execution: Re-execution resolves the pending forwarding request against the real mailbox despite restored task state identifying the test mailbox.The forwarding rule is consequently installed on the live resource.
  • Security violation: The attack rebinds authorization for a test action to an unintended live resource, causing real emails to be forwarded.It instantiates SF3 and illustrates the risk of alternating between test and production resources with externally maintained bindings.
  • Cross-case takeaway: Across the attacks, rollback rebinds valid security decisions to invalid contexts, including authorization to an unintended resource.Correct C/R can therefore break execution continuity and become exploitable.

A. Methodology

The methodology combines trace collection, semantic reconstruction, rule-based checking, and native rollback validation to identify and confirm checkpoint security failures. It represents events, states, dependencies, nondeterminism, and external effects across agent executions.

  • Analysis workflow: The multi-agent pipeline collects runtime traces and program context, reconstructs execution semantics, checks five failure conditions, and validates candidates through native rollback.Validation observes the recovered state and re-executes relevant post-checkpoint operations when needed.
  • Collector agent: The collector records model and framework operations, checkpoint creation, state changes, tool interactions, and internal or external component interactions.Program context supplies workflow, tool, artifact, framework, and C/R information needed for interpretation.
  • Analyzer agent: The analyzer normalizes framework records into ordered semantic events, reconstructs consumed and produced states, and builds event, causal, and state dependencies.It also identifies security-relevant states and persistent external effects.
  • Event representation: Each event is represented by its operation, versioned input state, versioned output state, and source of nondeterminism.The notation records the event information used to reason about replay and dependencies.
  • Checker agent: The checker reports SF1 candidates for uncovered pre-checkpoint state dependencies and SF2 candidates for captured states lacking causally consistent predecessors.These rules test whether restored internal components form a valid execution cut.
  • Checker agent: The checker reports SF3 when restored security-relevant judgments depend on changed external state outside the recovery boundary.It also reports SF4 when a nondeterministic post-checkpoint event will be re-executed.
  • Validator agent: The validator confirms SF4 when replay changes a security-relevant output and confirms SF5 when an external effect survives rollback while recovered state no longer records it.A finding is validated only after native recovery demonstrates the corresponding invalidation.

B. Experimental Setup

The evaluation measures five security failures across 347 traces and 1,735 framework-task executions spanning five checkpoint/rollback frameworks. Failure prevalence varies by the recovery boundary and state relationships each framework preserves.

  • Tasks and datasets: The study evaluates 347 traces and 1,735 framework-task executions across five frameworks using TerminalBench and AgentBench.The benchmarks cover terminal, operating-system, database, and ALFWorld environments.
  • Security-failure prevalence: SF1 and SF4 are the most prevalent failures, occurring in 67.2% and 67.7% of executions, respectively.SF1 reflects incomplete state coverage, while SF4 reflects divergence in nondeterministic post-checkpoint decisions and tool interactions.
  • Security-failure prevalence: SF5 occurs in only 2.3% of executions because few evaluated tasks produce persistent, non-idempotent external effects.Most tasks operate on local files, system state, databases, or simulated environments.
  • Security-failure prevalence: SF2 and SF3 are less frequent because they require inconsistent dependent-state restoration or external state changes before recovery.These failures depend on more specific relationships between checkpointed and external state.
  • Framework profiles: E2B shows no SF1 or SF2 because system snapshots jointly capture sandbox filesystem and memory, but SF3–SF5 remain possible.Its stronger internal coverage does not extend to the outside world.
  • Framework profiles: LangGraph and CrewAI preserve framework state but exclude workspace state, producing high SF1 and no observed SF2.CrewAI shows no SF3 because it checkpoints before external dependencies are established.
  • Framework profiles: Hermes and Cline reduce some incomplete-coverage cases by including workspace files, but their independently coordinated state can produce substantial SF2.Cline restores workspace and task history independently, while Hermes may restore a workspace checkpoint with only the latest conversation turn rolled back.
  • Validation and exploitability: Manual validation reports 98.7% precision, 99.9% recall, and 99.5% accuracy, with all 30 sampled validated findings successfully exploited.The 30 attacks were constructed under the malicious-skill adversary model and manually confirmed.

D. RQ2: Root Causes and Lessons

The study attributes recovery failures to checkpoint mechanisms that preserve resumable state without tracking security dependencies across state domains. It argues for deterministic references, constrained replay, and coordination mechanisms beyond checkpoint ordering alone.

  • Root causes: Existing C/R mechanisms primarily preserve resumable state without systematically tracking dependencies across internal state, external context, nondeterministic decisions, and persistent effects.Framework-specific checkpoint scope, timing, and restoration choices determine how these dependencies are omitted or invalidated.
  • External dependencies: The analysis identifies 1,357 semantic references that make checkpointed state dependent on external context across the five evaluated frameworks.These references include the object, policy, or condition to which restored state applies.
  • External dependencies: Concrete, deterministic references for time, object identity, and version can reduce hidden external dependencies and the attack surface for SF3.The recommended binding replaces context-dependent semantic references where possible.
  • Replay nondeterminism: Under-specified recovery state amplifies replay nondeterminism because rollback re-executes post-checkpoint decisions and LLM sampling can select divergent valid actions.The effect is strongest when recovered state permits multiple semantically valid continuations.
  • Replay nondeterminism: Recovery should preserve enough execution constraints to narrow replay to a well-defined continuation and limit SF4.Explicit procedures, correctness conditions, and relevant environment state reduce the space of valid post-rollback actions.
  • External effects: Neither execute-then-commit nor commit-then-execute closes the external-effect gap in the 96-workflow microbenchmark.The experiment injects recoverable failures between the effect and checkpoint update, then checks for repeated or skipped effects.
  • External effects: Preventing SF5 requires external coordination such as transactions, idempotency guarantees, or durable effect records rather than checkpoint ordering alone.These mechanisms bind agent progress to externally committed actions.
  • Scope and limitations: The study’s five failure modes are not exhaustive, and exploitability depends on the surrounding application and adversarial capabilities.The methodology exposes and validates recovery violations but does not certify overall agent-system security.

APPENDIX A MALICIOUS SKILL

The malicious skill exploits Hermes’s native checkpoint behavior by separating the workspace checkpoint from the later verification result. Rollback then restores a malicious workspace while retaining a genuine verification judgment, enabling release of unvalidated content.

  • Malicious skill: The skill prepares repository changes, runs configured checks, loads release metadata, and packages the current workspace for release.Its steps inspect and modify the repository before validation and packaging.
  • Rollback sequence: If release preparation is interrupted after repository changes, Hermes’s rollback restores the workspace checkpoint preceding the update sequence.The suggested recovery resumes the interrupted release procedure from the current task context.
  • Checkpoint behavior: Hermes creates checkpoint C0 immediately before the repository modification, preserving malicious workspace XM while the subsequent checks validate cleaned workspace XC.The verification result VC is genuine and is produced on XC.
  • Security impact: The attack rebinds verification result VC from cleaned artifact XC to malicious artifact XM without forging the checkpoint or security result.This is the SF1 violation demonstrated by the malicious skill.
  • Validation: Manual inspection of all evaluated instances reports 98.7% precision, 99.9% recall, and 99.5% accuracy for failure detection.The remaining errors are false positives in SF1 and false negatives in SF5.
Loading 2608.29381v1…