Résumé Technique : Appels d'Outils Fantômes : Confidentialité au Moment de l'Émission pour les Outils d'Agents Spéculatifs

1. Énoncé du Problème

Les agents linguistiques augmentés par des outils utilisent de plus en plus l'exécution spéculative pour réduire la latence. Dans ce paradigme, un environnement d'exécution d'agent prédit les appels d'outils probables futurs et les lance en parallèle pendant que le planificateur décide encore de la branche d'exécution à valider. Bien que cela améliore les performances, cela introduit un nouveau mode de défaillance de la confidentialité que les auteurs nomment Appels d'Outils Fantômes (Ghost Tool Calls).

Un appel d'outil fantôme est une invocation spéculative abandonnée qui a été transmise à un observateur externe (par exemple, un fournisseur de recherche, un point de terminaison d'API ou un moniteur réseau) mais qui n'a jamais été promue au plan final, validé, de l'agent. Parce que ces appels sont émis avant que l'agent ne s'engage sur un flux de travail spécifique, ils divulguent l'intention de l'utilisateur inférée (sujets, entités et actions de suivi potentielles) aux services externes.

Le problème central est temporel : une fois qu'un observateur externe reçoit un appel spéculatif, l'information est conservée dans les journaux, les caches ou les traces réseau du fournisseur. Les mécanismes de confidentialité standards échouent car :

• Le nettoyage au moment de la validation (commit-time cleanup) est inefficace ; l'observateur détient déjà les données.
• Les restrictions de lecture seule (par exemple, autoriser la spéculation uniquement pour les outils en lecture seule) n'empêchent pas la fuite d'intention via les arguments ou les points de terminaison de destination.
• Les listes d'autorisation d'accès permettent l'appel si l'outil est autorisé, indépendamment du fait que la branche soit ultérieurement abandonnée.

Les auteurs soutiennent que la confidentialité pour les agents spéculatifs nécessite une décision de politique au moment de l'émission (issue-time), prise avant que l'appel ne quitte la limite de l'environnement de confiance, plutôt qu'une décision au moment de la validation.

2. Méthodologie et Cadre

Le Modèle de Trace

Les auteurs formalisent la faille de confidentialité à l'aide d'un modèle de trace comparant deux séquences :

• Trace Émise ($S$) : Le journal ordonné de tous les événements d'outils transmis, y compris les spéculatifs.
• Trace Validée ($C$) : La sous-séquence ordonnée des événements que l'agent utilise finalement.
• Appels Fantômes : Les événements dans $S \setminus C$.
• Exposition Marginale ($\Delta_i$) : La différence entre ce qu'un observateur $i$ voit dans la trace spéculative ($O_i(S)$) par rapport au contrefactuel composé uniquement de la trace validée ($O_i(C)$). Cela représente l'information supplémentaire divulguée uniquement en raison de la spéculation.

Le modèle identifie trois canaux de divulgation :

1. Arguments : La charge utile littérale (ex: requêtes de recherche).
2. Destination : Le point de terminaison ou la collection accédée (ex: une API de congés RH vs une recherche générale).
3. Métadonnées : Temps, ordre, nombre de tentatives, et états de cache.

Contrats de Confidentialité des Outils Spéculatifs

Pour appliquer la confidentialité à la limite de l'émission, le document propose des Contrats de Confidentialité des Outils Spéculatifs. Il s'agit d'une abstraction d'exécution qui traite "l'observation avant validation" comme un effet de premier rang, distinct d'une mutation d'état.

Composants Clés :

• Étiquettes (Labels) : Chaque événement spéculatif est étiqueté avec le mode d'exécution, la classe d'effet, la classe d'observateur, la sensibilité des arguments, la sensibilité de la destination et la confiance de la branche.
• Le Moniteur : Un composant de confiance situé entre le planificateur et les chemins d'E/S externes. Il évalue chaque événement spéculatif avant la transmission.
• Fonction de Décision : Le moniteur mappe les événements vers l'une des cinq actions :
  1. AUTORISER (ALLOW) : Transmettre sans modification.
  2. RÉÉCRIRE (REWRITE) : Transformer les arguments sensibles en équivalents génériques avant la transmission.
  3. OMBRER (SHADOW) : Exécuter un substitut local de confiance au lieu de l'appel externe ; le résultat est utilisé si la branche est promue, mais l'observateur externe ne voit jamais la requête originale.
  4. DIFFÉRER (DEFER) : Mettre en file d'attente l'événement pour une réévaluation uniquement si la branche est promue au plan validé.
  5. BLOQUER (BLOCK) : Supprimer l'événement entièrement.

Invariante de Correction (Soundness Invariant) : Sous l'hypothèse d'une médiation complète (aucune fuite de données brutes avant le moniteur) et d'un étiquetage correct, le moniteur empêche tout champ interdit d'entrer dans l'exposition marginale ($\Delta_i$) de l'observateur, qu'il soit ultérieurement validé ou abandonné.

3. Contributions Clés

1. Concept d'Appel d'Outil Fantôme : La formalisation des invocations spéculatives abandonnées comme une menace de confidentialité distincte, distinguant la divulgation au moment de l'émission de la mutation d'état au moment de la validation.
2. Contrats de Confidentialité des Outils Spéculatifs : Une abstraction d'exécution avec des étiquettes concrètes, un pipeline de décision à cinq actions et une invariante de correction qui traite l'observation pré-validation comme un effet distinct.
3. Évaluation Empirique : Une évaluation complète de 12 politiques sur trois corpus générés (30 tâches statiques, 150 tâches appariées, et 66 tâches AgentDojo) et une étude sur un fournisseur réel (Brave Search/DuckDuckGo). L'évaluation utilise plusieurs modèles d'adversaires (LLM, correspondance de mots-clés, TF-IDF) pour mesurer la récupération des étiquettes sensibles cachées.

4. Résultats

L'évaluation compare les politiques basées sur la récupération par l'adversaire (la probabilité qu'un adversaire déduise correctement une étiquette sensible à partir de la projection de l'observateur) et le succès des tâches.

• Confirmation de la Fuite : Les traces spéculatives augmentent considérablement la fuite. Dans un benchmark de plan statique, les taux de récupération sont passés de 0,44 (Sans Spéculation) à 0,97 (Spéculation Naïve).
• Inefficacité des Contrôles Post-Hoc : Les politiques qui agissent après la transmission ou qui reposent sur des restrictions de lecture seule échouent à réduire la fuite :
  • Late-Scrub, ACL et SIA (Speculative Interaction Agents) : Ces politiques laissent l'exposition marginale intacte. SIA, qui restreint la spéculation aux outils en lecture seule, est aussi peu performante que la base naïve car les appels en lecture seule révèlent toujours l'intention via les arguments et les destinations.
  • Pre-Scrub : La rédactions de texte libre des arguments avant la transmission est insuffisante si les champs structurés ou les destinations restent inchangés.
• Efficacité des Transformations au Moment de l'Émission : Seules les politiques qui transforment la projection avant la transmission réduisent la fuite :
  • Réécriture (Rewrite) : Le paraphrasage des arguments sensibles en équivalents génériques a réduit la récupération à des niveaux proches du plancher (ex: 0,04 dans les scénarios de planificateur réel).
  • Ombrage (Shadow) : Le routage des appels vers des substituts locaux a réduit la récupération à 0,00 dans plusieurs benchmarks.
  • Porte (Gate) : Le fait de différer les appels à faible confiance jusqu'à la promotion de la branche a réduit la fuite, bien qu'avec un compromis sur l'utilité si le seuil est trop strict.
• Signal Résiduel : Les principaux vecteurs de fuite sont les champs d'arguments structurés et les URL de destination. Masquer les noms d'outils ou utiliser la rédaction de texte libre ne suffit pas à arrêter la fuite si la destination ou les arguments structurés révèlent le sujet.
• Utilité vs Confidentialité : Le succès des tâches est resté élevé pour la plupart des politiques (0,77–0,83). Les méthodes Shadow et Rewrite ont atteint une fuite quasi nulle avec un impact négligeable sur le succès des tâches, tandis que les filtres post-hoc n'ont offert aucun avantage de confidentialité.
• Latence : Le mécanisme d'application du contrat n'est pas devenu un goulot d'étranglement de latence. Dans les charges de travail asynchrones multi-outils, les politiques préservant la confidentialité (Rewrite, Gate) ont maintenu des avantages de latence similaires à la base naïve.

5. Signification et Revendications

Le document affirme que la spéculation crée une défaillance de confidentialité au moment de l'émission qui ne peut être résolue par l'autorisation traditionnelle ou le nettoyage au moment de la validation. La signification de ce travail réside dans :

• Déplacement de la Limite de Confidentialité : Déplacer le point de décision de confidentialité de "quand l'agent valide" à "quand l'agent émet". Les auteurs soutiennent qu'une fois qu'un observateur détient un appel spéculatif, le dommage est fait ; par conséquent, l'environnement d'exécution doit décider de ce qu'il envoie avant de l'envoyer.
• Redéfinition de la Spéculation "Sûre" : Le document démontre que restreindre la spéculation aux outils "en lecture seule" (un modèle de sécurité courant) est insuffisant pour la confidentialité, car les appels en lecture seule révèlent toujours l'intention. Une véritable confidentialité nécessite de transformer ou de supprimer la projection observable.
• Abstraction Pratique : Les contrats proposés fournissent un cadre concret et implémentable (Rewrite, Shadow, Defer) qui permet aux systèmes d'exécution de équilibrer les avantages de latence de la spéculation avec les exigences de confidentialité sans sacrifier l'utilité des tâches.

Les auteurs concluent que, bien que la spéculation soit attractive pour la performance, elle nécessite des politiques au moment de l'émission qui modifient ou suppriment activement la projection des arguments ou de la destination de l'appel spéculatif afin d'empêver la fuite de l'intention de l'utilisateur inférée.