Technical Summary: Ghost Tool Calls: Issue-Time Privacy for Speculative Agent Tools

1. Problem Statement

Tool-augmented language agents increasingly employ speculative execution to reduce latency. In this paradigm, an agent runtime predicts likely future tool calls and dispatches them in parallel while the planner is still deciding which branch of execution to commit to. While this improves performance, it introduces a novel privacy failure mode the authors term Ghost Tool Calls.

A ghost tool call is an abandoned speculative invocation that was dispatched to an external observer (e.g., a search provider, API endpoint, or network monitor) but was never promoted to the agent's final, committed plan. Because these calls are issued before the agent commits to a specific workflow, they leak inferred user intent (topics, entities, and potential follow-up actions) to external services.

The core issue is temporal: once an external observer receives a speculative call, the information is retained in provider logs, caches, or network traces. Standard privacy mechanisms fail to address this because:

• Commit-time cleanup is ineffective; the observer already holds the data.
• Read-only restrictions (e.g., allowing speculation only for read-only tools) do not prevent the leakage of intent via arguments or destination endpoints.
• Access-control allow-lists permit the call if the tool is authorized, regardless of whether the branch is later abandoned.

The authors argue that privacy for speculative agents requires an issue-time policy decision, made before the call leaves the trusted runtime boundary, rather than a commit-time decision.

2. Methodology and Framework

The Trace Model

The authors formalize the privacy gap using a trace model comparing two sequences:

• Issued Trace ($S$): The ordered log of all dispatched tool events, including speculative ones.
• Committed Trace ($C$): The ordered subsequence of events the agent ultimately uses.
• Ghost Calls: Events in $S \setminus C$.
• Marginal Exposure ($\Delta_i$): The difference between what an observer $i$ sees in the speculative trace ($O_i(S)$) versus the committed-only counterfactual ($O_i(C)$). This represents the additional information leaked solely due to speculation.

The model identifies three disclosure channels:

1. Arguments: The literal payload (e.g., search queries).
2. Destination: The endpoint or collection accessed (e.g., an HR-leave API vs. a general search).
3. Metadata: Timing, order, retry counts, and cache states.

Speculative Tool Privacy Contracts

To enforce privacy at the issue-time boundary, the paper proposes Speculative Tool Privacy Contracts. This is a runtime abstraction that treats "observation before commitment" as a first-class effect, distinct from state mutation.

Key Components:

• Labels: Each speculative event is labeled with execution mode, effect class, observer class, argument sensitivity, destination sensitivity, and branch confidence.
• The Monitor: A trusted component sitting between the planner and external I/O paths. It evaluates every speculative event before dispatch.
• Decision Function: The monitor maps events to one of five actions:
  1. ALLOW: Dispatch unchanged.
  2. REWRITE: Transform sensitive arguments into generic equivalents before dispatch.
  3. SHADOW: Execute a trusted local substitute instead of the external call; the result is used if the branch is promoted, but the external observer never sees the original request.
  4. DEFER: Queue the event for re-evaluation only if the branch is promoted to the committed plan.
  5. BLOCK: Drop the event entirely.

Soundness Invariant: Under the assumption of complete mediation (no raw data leaks before the monitor) and correct labeling, the monitor prevents any forbidden field from entering the observer's marginal exposure ($\Delta_i$), regardless of whether the event is later committed or abandoned.

3. Key Contributions

1. Ghost Tool Call Concept: The formalization of abandoned speculative invocations as a distinct privacy threat, distinguishing between issue-time disclosure and commit-time state mutation.
2. Speculative Tool Privacy Contracts: A runtime abstraction with concrete labels, a five-action decision pipeline, and a soundness invariant that treats pre-commit observation as a distinct effect.
3. Empirical Evaluation: A comprehensive evaluation of 12 policies across three generated corpora (30-task static, 150-task paired, and 66-task AgentDojo) and a real-provider study (Brave Search/DuckDuckGo). The evaluation uses multiple adversary models (LLMs, keyword matching, TF-IDF) to measure the recovery of hidden sensitive labels.

4. Results

The evaluation compares policies based on adversarial recovery (the probability an adversary correctly infers a sensitive label from the observer's projection) and task success.

• Leakage Confirmation: Speculative traces significantly increase leakage. In a static-plan benchmark, recovery rates jumped from 0.44 (No-Speculation) to 0.97 (Naive speculation).
• Ineffectiveness of Post-Hoc Controls: Policies that act after dispatch or rely on read-only restrictions fail to reduce leakage:
  • Late-Scrub, ACL, and SIA (Speculative Interaction Agents): These policies leave the marginal exposure intact. SIA, which restricts speculation to read-only tools, performs as poorly as the Naive baseline because read-only calls still reveal intent via arguments and destinations.
  • Pre-Scrub: Free-text redaction of arguments before dispatch is insufficient if structured fields or destinations remain untouched.
• Effectiveness of Issue-Time Transforms: Only policies that transform the projection before dispatch reduce leakage:
  • Rewrite: Paraphrasing sensitive arguments into generic equivalents reduced recovery to near-floor levels (e.g., 0.04 in real-planner scenarios).
  • Shadow: Routing calls to local substitutes reduced recovery to 0.00 in several benchmarks.
  • Gate: Deferring low-confidence calls until branch promotion reduced leakage, though with a trade-off in utility if the threshold is too strict.
• Residual Signal: The primary carriers of leakage are structured argument fields and destination URLs. Masking tool names or using free-text redaction alone does not stop leakage if the destination or structured arguments reveal the topic.
• Utility vs. Privacy: Task success remained high across most policies (0.77–0.83). Shadow and Rewrite achieved near-zero leakage with negligible impact on task success, whereas post-hoc filters offered no privacy benefit.
• Latency: The contract enforcement mechanism did not become a latency bottleneck. In multi-tool async workloads, privacy-preserving policies (Rewrite, Gate) maintained latency advantages similar to the Naive baseline.

5. Significance and Claims

The paper claims that speculation creates an issue-time privacy failure that cannot be solved by traditional authorization or commit-time cleanup. The significance of the work lies in:

• Shifting the Privacy Boundary: Moving the privacy decision point from "when the agent commits" to "when the agent issues." The authors argue that once an observer holds a speculative call, the damage is done; therefore, the runtime must decide what to send before sending it.
• Redefining "Safe" Speculation: The paper demonstrates that restricting speculation to "read-only" tools (a common safety pattern) is insufficient for privacy, as read-only calls still leak intent. True privacy requires transforming or suppressing the observable projection.
• Practical Abstraction: The proposed contracts provide a concrete, implementable framework (Rewrite, Shadow, Deferr) that allows runtime systems to balance the latency benefits of speculation with privacy requirements without sacrificing task utility.

The authors conclude that while speculation is attractive for performance, it requires issue-time policies that actively change or suppress the speculative call's argument or destination projection to prevent the leakage of inferred user intent.