Ghost tool calls : l'exécution spéculative des agents fuite l'intention de l'utilisateur

De quoi s’agit-il ?

« Ghost Tool Calls: Issue-Time Privacy for Speculative Agent Tools » est un papier publié sur arXiv le 1ᵉʳ juin 2026 (2606.02483) par Bardia Mohammadi, Lars Klein, Akhil Arora et Laurent Bindschaedler. Il étudie un effet de bord sur la vie privée d’une optimisation de performance qui se généralise dans les runtimes d’agents : l’exécution spéculative des outils.

Pour masquer la latence d’un aller-retour vers un outil, certains frameworks d’agents prédisent les appels d’outils que le modèle est susceptible d’émettre ensuite et les déclenchent par avance, en parallèle du raisonnement, avant que l’agent n’ait réellement validé cette branche. L’observation du papier est simple et dérangeante : lorsque l’agent abandonne ensuite la branche spéculative, la prédiction est jetée — mais pas la requête réseau qu’elle a déclenchée. Les auteurs nomment ces invocations abandonnées-mais-déjà-envoyées des ghost tool calls (appels d’outils fantômes).

Comment ça marche

Un envoi spéculatif transmet de vrais arguments à un vrai service externe. Ces arguments encodent l’intention déduite de l’utilisateur : quel fichier l’agent pensait que vous vouliez, à quel contact il s’apprêtait à écrire, quelle requête il allait lancer contre une API tierce. Le service destinataire reçoit et journalise cette requête à l’instant où elle arrive.

Le résultat central : le problème est le timing, pas l’autorisation. Le papier l’énonce sans détour : « aucun nettoyage au moment du commit, restriction en lecture seule ou allow-list de contrôle d’accès n’annule ce qu’un observateur détient déjà ». Une fois qu’une requête a atteint un observateur externe, celui-ci conserve la divulgation quelles que soient les décisions ultérieures de l’agent. Annuler la branche annule l’état de l’agent, pas les journaux du tiers.

Les auteurs reformulent le problème en traitant l’observation avant validation comme un effet de première classe, distinct de la mutation d’état, et proposent les Speculative Tool Privacy Contracts — une abstraction de runtime qui régit ce qu’un appel spéculatif est autorisé à révéler au moment où il est émis. Ils l’implémentent dans un runtime prototype et évaluent douze politiques sur trois corpus.

Les résultats sont la partie la plus utile en pratique. L’envoi spéculatif augmente mesurablement ce qu’un observateur externe peut déduire de l’intention de l’utilisateur par rapport à une exécution non spéculative. Surtout, les défenses vers lesquelles les opérateurs se tournent d’ordinaire n’aident pas : les filtres a posteriori, les restrictions en lecture seule et les allow-lists de contrôle d’accès laissent cette déduction intacte, car ils agissent après que les octets sont déjà sur le réseau. Seules les politiques au moment de l’émission — celles qui altèrent ou suppriment la projection des arguments ou de la destination de l’appel spéculatif avant l’envoi — réduisent réellement ce que l’observateur apprend.

Pourquoi c’est important

C’est un mode de défaillance plus discret que la prompt injection ou le détournement d’outils, et il ne requiert aucun attaquant dans votre prompt. L’« observateur » peut simplement être le service tiers ordinaire avec lequel votre agent dialogue : une API de recherche, un CRM, une passerelle d’e-mail, un serveur d’outils MCP. Chaque branche spéculative qui ne s’exécute jamais remet tout de même à ce service un instantané de ce que votre utilisateur cherchait probablement à faire.

Cela renvoie directement à LLM02:2025 Sensitive Information Disclosure de l’OWASP (exposition non intentionnelle de données utilisateur via le comportement piloté par le modèle) et se trouve amplifié par LLM06:2025 Excessive Agency — plus un agent peut atteindre d’outils par spéculation, plus large est l’ensemble des parties externes qui reçoivent la fuite d’intention. Pour des données réglementées, une requête spéculative abandonnée vers un endpoint externe peut constituer une divulgation à déclarer, alors même que, du point de vue de l’agent, « rien ne s’est passé ».

Défenses

La leçon centrale du papier : on ne peut pas corriger ce problème après l’envoi, donc les défenses doivent intervenir plus tôt dans le pipeline.

• Contrôler la spéculation au moment de l’émission. Appliquez le cadre du papier : décidez de ce qu’un appel spéculatif peut révéler avant qu’il ne quitte le runtime, pas après la résolution de la branche. Supprimez ou réécrivez la projection des arguments et de la destination des appels spéculatifs à faible confiance.
• Ne comptez pas sur le rollback ou les allow-lists pour la confidentialité. Le nettoyage au commit, les modes lecture seule et les allow-lists de contrôle d’accès sont des contrôles d’intégrité valides mais, selon les résultats, n’annulent en rien une divulgation qu’un observateur externe a déjà reçue.
• Réservez la spéculation aux outils de confiance, idempotents et peu sensibles. Les outils locaux ou de première partie ne fuitent vers aucun tiers ; réservez la pré-émission spéculative à ceux-là et désactivez-la pour les outils qui transportent du contenu utilisateur vers des endpoints externes.
• Minimisez ce que portent les arguments spéculatifs. Envoyez des valeurs de remplacement ou des arguments grossis spéculativement et ne substituez les vraies valeurs qu’au commit, afin qu’une branche abandonnée révèle peu de choses.
• Traitez l’envoi spéculatif comme un événement journalisé et auditable. Appliquez le moindre privilège d’agence (OWASP LLM06) et enregistrez quelles parties externes ont reçu des appels spéculatifs, afin que la fuite d’intention soit au moins observable.

Statut

Il s’agit de recherche académique publiée décrivant une faiblesse structurelle de confidentialité dans l’exécution spéculative des agents et une mitigation de runtime proposée, et non d’une vulnérabilité dans un produit nommé précis ; aucun code d’exploitation n’est en jeu. Date clé : préprint arXiv 2606.02483, version 1, soumis le 1ᵉʳ juin 2026 (cs.CR / cs.AI / cs.CL). Les Speculative Tool Privacy Contracts décrits sont un prototype de recherche ; retenez le principe de mitigation au moment de l’émission comme enseignement actionnable plutôt que comme une bibliothèque livrée.