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.