Les agents collectent plus qu'ils ne révèlent : auditer la vie privée au stade de l'acquisition
Un benchmark de juin 2026 inspecte le moment où les données sensibles entrent dans le contexte de l'agent, pas seulement ce qu'il divulgue ensuite — et la sur-collecte est répandue.
De quoi s’agit-il ?
La plupart des évaluations de vie privée pour les agents LLM posent une seule question : les données sensibles ont-elles quitté le système ? Elles inspectent la réponse finale ou les actions sortantes et vérifient si un numéro de téléphone, un détail médical ou le salaire d’un collègue s’est retrouvé dans la sortie. Un benchmark publié sur arXiv en juin 2026, PrivacyPeek: Auditing What LLM-Based Agents Acquire, Not Just What They Say (arXiv:2606.00152), soutient que cela passe à côté d’une défaillance plus précoce et plus lourde de conséquences. Avant de pouvoir divulguer quoi que ce soit, un agent doit d’abord acquérir la donnée — la faire entrer dans son contexte via un appel d’outil, une étape de récupération ou une requête en base. Le papier recentre la question sur ce moment de collecte : non pas « cette donnée aurait-elle dû sortir ? » mais « l’agent aurait-il dû la collecter tout court ? »
Ce cadrage compte, car c’est au stade de l’acquisition que vit réellement le principe de minimisation des données. Un agent qui lit discrètement tout votre agenda pour répondre à une question sur la réunion de demain a déjà violé le moindre privilège, même s’il ne vous répète jamais un seul événement sans rapport.
Comment ça marche
PrivacyPeek sépare deux choses que la plupart des benchmarks confondent. La première est la Probe Elicitation — le test familier consistant à voir si l’on peut amener l’agent à dire quelque chose de sensible. La seconde, et c’est la contribution du papier, est l’Acquisition Inspection : la lecture de la trajectoire d’appels d’outils de l’agent pour détecter le moment où il est allé chercher des données hors du périmètre de la tâche confiée.
Concrètement, le benchmark fournit une tâche, un environnement doté d’outils et une définition des données que la tâche requiert légitimement. Pendant l’exécution de l’agent, sa séquence d’appels d’outils est enregistrée et confrontée à ce périmètre. Si la tâche est « trouver un restaurant près du bureau pour jeudi » et que la trajectoire inclut un appel récupérant les moyens de paiement enregistrés ou des contacts sans rapport, c’est signalé comme sur-acquisition — que cela apparaisse ou non dans la réponse. Les auteurs ont construit le jeu de cas via un pipeline avec supervision humaine, produisant 1 182 cas couvrant 7 comportements d’acquisition et 16 domaines applicatifs, exécutés contre 10 agents issus de 4 familles de modèles.
Le résultat principal : la collecte inutile d’informations sensibles est répandue parmi les agents testés — un schéma invisible pour toute évaluation qui ne lit que la sortie finale. Cela rejoint un panorama publié le même mois, Agents That Know Too Much: A Data-Centric Survey of Privacy in LLM Agents (arXiv:2606.26627), et prolonge la grille d’intégrité contextuelle de travaux antérieurs comme Beyond Jailbreaking: Auditing Contextual Privacy in LLM Agents (arXiv:2506.10171), en passant de ce que les agents divulguent à ce qu’ils touchent.
Pourquoi c’est important
L’écart est architectural, pas cosmétique. Un test de vie privée centré sur la sortie peut certifier un agent comme « sûr » alors qu’il aspire régulièrement des données qu’il n’a aucune raison de lire. Cette exposition est réelle même sans fuite : les données acquises séjournent dans la fenêtre de contexte, où une injection de prompt en aval peut les exfiltrer ; elles atterrissent dans les journaux et traces conservés par la plateforme ; et elles élargissent le rayon d’impact de toute compromission ultérieure. Un agent branché sur des outils larges — e-mail, fichiers, agendas, CRM — avec une propension à sur-collecter est un passif permanent, car le matériau sensible est déjà à l’intérieur du périmètre avant même qu’un attaquant n’apparaisse.
Cela casse aussi une hypothèse de conformité courante. Les obligations de minimisation, sous des régimes comme le RGPD, portent sur la collecte et le traitement, pas seulement la divulgation. Un agent qui lit bien plus que ce qu’une tâche exige constitue un problème de minimisation en soi, qu’un audit purement centré sur la sortie ne fera jamais remonter.
Défenses
Traitez l’acquisition comme un point de contrôle de premier rang, plutôt que de supposer qu’une réponse propre signifie un comportement propre.
Auditez la trajectoire, pas seulement la sortie. Journalisez chaque appel d’outil et chaque récupération, et évaluez-les au regard des données réellement nécessaires à la tâche — c’est exactement ce que formalise l’Acquisition Inspection. Une suite de tests qui ne lit que les réponses finales laissera passer les agents qui sur-collectent.
Cadrez les outils sur la tâche. Préférez des outils étroits et à finalité définie (« obtenir les événements de l’agenda de jeudi ») plutôt que larges (« lire toutes les données de l’agenda »), afin que l’agent ne puisse physiquement pas acquérir au-delà du périmètre. Liez la disponibilité des outils à la tâche courante plutôt que d’accorder l’ensemble par défaut.
Imposez la minimisation à la frontière. Placez une couche de politique entre l’agent et ses sources de données, capable de refuser ou de restreindre une requête dont le périmètre excède la tâche, au lieu de compter sur la retenue du modèle.
Minimisez la rétention de ce qui est acquis. Supprimez les champs sensibles du contexte, des journaux et des traces dès qu’ils ne sont plus nécessaires, pour que la sur-collecte ne devienne pas silencieusement une exposition durable.
Testez avec des benchmarks conscients de l’acquisition. Adoptez des évaluations qui séparent ce que l’agent dit de ce qu’il collecte ; les deux modes de défaillance appellent des correctifs différents, et un seul apparaît dans la transcription.
Statut
| Aspect | Détail |
|---|---|
| Source | PrivacyPeek (arXiv:2606.00152), publié en juin 2026 |
| Classe | Fuite au stade de l’acquisition — sur-collecte de données sensibles dans le contexte de l’agent |
| Méthode | Double évaluation : Acquisition Inspection (audit de trajectoire d’outils) + Probe Elicitation |
| Périmètre | 1 182 cas, 7 comportements d’acquisition, 16 domaines applicatifs |
| Testé | 10 agents LLM issus de 4 familles de modèles |
| Constat | La collecte inutile d’informations sensibles est répandue |
| Nature | Benchmark de recherche / mesure — pas de CVE, pas d’exploit actif |