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

Ghost Tool Calls: Protecting User Intent from Speculative Agent Leakage

When AI agents guess what you might need next to save time, they often send "speculative" requests to websites or services. Even if the agent eventually decides not to use those results, the websites have already seen your potential interests. This paper introduces a way to mask or replace these "ghost" requests before they leave the AI's control.

In the push to reduce latency (the delay before a transfer of data begins), modern tool-augmented language agents have moved toward speculative execution. Much like a CPU uses branch prediction to stay busy, an agent runtime predicts likely future tool calls. These might be a web search or an API query (a set of functions used to communicate with software). The agent dispatches them before the central planner has committed to a specific reasoning branch. While this hides network round-trip time, it creates a massive, unmanaged privacy surface.

The Problem

The core issue is a temporal mismatch between observation and commitment. Current safety frameworks focus on state mutation (changes to stored data). They ensure that if a speculative branch is abandoned, any changes to a database are rolled back. However, privacy is about observation. Once a speculative call hits an external provider, that provider has already logged the request. There is no "undo" button for a sent HTTP request.

The authors call these abandoned, externally visible invocations "ghost tool calls." As shown in, a user asking about lease penalties might trigger a legitimate search for tenant law.

The agent might also speculatively trigger searches for "free apartments" or "personal loan rates." Even if the agent never uses those results, the providers now possess a digital biography of the user's inferred intent. Standard mitigations like read-only restrictions or post-hoc scrubbing (cleaning logs after the fact) fail. The disclosure has already occurred at the moment of dispatch.

How It Works

To solve this, the researchers propose Speculative Tool Privacy Contracts. The architectural pivot moves the enforcement boundary from commit-time (when the agent confirms it needs the tool) to issue-time (the moment the request leaves the trusted runtime).

The system relies on a central monitor between the planner and all external IO (input/output) paths. The process follows these logical steps:

1. Labeling: Before any tool call is dispatched, the monitor binds metadata to the event. This includes the execution mode, the sensitivity of the arguments, and the destination label.
2. Policy Evaluation: The monitor evaluates the proposed event against a contract $\kappa$. This contract defines what is permissible for a given observer.
3. Action Selection: Based on the contract, the monitor selects one of five actions:
4. ALLOW: Dispatch the call unchanged.
5. REWRITE: Transform sensitive arguments into generic equivalents (e.g., replacing a specific medical condition with "health inquiry") before the provider sees them.
6. SHADOW: Route the call to a trusted-local substitute instead of an external provider. This ensures no external observer sees the intent.
7. DEFER: Queue the call and wait until the agent officially commits to that branch.
8. BLOCK: Drop the call entirely.

By treating "observation before commitment" as a first-class effect, the runtime ensures that the information leaving the system is already filtered.

Numbers

The authors evaluate twelve different policies using a prototype runtime. The most critical finding is that traditional "safety" measures are ineffective against speculative leakage.

The paper reports that in a "Naive" setting (no policy), adversarial recovery (the ability of an attacker to guess private info) is extremely high. It ranges from 0.489 to 0.97 depending on the corpus. This means an attacker can almost certainly reconstruct the user's intent. Crucially, the authors find that post-hoc filters like Late-Scrub, access control lists (ACL), and even the SIA (Speculative Interaction Agents) baseline cluster with the leaky Naive baseline. As shown in, these policies provide almost zero delta in reducing adversarial recovery.

The only effective mitigations are issue-time transformations. The authors measure that Shadow (routing to local substitutes) achieves near-perfect privacy. It shows 0.000 adversarial recovery. Rewrite (transforming arguments) also performs strongly. It reduces recovery to approximately 0.033–0.044. Regarding performance, implementing these contracts is not a major latency bottleneck. In a multi-tool asynchronous workload, the Contract-async approach stayed within 1.5 percentage points of the Naive-async latency.

What's Missing

While the empirical results are compelling, there are gaps that a production engineer should consider:

• Labeler Reliability: The security model rests on the accuracy of the rule-based labeler. The authors admit their labeler achieved a Macro-F1 (a measure of classification accuracy) of only 0.10 to 0.60 across different channels. If the labeler misclassifies an "intent-revealing" argument as "public," the monitor will ALLOW the leak.
• Model-Provider Trust: The threat model assumes the model-serving layer (the planner) is trusted. In many modern architectures, the planner is a remote API. If the planner itself observes the user, this runtime monitor provides no protection against the model provider.
• Complexity of Substitutes: The Shadow action is highly effective but requires "trusted-local substitutes." Implementing high-fidelity local mocks for complex enterprise APIs is a non-trivial engineering task. This could introduce significant maintenance overhead.

Should You Prototype This

Yes, but only if you are building agentic workflows that interact with third-party APIs.

If your agents are purely internal or operate within a closed ecosystem, the complexity likely outweighs the benefits. However, if you are shipping a consumer-facing agent that speculatively calls web searches or external services, you cannot rely on standard "guardrails." The research shows that once a speculative call is sent, the damage is done.

Start by prototyping the Rewrite action. It offers a strong privacy-to-utility ratio. It is also easier to implement than the full Shadow requirement of maintaining local API substitutes. Code and datasets are reportedly available at https://github.com/mpi-dsg/ghost-tool-calls.