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.
Figures & tables
System
State Scope
Captured State
Checkpoint Creation
Restoration
LangGraph
Framework
Graph state, including messages, intermediate results, pending execution state
Automatic at each superstep boundary once persistence is enabled
Resume the latest checkpoint or select an earlier checkpoint for replay/branching
CrewAI
Framework
Crew/Flow/Agent execution state, including task progress, outputs, memory, and intermediate state
Event-driven once enabled; task completion is the default trigger
Restore a selected checkpoint and resume without re-executing completed tasks
Hermes
Workspace
Project/workspace files; rollback also adjusts the most recent conversation turn
Automatic before file mutations or recognized destructive commands once checkpointing is enabled
Restore a selected workspace checkpoint (or individual file) via /rollback
Cline
Workspace
Project files associated with the corresponding task-history position
Automatic after file modifications and terminal commands; enabled by default
Restore files, task history, or both from a selected checkpoint
E2B
OS/VM
Sandbox filesystem and memory state, including running processes
Explicit, at developer-selected points via create_snapshot()
Create a new sandbox from a selected snapshot
TABLE I : Checkpoint and rollback mechanisms in representative agent systems.
Fig. 1 : System model for agent checkpoint and rollback.
Fig. 2 : SF1: Incomplete internal state coverage.
Fig. 3 : SF2: Inconsistent checkpoint state.
Fig. 4 : SF3: External state mismatch.
Fig. 5 : SF4: Unbound nondeterministic replay.
Fig. 6 : SF5: Unrecorded external effects.
Fig. 7 : Methodology overview.
Framework
Dataset
SF1
SF2
SF3
SF4
SF5
LangGraph
AgentBench
99
0
49
89
6
TerminalBench
201
0
50
139
11
CrewAI
AgentBench
106
0
0
80
3
TerminalBench
222
0
0
196
4
Hermes
AgentBench
71
97
1
80
11
TerminalBench
183
143
43
140
0
TABLE II : Prevalence of security failures.
Reference
#
Reference
#
now
222
earlier
52
current state
178
previous run
44
this environment
87
this task
41
currently
83
here
39
TABLE III : Frequent semantic references to external context.
External Action
#
Execute → Commit
Commit → Execute
Payment
30
28
29
Message
31
29
30
Resource change
35
33
34
Overall
96
90 (93.8%)
93 (96.9%)
TABLE IV : Recovery failures under different orderings.
Appendix figures & tables1 asset
Supplementary material from the paper’s appendix.
Appendix
SF
Precision
Recall
Accuracy
SF1
96.6%
100.0%
97.8%
SF2
100.0%
100.0%
100.0%
SF3
100.0%
100.0%
100.0%
SF4
100.0%
100.0%
100.0%
SF5
100.0%
90.0%
99.8%
Overall
98.7%
99.9%
99.5%
Appendix
TABLE V : Manual validation of security-failure detection.
Artificial intelligence agent security studies attacks and safeguards for tool-using, persistent, and collaborative systems across digital and physical settings.
A durable agent can resume a consequential action while its authority changes and the action's external outcome remains uncertain. We study execution-time reliability of tool-using AI agents, isolating recovery decisions from language-model behavior. Checkpoint state, permission to dispatch, evidence of an external effect and permission to reconcile are distinct obligations. We present a finite conformance study that checks these obligations through histories scored against a provider effect ledger hidden from the recovering application. A prospectively frozen campaign executes 336 histories on native LangGraph and Temporal hosts, crossing 14 schedules, three provider contracts and four matched application policies. All 168 paired host cells have identical checked outcomes. Per host, retained-ledger reconciliation passes all 42 histories: 21 checked completions, 15 denials and six unknown outcomes with reservations retained. Cached retry, revalidation before retry and stable-key retry pass 30, 36 and 31 histories respectively. A separate 16-case component study of InfinityOS, an enterprise AI platform developed by Arya.ai, exercises exported authority, worker, recovery and settlement code over repository fakes. The results isolate the roles of current authority, provider contracts and retained observations in recovery, with safety, completion and unresolved obligations reported separately for the declared application profile.
Autonomous agents act through sandboxed containers and microVMs whose state spans filesystems, processes, and runtime artifacts. Checkpoint and restore (C/R) of this state is needed for fault tolerance, spot execution, RL rollout branching, and safe rollback-yet existing approaches fall into two extremes: application-level recovery preserves chat history but misses OS-side effects, while full per-turn checkpointing is correct but too expensive under dense co-location. The root cause is an agent-OS semantic gap: agent frameworks see tool calls but not their OS effects; the OS sees state changes but lacks turn-level context to judge recovery relevance. This gap hides massive sparsity: over 75% of agent turns produce no recovery-relevant state, so most checkpoints are unnecessary. Crab (Checkpoint-and-Restore for Agent SandBoxes) is a transparent host-side runtime that bridges this gap without modifying agents or C/R backends. An eBPF-based inspector classifies each turn's OS-visible effects to decide checkpoint granularity; a coordinator aligns checkpoints with turn boundaries and overlaps C/R with LLM wait time; and a host-scoped engine schedules checkpoint traffic across co-located sandboxes. On shell-intensive and code-repair workloads, Crab raises recovery correctness from 8% (chat-only) to 100%, cuts checkpoint traffic by up to 87%, and stays within 1.9% of fault-free execution time.
AI agents can be interrupted while editing files, calling tools, or carrying out multi-step tasks. Restarting repeats completed work, but continuing from unverified or outdated progress can carry earlier errors forward. A saved state is not necessarily a suitable place to resume. We introduce recoverability as a system primitive that makes reuse an explicit decision: select a supported starting point and a permitted recovery action, or withhold automatic continuation. Its behavioral contract binds that choice to supporting evidence, execution, and independent checks. A reference architecture connects persistence, validation, and control, with complementary runtime instances testing distinct responsibilities. Four deterministic and 20 paired file challenges demonstrate that accurate restoration and successful completion can conceal disallowed starting points. Progress controls attribute retained work to shared restoration. Event-time tests show that permission must also constrain the action, and that independently held policy evidence can expose violations even after an effect occurs. These findings establish why recovery decisions need their own evaluation, beyond restored bytes and final task success. Within supplied policies and a declared trust model, the contribution is a common, testable interface for retaining justified progress and making the conditions for its reuse explicit and enforceable.
Zhihui Zhang, Wei Liu
Independent researcher · Beijing Information Science and Technology University