Tool Call Replay Attack: How It Works and How to Prevent It
A tool call replay attack occurs when a previously captured, legitimately authenticated tool call request is intercepted and resubmitted to an AI agent runtime, causing it to execute again. Prevention depends on runtime-layer controls that bind freshness and intent to each request, not only to the session.
What a Tool Call Replay Attack Is, and Is Not
A tool call replay attack targets the transport and execution layer of an AI agent architecture, not the model’s reasoning. An attacker intercepts a legitimate, already-authorized tool call, such as a JSON-RPC request an agent sent to invoke an external API through a protocol like MCP, and resubmits it later without modification.
Because the original request carried valid authentication at the time it was issued, the replayed copy often still passes authentication checks if the runtime only verifies that a token or session is valid, not whether the specific request has already been executed. This distinguishes replay from prompt injection or jailbreaking, which manipulate the model’s decision-making upstream. A replayed tool call requires no influence over the agent’s reasoning at all; it bypasses intent verification entirely by re-executing an action the model believed was already complete.
The impact depends on what the tool call does. Replaying a read-only query has limited consequence beyond information exposure. Replaying a state-changing call, such as a payment, a permission grant, or a record update, can produce duplicate transactions, unauthorized privilege changes, or data corruption, because the receiving system executes the action again as if it were new.
Why AI Agent Tool-Calling Architectures Are Structurally Exposed
Several characteristics of agent-to-tool integrations make replay easier than in typical human-driven API usage. Tool calls are machine-generated and high-frequency, which means legitimate retries after network failures look similar to malicious replays; distinguishing them requires state tracking, not just authentication.
Many integrations also reuse a single bearer credential or session token across numerous tool invocations rather than issuing per-request proof of authorization, so a captured request often remains valid for the full lifetime of that token.
The Model Context Protocol defines tool invocation over JSON-RPC 2.0 and establishes sessions per connection, but the base specification does not itself mandate a replay-resistant authentication mechanism for individual tool calls. That means a session-authenticated request can be structurally identical to a replayed one at the protocol layer unless the implementation adds its own freshness controls.
This is consistent with how established standards treat the underlying problem: NIST SP 800-63B identifies replay as a threat to authenticator verification, and RFC 6750 documents that bearer tokens, once intercepted, can be reused without additional proof of possession unless explicitly bound to a client or session.
Where replay defense belongs. Because the LLM has no visibility into transport-level request history, replay defense cannot be delegated to the model. It has to be enforced by the runtime governance layer that sits between the agent and the tools it calls.
Where Replay Risk Enters the Agent Pipeline
Replay is not primarily a model-quality problem. It is a gap between legitimate issuance and repeated execution when freshness is not checked at the runtime boundary.
Capture
Tool call requests traverse logs, proxies, or network paths where they can be recorded intact.
Resubmission
The captured request is replayed unmodified, carrying its original authorization.
Execution gap
Without freshness checks, the runtime cannot distinguish the replay from a legitimate call.
Technical Controls to Prevent Tool Call Replay
Effective defense authenticates and tracks each tool call as a discrete event. The controls below are the runtime mechanisms described throughout this guide.
Per-request nonces
Each tool call carries a unique nonce that the runtime records and rejects on reuse, so a captured request cannot be accepted a second time.
Bounded timestamp windows
Requests include a timestamp validated against a short acceptance window, limiting how long an intercepted call remains eligible for execution.
Request signing
Cryptographic signatures bind method, parameters, nonce, and timestamp together, so altered or reconstructed copies fail verification.
Idempotency keys for state-changing calls
State-changing operations require an idempotency key. Duplicate submissions return the original result instead of executing the action again.
Session-bound proof-of-possession credentials
Credentials are bound to the client or session that issued them, reducing the value of bare bearer tokens captured in transit or logs.
Evaluation Criteria for Replay-Resistant Agent Deployments
Use these checks when reviewing agent runtimes, MCP integrations, and tool gateways for replay resistance.
- Tool calls are authenticated per request, not only per session or connection.
- State-changing tool calls require an idempotency key before execution.
- Timestamp and nonce validation outcomes are logged for audit and incident investigation.
- Tool calls are classified as read-only or state-changing as part of documented risk policy.
- Token and credential lifetimes are bounded, with a defined process for invalidating captured credentials.
- Protocol-level claims of replay protection (including MCP-based integrations) are verified against the actual implementation rather than assumed.
Frequently Asked Questions
Is a tool call replay attack the same as a session hijacking attack?
No. Session hijacking involves an attacker taking over an active session to issue new requests. Replay involves resubmitting an already-issued, previously legitimate request, which may not require any live session access at all.
Does MCP provide built-in replay protection?
The MCP specification defines transport and session establishment over JSON-RPC but does not itself mandate a replay-prevention mechanism for tool-call authentication. Replay resistance depends on how the implementation layer adds nonce, timestamp, or signing controls on top of the base protocol.
How is a legitimate retry distinguished from a malicious replay?
Authentication checks alone cannot make this distinction, since both carry valid credentials. Idempotency keys and request-level state tracking allow the runtime to recognize a duplicate submission and return the original result instead of re-executing the action.
A tool call replay attack occurs when a previously captured, legitimately authenticated tool call request is intercepted and resubmitted to an AI agent runtime, causing it to execute again. It succeeds because most agent-to-tool integrations authenticate at the session or token level rather than the individual request level, so a valid captured call remains structurally indistinguishable from a fresh one. Prevention requires runtime-layer controls: per-request nonces, bounded timestamp windows, request signing, idempotency keys for state-changing calls, and session-bound proof-of-possession credentials.
Enforce Replay Resistance at the Runtime Layer
Trussed AI provides runtime governance for AI agent tool calls, including MCP security, agent identity, and tool approval workflows, so replay resistance is enforced independently of the model.
Explore Runtime Governance