Ghost Tool Calls and the Broker Assumption

A June 1, 2026 paper describes tool calls an agent makes and then abandons, calls that leak user intent to external services regardless of whether the agent ever commits to the action. No access control fixes the leak, because the leak already happened.

On June 1, 2026, a team from EPFL, Bardia Mohammadi, Lars Klein, Akhil Arora, and Laurent Bindschaedler, published Ghost Tool Calls: Issue-Time Privacy for Speculative Agent Tools, identifying a privacy failure mode specific to a performance optimization now common in tool-augmented language agents. To hide latency, agents increasingly issue speculative tool calls, invoking a tool for a branch of reasoning the agent has not yet decided to pursue, on the bet that the result will be useful if that branch is chosen. According to the paper's abstract, those speculative calls leak inferred user intent to external services before the agent commits to the branch, and every external observer that received the call retains the disclosure even after the agent abandons that branch entirely.

The paper's framing of the core problem is precise: timing is the issue, not authorization. No commit-time cleanup, no read-only restriction, and no access-control allow-list can unsend what an observer already holds. The authors term these invocations "ghost tool calls" and propose Speculative Tool Privacy Contracts, a runtime abstraction that treats observation before commitment as a first-class effect distinct from state mutation. In a prototype runtime evaluating twelve policies across three corpora, the researchers found that speculative dispatch increases what an observer can infer about user intent, and that post-hoc filters, read-only restrictions, and access-control allow-lists all leave that inference intact. Only policies that change or suppress the speculative call's argument or destination projection before dispatch, acting at issue time rather than after the fact, actually reduce the leak.

The Assumption the Whole Access Control Literature Shares

Nearly every access control framework proposed for agentic systems, including attribute-based and role-based models built specifically for tool-calling agents, is built on an implicit assumption: the moment that matters is the moment the tool call executes, and if that moment is gated by a correct policy check, the system is secure. Ghost Tool Calls demonstrates that this assumption is wrong for an entire class of agent behavior. A speculative call that is never executed to completion, that the agent abandons before committing, still transmits information to whatever service received it. The tool broker's own bookkeeping, "was this call authorized, did it complete, was its result used", is irrelevant to the privacy question, because the disclosure occurred at issue time, independent of whether the call was ever authorized to complete or ever produced a result the agent used.

This is a structural blind spot in the broker model that underlies most current tool-use architectures: a broker that mediates and logs completed or explicitly denied calls has no visibility into, and no control over, information that left the system at the moment of issuance. The CISA-led Five Eyes advisory on agentic AI frames privilege risk in terms of what an agent is permitted to do, and frames design and configuration risk in terms of when permission is evaluated relative to invocation. Ghost tool calls sit outside both frames: the paper's finding is not about whether the call was permitted, and not about when permission was checked. It is about whether the call was ever committed at all, and demonstrates that the answer to that question does not matter to the privacy outcome.

Why Post-Hoc Controls Cannot Retroactively Work

The paper's most consequential empirical result is negative: none of the standard defensive patterns, filtering after the fact, restricting to read-only operations, or allow-listing permitted destinations, reduce what an external observer can infer, because all three operate on a timeline that assumes the disclosure has not yet happened when the control is applied. A read-only restriction limits what a completed call can do to external state. It does nothing to the information content of a call that was issued and observed regardless of whether it later executed as read-only or was aborted. An allow-list determines which destinations are permitted. It does not un-observe a call an allow-listed destination already received before the agent decided against pursuing that branch.

The paper's proposed alternative, treating observation as a first-class effect that must be controlled at issue time, is a genuinely different engineering discipline than the state-mutation-centric access control that dominates current practice. It requires reasoning about what a speculative call reveals before the call's outcome is known, which is a harder design problem than reasoning about what a completed call did.

A Narrower Version of a Familiar Problem

The gap Ghost Tool Calls identifies is a narrow, precisely specified instance of a broader pattern this arc has tracked: governance mechanisms built around the moment of committed action miss information that leaks at earlier, uncommitted stages of an agent's decision process. Speculative execution optimizations exist because latency matters commercially. The paper does not argue against speculative dispatch. It argues that any privacy or security framework that does not account for issue-time observation is incomplete by construction, regardless of how well it governs committed actions.

Open Questions

• How many production agent deployments currently use speculative tool dispatch without any issue-time privacy control, given that the optimization predates this paper's naming of the risk?
• What would it take for tool providers, who are the external observers receiving speculative calls, to voluntarily discard information from calls the agent later abandons, given that the paper notes no technical mechanism forces this?
• Does Speculative Tool Privacy Contracts require cooperation from the tool provider's side of the interface, or can it be enforced entirely from the agent's side?
• How does an enterprise audit whether its own tool-use agents are issuing ghost tool calls that leak intent, given that the leak by definition occurs before any completed-call log entry is written?
• At what point does the industry's default optimization for latency need to be re-evaluated against the privacy cost this paper quantifies, without prescribing which side of that trade a given deployment should take?
• If issue-time policies are the only defense shown to work, what governance body or standard would define which argument and destination projections are safe to suppress before dispatch, and who verifies that suppression was applied correctly?

The governance artifact is retained. The governance function is not.