TRAP: Tool Result Replay Attacks for Probing LLM Agent Misbinding

This paper attempts to address the security risks caused by contextual misbinding of real, unmodified tool results (tool-result misbinding) in tool-using agents.

• Scenario and importance: In long-horizon and asynchronous agent workflows, tool execution results rely on runtime components such as persistent storage, caches, message queues, and checkpoints to flow between steps. System correctness requires that each result be accurately attributed to the task and execution state that generated it.
• Gap in existing research: Existing agent security research mainly focuses on malicious input content (e.g., prompt injection, poisoned tool outputs) or execution-layer failures, and has not deeply explored the systemic risks of real, unmodified legitimate tool results being fed into incompatible contexts.
• Core observation and hypothesis: Tool results are not just simple outputs but execution artifacts with contextual constraints; once a result is decoupled from its original execution context, even if the content is real and unmodified, the agent may mistake it for valid evidence for the current task and take incorrect actions.
• What the paper proposes: The paper formalizes the tool-result misbinding problem and proposes the replay attack benchmark ReplayBench and three runtime validity-checking defense mechanisms implemented at the tool gateway.
• Threat model:
  • Attacker goal: Induce the target agent to generate inconsistent actions based on misbound real tool results, causing persistent external state errors.
  • Attacker knowledge and capability: The attacker (or faulty runtime component) associates previously generated tool results with the wrong execution context while preserving content integrity; ordinary runtime enforcement checks remain in effect, and the attacker cannot directly bypass action checks or independently modify external state.
  • Victim system: Tool-using agent systems that rely on persistent state, caches, or queues to pass tool results (e.g., systems built on LangGraph, LlamaIndex, or OpenAI Agents SDK).

Safety of tool-using agents

• Multi-step tool use risks: Ruan et al. (2024), Andriushchenko et al. (2025) (AgentHarm) evaluated safety risks and harmful behaviors in multi-step tool use.
• Indirect prompt injection: Zhan et al. (2024) (InjecAgent), Debenedetti et al. (2024) (AgentDojo) studied indirect prompt injection (IPI) that manipulates agents through external content.
• Multi-stage and protocol security: Zhang et al. (2025) (Agent Security Bench / ASB), Zong et al. (2026) (MCP-safetybench) studied broader attacks spanning prompt, memory, and execution stages. The authors note these works establish tool-mediated information flow as a core security boundary, but mainly focus on adversarial or corrupted input content.

State, replay, and context integrity

• Persistent memory and cross-task interference: Gao et al. (2026) (Mempoison) demonstrated the impact of stored information persisting in memory on subsequent behavior; Jaye et al. (2026) (Corpgen) studied cross-task interference in interleaved long-horizon agent execution.
• Asynchronous calls and replay risks: Shi et al. (2026) (Asynctool) tested asynchronous tool state maintenance under concurrent tasks; Jing et al. (2025) (MCIP), Zheng et al. (2026) (Acrfence) studied replay and rollback risks in MCP systems and checkpoint recovery.
• Formal policies and provenance: Siu et al. (2026), Wang et al. (2026), Alvarez et al. (2026) (ProvenanceGuard), Palumbo et al. (2026) formalized agent security from the perspectives of context integrity, execution provenance, and runtime policy enforcement.

Execution-layer failure evaluation and benchmarks

• Model state isolation evaluation: Bazinska et al. (2026) isolated and tested the fragile states of backbone LLMs, but did not trace end-to-end propagation of failures through the full execution flow.

• Baseline methods and benchmarks: The baseline defense used as a comparison in the evaluation is Object-ID binding; the comparison attack is indirect prompt injection (IPI) with explicit instructions. The benchmark environment is ReplayBench constructed in this paper, covering 19 application scenarios.

• Difference from existing work: The authors note that, unlike studies focusing on adversarial content injection or isolated model states, this paper systematically evaluates how real, unmodified tool results are replayed across contexts and traces the full propagation chain from delivery, action generation, and action acceptance to final state errors.

The paper proposes the evaluation benchmark ReplayBench based on controlled replay to probe agent misbinding of tool results, and designs three runtime validity-check defenses implemented at the tool gateway.

Problem Formalization and Failure Propagation

• Misbinding formalization: Let a tool call be c_s = (f, x_s), generating a real result r_s = f(x_s) under source context C_s, with a binding function satisfying B(r_s, C_s) = 1. When r_s is used in a target context C_t that does not satisfy the original binding, tool-result misbinding occurs: B(r_s, C_t) = 0. This formula defines the semantic invalidation of a legitimate result in an incompatible context.
• Four-stage failure propagation model:
  1. Result delivery: The source result is successfully delivered at the runtime level and becomes visible to the agent in the target context.
  2. Wrong action generation: After observing the misbound result, the agent generates an action inconsistent with correct execution in the target context.
  3. Action acceptance: The generated wrong action passes routine checks in the downstream execution layer and is accepted for execution.
  4. Final-state error: The accepted action causes the persistent external environment state to deviate from the correct outcome of the target task.

ReplayBench Evaluation Framework Design

• 19 application scenarios: covering email (F01), instant messaging (F02), calendar tasks (F03), cloud drive sharing (F04), search knowledge base (F05), e-commerce orders (F06), banking payments (F07), travel logistics (F08), medical prescriptions (F09), HR payroll (F10), customer support (F11), project approval (F12), identity isolation (F13), software release (F14), cloud operations and databases (F15), security operations (F16), compliance governance (F17), IoT control (F18), and government/legal (F19), all with sandboxed tools and verifiable persistent states.
• Four failure templates:
  • T01 (Cross-task wrong-object replay): Replays a legitimate result generated for task A into task B, which operates on a different object, violating task-result attribution.
  • T02 (Stale context replay): Reuses a previously valid result after authorization, resource state, or policy changes, violating context validity.
  • T03 (Repetition effect replay): Replays the result of an already committed state-changing operation, causing the operation to execute again, violating idempotency constraints.
  • T04 (Out-of-order replay): Delivers multiple real results in an order inconsistent with state transitions, violating causal ordering.
• Three replay mechanisms:
  • M1 (Durable Recovery): Persists the source result to a SQLite event store, from which a recovery consumer reads and delivers it to the target task.
  • M2 (Queue Redelivery): Writes the source result to an outbound queue, from which a worker node serving the target task dequeues it.
  • M3 (Cache Resume): Stores the source result in a session checkpoint or cache, loading it when the target execution resumes.

Runtime Validity-Check Defense Mechanisms

• Call-ID binding: At the tool gateway, assigns a call identifier to each pending verification call; delivery is allowed only if the identifier of the returned result matches the identifier of the current pending call; otherwise, it is intercepted directly at the gateway layer.
• One-shot tickets: Allows results to be delivered to the model but issues a single-use valid credential for each valid result; the agent must submit an unused credential when executing state-modifying actions; cross-session or already-used tickets are rejected by the gateway.
• World-state epochs: Binds tool results to the state generation number of the referenced object; the epoch increments when the external object undergoes state transitions such as revocation, commit, or cancellation; if the epoch does not match at action submission, execution is rejected.

Experimental Setup

• Models under test: The evaluation covers 8 LLMs, including GPT-5.5, GPT-5.6-Sol, GPT-5.6-Luna, Gemini-3.8-Flash, DeepSeek-V4-Pro, GLM-5.3, Qwen3.8-Max, and Claude-Opus-5.
• Agent frameworks: The evaluation uses 3 representative agent frameworks: LlamaIndex, LangGraph, and OpenAI Agents SDK.
• Evaluation scenarios and benchmarks: The main experiment T01 uses 7 representative scenarios (email, calendar, files, banking, identity, DevOps, security); the full benchmark extends to 19 scenarios (including e-commerce, healthcare, HR, CRM, etc.).
• Evaluation metrics: Final-state error rate (FSER) is the primary end-to-end metric, supplemented by delivery rate (DAR), wrong action rate (WAR), and action acceptance rate (AAR) for stage attribution; defense evaluation reports false rejection rate (FR) and recovery rate (Recov).
• Review and verification method: All state-changing actions are executed in a local sandbox; an independent checker reloads the persistent state after execution and checks against template-specific correctness conditions to determine whether a final-state error occurred; no LLM judge scoring is used.
• Sample size and repetitions: All experimental configurations are evaluated on n=10 valid trials by default, except sensitivity experiments extended to n=30.

Main Results

(Note: Values are from Table 4, computed based on 5,000 cell bootstrap resamples; covering all 8 tested models)

• High error rates across configurations: According to Table 1, among 168 model-framework-scenario configurations, 64 configurations (38.1%) have FSER = 1.0; the average FSER across all configurations is 0.649; across the full benchmark's 228 configurations, the average FSER reaches 0.989 (Appendix G).
• Model dominance in susceptibility differences: According to the variance decomposition in Table 6, model identity explains 74.2% of FSER variance (η²=0.742), while framework explains only 0.7% (η²=0.007); the average FSER across the three frameworks clusters between 0.607 and 0.686 (Table 5).
• Failure point localized to action generation: Stage analysis shows DAR is generally close to 1.0, and AAR closely tracks WAR and FSER, indicating that replayed results are almost always successfully delivered; the main divergence is whether the model uses the misbound result as a basis for action.

Stateful Replay Templates (T02–T04) Ablation

• Test content: Evaluates three templates that maintain object consistency (T02 context validity, T03 idempotent repetition, T04 causal ordering) in the cloud drive file-sharing scenario (F04), covering 8 models and 3 frameworks (24 configurations per template, Figure 4, Appendix E).
• Experimental results: T02 achieves FSER=1.0 in 22/24 configurations; T03 and T04 each achieve FSER=1.0 in 21/24 configurations (Figure 4). Qwen3.8-Max has FSER=0 under T01 cross-object replay but rises to 1.00 under T02–T04. Across the full benchmark's 19 scenarios, GPT-5.5 has FSER=1.00 in all 171 configurations under T02–T04 (Table 8).
• Authors' interpretation: The authors note that maintaining object consistency alone does not guarantee result validity; agents without context binding cannot recognize changes in environment state or causal ordering.

Effects of Similarity, Freshness, and Environment Changes on Replay

• Test content: Independently controls task similarity, object similarity, result freshness visibility, and environment changes with GPT-5.5 + LlamaIndex under T01 (Figure 5, Table 10, Table 11, Appendix I).
• Experimental results: In the email scenario, high/medium task similarity yields FSER of 0.80–1.00, dropping to 0 with low similarity; in the cloud drive scenario, FSER remains 1.00 even with low task similarity; object similarity shows no clear association with FSER (Table 10). Highly stale results with explicit freshness fields reduce WAR, AAR, and FSER from 1.00 to 0.60, while implicit hiding keeps them at 1.00 (Table 11). Under implicit environment changes, FSER remains 1.00; explicit notification of authorization revocation reduces FSER to 0.20 (Figure 5c).
• Authors' interpretation: The authors believe the effect of task similarity is scenario-dependent, object similarity has no direct association; explicit cues help identify invalidity evidence, but models cannot reliably infer temporal validity.

Runtime Defense Evaluation and Replay vs. IPI Comparison

• Test content: Evaluates three defenses—call-ID binding, one-shot tickets, and world-state epochs—with GPT-5.5 + LlamaIndex in F01 and F04 scenarios (Table 2, Figure 6); compares real replay with indirect prompt injection (IPI) (Table 12, Table 13).
• Experimental results: All three defenses achieve FSER=0, FR=0, and Recov=1.0 (Table 2). Call-ID binding intercepts at the delivery stage (DAR=0), while one-shot tickets and world-state epochs allow delivery (DAR=1) but intercept before action acceptance (AAR=0). In contrast, the object-ID binding baseline yields FSER=1.0 under T03 repeated replay (Appendix K). In the IPI comparison, DeepSeek-V4-Pro and GLM-5.3 have FSER of 0.60–1.00 under replay but FSER=0.00 under IPI (Table 12).
• Authors' interpretation: The authors note that FSER=0 arises from different intervention points (blocking before delivery vs. intercepting before mutation); models can reject IPI payloads containing explicit instructions but still adopt untampered replayed results, indicating that robustness to prompt injection is insufficient to prevent misbinding of real results.

Additional Ablations and Analyses

• Replay transport mechanisms (Table 7): With GPT-5.5 in F01 and F04, M1 (durable recovery), M2 (queue redelivery), and M3 (cache resume) all achieve DAR=1.0, with FSER ranging from 0.70 to 1.00.
• Trial count sensitivity (Table 9): With GPT-5.5 at n=10 vs. n=30, email FSER changes from 0.80 to 0.93, cloud drive from 0.70 to 0.87, calendar remains 1.00; Qwen3.8-Max increases slightly from 0.00 to 0.07.
• Variance decomposition (Table 6): Model factor explains 74.2% of FSER variance (η²=0.742), framework only 0.7% (η²=0.007), scenario 6.0% (η²=0.060).

Negative Results and Exceptions

• Claude-Opus-5 shows the lowest average FSER (0.019) in T01, but some configurations under T02/T04 in F04 still reach FSER of 0.70–1.00 (Figure 4).
• Explicit revocation authorization prompts do not fully eliminate errors; FSER remains at 0.20; the authors found that in specific cases the model still directly calls tools without mentioning the revocation information (Appendix I.3).
• The object-ID binding baseline completely fails on same-object repeated replay (T03), with FSER reaching 1.0 (Appendix K).

Limitations and future directions noted by the authors

• Replay paths are controlled implementations: The authors note that the persistent recovery, queue redelivery, and cache recovery implemented in the evaluation are controlled implementations of representative replay paths, not full replicas of three production-grade middleware systems (Section 3.1.3, Appendix F).
• Defenses limited to the tool gateway: The authors note that all three evaluated runtime defenses are implemented directly at the tool gateway without changing model-side prompts (Section 4.3, Appendix K).
• Freshness cues not in the main protocol: The authors note that the freshness metadata field is introduced only as a controlled ablation variable, is not included in ReplayBench's main evaluation protocol, and explicit cues cannot reliably eliminate replay abuse (Section 4.2.3, Appendix I.2).
• Call for explicit context binding: The authors call for establishing explicit context binding mechanisms in tool-using agent runtimes to ensure tool results remain valid for the current execution before being consumed (Abstract, Section 5).

Experimental coverage

• Models and frameworks tested: The experiments cover 8 LLMs (GPT-5.5, GPT-5.6-Sol, GPT-5.6-Luna, Gemini-3.8-Flash, DeepSeek-V4-Pro, GLM-5.3, Qwen3.8-Max, Claude-Opus-5) and 3 agent frameworks (LlamaIndex, LangGraph, OpenAI Agents SDK).
• Application scenario coverage: The main experiment T01 covers 7 representative scenarios, and the full benchmark extends to 19 scenarios.
• Evaluation sample size: Each configuration is evaluated with n=10 valid trials, except sensitivity experiments extended to n=30.
• Templates and replay mechanisms: The evaluation includes 4 failure templates (T01 to T04) and 3 controlled replay mechanisms (M1, M2, M3).
• Metrics not reported in the paper: The paper does not report large-scale concurrent reproduction on production-grade distributed middleware, network latency and throughput overhead, or the impact of generation hyperparameter variations such as sampling temperature on FSER.

1. Research positioning: This study targets tool-using agent systems and proposes a replay attack study and evaluation benchmark, ReplayBench, that probes contextual misbinding of real, unmodified tool results.
2. Problem to solve: In long-horizon and asynchronous execution, agents rely on caches, queues, and recovery components to route tool results. When results are detached from their original context and misused for other tasks or states, the agent mistakes them for valid evidence and produces persistent external state errors.
3. Method highlights: The paper formalizes misbinding and establishes a four-stage failure propagation model (delivery, action generation, action acceptance, state error), builds a sandboxed benchmark covering 19 application scenarios, 4 failure templates, and 3 replay mechanisms, and proposes three categories of gateway runtime defenses.
4. Main experimental findings:
   • Under T01 cross-task replay, 8 LLMs and 3 frameworks achieve an average FSER of 0.649 (Table 1), and the full benchmark average FSER is 0.989 (Table 8), with 38.1% of configurations showing FSER=1.0.
   • Model identity explains 74.2% of FSER variance (Table 6); DeepSeek-V4-Pro has an average FSER of 0.967, while Claude-Opus-5 is only 0.019 (Table 4).
   • Under the T02–T04 stateful templates that remove cross-task object differences, models still reach FSER=1.00 in the vast majority of configurations in the cloud drive scenario (Figure 4).
   • Call-ID binding, single-use tickets, and world-state epoch defenses all reduce FSER to 0 with FR of 0 and Recov of 1.0 (Table 2).
5. Author conclusion: The authors believe the root cause of replay failures lies mainly in model-side action generation; robustness to prompt injection alone cannot defend against misbinding of real results, so agent runtimes must introduce explicit contextual validity binding mechanisms.