Tâche accomplie, vie privée fuitée : les agents sur-partagent entre outils

De quoi s’agit-il ?

ToolPrivacyBench est un benchmark, publié sur arXiv (2606.28061) le 26 juin 2026 par Shijing Hu, Liang Liu, Zhu Meng et Zhicheng Zhao, qui mesure un angle mort de l’évaluation des agents LLM à outils : chaque outil reçoit-il uniquement les données privées dont il a réellement besoin ?

Le manque visé est précis. Les benchmarks classiques de function-calling notent l’accomplissement de la tâche et la correction des appels d’API — l’agent a-t-il appelé les bons outils avec des arguments valides et terminé le travail ? Les benchmarks de vie privée, eux, inspectent en général la réponse finale de l’agent ou lui demandent un jugement de confidentialité. Aucun des deux ne surveille le milieu d’une exécution multi-outils. ToolPrivacyBench fait exactement cela : il audite l’ensemble de la trajectoire exécutée et vérifie si les « atomes privés de la tâche » — des éléments discrets d’information sensible — n’ont circulé que vers les outils et les puits autorisés à les recevoir.

Comment ça marche

Chacun des 2 150 cas du benchmark est associé à une base de connaissances de politique décrivant quelle information a le droit d’atteindre quel outil ou quel puits. Sur ces cas, 1 150 sont des workflows métier sensibles entièrement synthétiques et 1 000 sont adaptés de benchmarks multi-outils et de function-calling existants.

L’évaluation se fait au niveau de la trajectoire, et non de la réponse. L’agent s’exécute contre des back-ends métier fictifs, et le système enregistre deux choses : les arguments réellement passés à chaque appel d’outil et les journaux d’audit des back-ends. Un évaluateur compare ensuite ces flux enregistrés à la base de connaissances de politique du cas. Si un atome privé a atteint un outil qui n’en avait pas besoin, cela est signalé comme sur-divulgation — que la tâche ait réussi ou non. Il s’agit d’un harnais d’évaluation, pas d’une attaque : il inspecte le comportement normal de l’agent au regard d’une politique déclarée, sans aucun payload d’exploitation.

Le cadre que formalisent les auteurs est une frontière de divulgation « besoin d’en connaître » : chaque outil ne doit recevoir que l’information nécessaire à sa finalité déclarée. Un flux d’information lié à sa finalité, autrement dit — la même intuition que l’intégrité contextuelle et le moindre privilège, appliquée aux arguments que l’agent injecte dans ses appels d’outils intermédiaires.

Pourquoi c’est important

Le résultat principal est inconfortable et facile à négliger : sur neuf agents largement utilisés, une exécution d’outil réussie n’impliquait pas une divulgation de vie privée appropriée. Un agent pouvait accomplir correctement la tâche confiée tout en transmettant, en chemin, des informations privées inutiles via des appels d’outils intermédiaires.

Cela découple deux choses que les équipes produit ont tendance à confondre. Un signal vert « tâche réussie » ne dit rien de ce que l’agent a fuité pour arriver à ce résultat. En déploiement réel, ces outils intermédiaires sont souvent des API tierces, des services de journalisation, des back-ends de recherche ou des sous-agents en aval — chacun une partie supplémentaire qui détient désormais des données dont elle n’avait pas besoin. Un agent de support client qui résout un ticket peut avoir poussé une fiche client complète dans un outil de recherche qui ne demandait qu’un numéro de commande.

C’est le cousin discret et non adversarial de l’injection de prompt. Aucun attaquant n’est nécessaire ; le sur-partage est le comportement par défaut de l’agent face à une tâche plausible. C’est important parce que les agents sont de plus en plus branchés sur des chaînes d’outils où chaque saut est un puits potentiel, et parce que la pratique d’évaluation actuelle — optimiser l’accomplissement — récompense activement les agents qui saisissent et transmettent plus de contexte qu’ils ne le devraient. Une étude de juin 2026 sur la vie privée dans les agents LLM et des travaux antérieurs sur les fuites d’orchestration d’outils pointent dans la même direction : c’est la couche d’orchestration, pas seulement la réponse finale, où les données privées s’échappent.

Défenses

ToolPrivacyBench est un outil de mesure, mais son cadre « besoin d’en connaître » se traduit directement en mitigations concrètes pour quiconque déploie des agents à outils :

• Imposer le besoin d’en connaître à la frontière de l’outil. Définissez, par outil, exactement quels champs il peut recevoir, et supprimez ou rejetez tout le reste avant que l’appel ne quitte l’agent. Ne comptez pas sur le modèle pour s’auto-limiter.
• Auditer les trajectoires, pas seulement les réponses. Journalisez et examinez les arguments réels des outils et les accès aux back-ends, puis comparez-les à une politique de divulgation explicite. Une tâche « réussie » peut malgré tout échouer à un audit de vie privée.
• Minimiser le contexte transmis aux outils. Passez des identifiants et des références restreintes plutôt que des fiches complètes ; résolvez les données sensibles le plus tard et le plus étroitement possible.
• Traiter chaque outil et sous-agent comme une partie distincte. Appliquez des contrôles de flux de données entre les sauts comme vous le feriez entre services, y compris les API tierces et les pipelines de journalisation.
• Ajouter la sur-divulgation à l’évaluation avant déploiement. Mesurez la sur-divulgation de vie privée aux côtés de la réussite de la tâche, et relancez-la après tout changement d’outils, de prompts ou de version de modèle.

Statut

Élément	Détail
Artefact	ToolPrivacyBench, arXiv:2606.28061
Publication	26 juin 2026
Type	Benchmark d’évaluation (défensif / mesure)
Portée	Sur-divulgation liée à la finalité dans les agents à outils
Taille	2 150 cas (1 150 workflows synthétiques + 1 000 adaptés)
Agents évalués	Neuf agents largement utilisés
Résultat clé	La réussite de la tâche n’implique pas la divulgation « besoin d’en connaître »

FAQ

Qu’est-ce que ToolPrivacyBench ?

ToolPrivacyBench est un benchmark décrit dans l’article arXiv 2606.28061 (26 juin 2026) qui mesure si les agents LLM à outils sur-partagent des données privées pendant des tâches multi-outils. Il audite l’ensemble de la trajectoire d’exécution pour vérifier que l’information sensible n’atteint que les outils autorisés à la recevoir.

Que signifie « vie privée liée à la finalité » ici ?

Cela signifie que chaque outil ne doit recevoir que l’information nécessaire à sa finalité déclarée — une frontière de divulgation « besoin d’en connaître ». Passer des données privées supplémentaires à un outil qui n’en a pas besoin compte comme une sur-divulgation, même si la tâche globale se termine avec succès.

Pourquoi l’accomplissement de la tâche ne suffit-il pas à juger un agent sûr ?

Parce que accomplissement et divulgation sont indépendants. Le benchmark a constaté que des agents peuvent terminer correctement une tâche tout en faisant circuler des informations privées inutiles via des appels d’outils intermédiaires. Un signal de « réussite » ne dit pas ce que l’agent a fuité vers les outils et puits intermédiaires.

En quoi est-ce différent de l’injection de prompt ?

L’injection de prompt requiert un contenu malveillant pour détourner l’agent. La sur-divulgation ici est non adversariale : c’est le comportement par défaut de l’agent sur une tâche légitime, transmettant discrètement plus de données privées que nécessaire. Aucun attaquant n’est impliqué.

Comment les développeurs peuvent-ils réduire la sur-divulgation ?

Imposez des listes blanches de champs par outil, transmettez des identifiants restreints plutôt que des fiches complètes, auditez les arguments réels des outils au regard d’une politique explicite, et ajoutez la sur-divulgation à l’évaluation avant déploiement plutôt que de ne mesurer que la réussite de la tâche.