Ghost tool calls: speculative agent execution leaks user intent

What is this?

“Ghost Tool Calls: Issue-Time Privacy for Speculative Agent Tools” is a paper posted to arXiv on 1 June 2026 (2606.02483) by Bardia Mohammadi, Lars Klein, Akhil Arora and Laurent Bindschaedler. It studies a privacy side effect of a performance optimization that is becoming common in agent runtimes: speculative tool execution.

To hide the latency of a tool round-trip, some agent frameworks predict the tool calls the model is likely to make next and dispatch them early, in parallel with reasoning, before the agent has actually committed to that branch. The paper’s observation is simple and uncomfortable: when the agent later abandons the speculative branch, the prediction is discarded — but the network request it triggered is not. The authors call these abandoned-but-already-sent invocations ghost tool calls.

How it works

A speculative dispatch sends real arguments to a real external service. Those arguments encode inferred user intent: which file the agent thought you wanted, which contact it was about to email, which query it was about to run against a third-party API. The destination service receives and logs that request the instant it arrives.

The core finding is that the problem is timing, not authorization. The paper states plainly that “no commit-time cleanup, read-only restriction, or access-control allow-list unsends what an observer already holds.” Once a request reaches an external observer, that observer retains the disclosure regardless of what the agent decides afterwards. Rolling back the branch rolls back the agent’s state, not the third party’s logs.

The authors reframe this by treating observation before commitment as a first-class effect, distinct from state mutation, and propose Speculative Tool Privacy Contracts — a runtime abstraction that governs what a speculative call is allowed to reveal at the moment it is issued. They implement the contracts in a prototype runtime and evaluate twelve policies across three corpora.

The results are the practically useful part. Speculative dispatch measurably increases what an external observer can infer about user intent compared to non-speculative execution. Crucially, the defenses operators usually reach for do not help: post-hoc filters, read-only restrictions, and access-control allow-lists all leave that inference intact, because they act after the bytes are already on the wire. Only issue-time policies — ones that alter or suppress the speculative call’s argument or destination projection before dispatch — actually reduce what the observer learns.

Why it matters

This is a quieter failure mode than prompt injection or tool-misuse, and it does not require an attacker inside your prompt at all. The “observer” can simply be the ordinary third-party service your agent talks to: a search API, a CRM, an email gateway, an MCP tool server. Each speculative branch that never executes still hands that service a snapshot of what your user was probably trying to do.

It maps directly onto OWASP’s LLM02:2025 Sensitive Information Disclosure (unintended exposure of user data through model-driven behavior) and is amplified by LLM06:2025 Excessive Agency — the more tools an agent can speculatively reach, the wider the set of external parties that receive intent leakage. For regulated data, an abandoned speculative query against an external endpoint can be a reportable disclosure even though, from the agent’s point of view, “nothing happened.”

Defenses

The paper’s central lesson is that you cannot fix this after dispatch, so defenses have to move earlier in the pipeline.

• Gate speculation at issue time. Apply the paper’s framing: decide what a speculative call may reveal before it leaves the runtime, not after the branch resolves. Suppress or rewrite the argument and destination projection of low-confidence speculative calls.
• Don’t rely on rollback or allow-lists for privacy. Commit-time cleanup, read-only modes, and access-control allow-lists are valid integrity controls but, per the findings, do nothing to undo a disclosure an external observer already received.
• Restrict speculation to trusted, idempotent, low-sensitivity tools. Local or first-party tools leak to no third party; reserve speculative pre-dispatch for those and disable it for tools that carry user content to external endpoints.
• Minimize what speculative arguments carry. Send placeholders or coarsened arguments speculatively and substitute the real values only on commit, so an abandoned branch reveals little.
• Treat speculative dispatch as a logged, auditable event. Apply least-privilege agency (OWASP LLM06) and record which external parties received speculative calls, so intent leakage is at least observable.

Status

This is published academic research describing a structural privacy weakness in speculative agent execution and a proposed runtime mitigation, not a vulnerability in a specific named product, and no exploit code is involved. Key date: arXiv preprint 2606.02483, version 1, submitted 1 June 2026 (cs.CR / cs.AI / cs.CL). The Speculative Tool Privacy Contracts described are a research prototype; treat the issue-time mitigation principle as the actionable takeaway rather than a shipped library.