Pourquoi la vie privée d'un agent ne se protège pas au niveau de la réponse finale

De quoi s’agit-il ?

Quand un modèle de langage n’était qu’un chatbot, la vie privée avait un seul point d’application : la réponse finale. On filtrait ce que le modèle s’apprêtait à dire, et c’était la surface à défendre. Ce schéma ne décrit plus la façon dont ces systèmes sont déployés. Un agent LLM traduit désormais une requête en interrogation de base de données, récupère des passages dans une collection de documents privés, croise des résultats issus de plusieurs sources, écrit des conclusions intermédiaires en mémoire et agit sur le résultat — souvent avec des permissions déléguées plus larges que ne l’exige la tâche courante.

Un état de l’art publié sur arXiv le 25 juin 2026 par Nada Lahjouji et Ashwin Gerard Colaco (University of California, Irvine) — « Agents That Know Too Much » — pose le constat central avec précision : pour ce que les auteurs appellent un data agent, la vie privée n’est pas une propriété d’une sortie unique. C’est une propriété d’une exécution qui s’étend aux sources de données, aux canaux intermédiaires, à la mémoire et aux actions. Les auteurs passent en revue un champ actif mais dispersé — génération augmentée par récupération (RAG), text-to-SQL, mémoire d’agent, injection de prompt, contrôle d’accès — et le réorganisent autour des données que l’agent manipule plutôt que par type d’attaque.

Comment ça fonctionne

L’idée directrice est qu’un data agent supprime le point d’application unique pour cinq raisons structurelles, chacune ouvrant un canal où des informations sensibles peuvent fuir avant même qu’une réponse soit produite.

D’abord, l’agent touche simultanément de nombreuses sources hétérogènes — bases relationnelles, index vectoriels sur documents privés, fichiers, API externes, et sa propre mémoire — chacune exposant les données différemment. Ensuite, il exécute des workflows multi-étapes où l’information sensible transite par des artefacts intermédiaires : le SQL généré, les lignes récupérées, les arguments passés à un outil, le texte écrit dans un bloc-notes. Chacun peut exposer des données bien avant la réponse visible par l’utilisateur. Troisièmement, il conserve un état persistant : une donnée écrite en mémoire lors d’une session peut resurgir dans une autre — potentiellement pour un autre utilisateur. Quatrièmement, il agit avec une autorité déléguée, détenant fréquemment des permissions plus larges que la requête en cours, de sorte qu’un agent détourné ou compromis peut atteindre bien plus que ce qu’il devrait. Cinquièmement, chaque transformation protectrice se paie en utilité : plus l’agent caviarde ou retient, moins ses réponses sont utiles, et cette tension doit être gérée en continu plutôt que résolue une fois pour toutes.

Deux constats reviennent dans l’état de l’art. Parmi les mécanismes de gouvernance, seul le contrôle de flux d’information (information-flow control) couvre à la fois la fuite compositionnelle (des faits sensibles reconstitués à travers plusieurs étapes anodines) et la fuite par inférence inter-sessions — or ce sont les deux risques les moins protégés dans la littérature actuelle. Et aucun benchmark existant ne fait parcourir à un agent l’ensemble de ses surfaces de données sous une politique de confidentialité unique, ce que les auteurs identifient comme l’instrument dont le champ manque le plus.

Pourquoi c’est important

C’est le même problème structurel que la « lethal trifecta » décrite par Simon Willison côté exfiltration — accès à des données privées, exposition à du contenu non fiable, et capacité à communiquer vers l’extérieur — mais vu depuis la surface de données plutôt que depuis l’attaque. Les agents d’analytique en entreprise sur des entrepôts de données, les assistants cliniques lisant des dossiers patients, les assistants personnels lisant les courriels et fichiers d’un utilisateur partagent tous cette propriété : le canal de fuite est l’exécution, pas la réponse. Une équipe qui ne durcit que le filtre de sortie défend un canal sur cinq.

La réserve honnête : il s’agit d’un état de l’art, pas d’une nouvelle défense ni d’une vulnérabilité mesurée. Sa valeur est la carte : une taxonomie partagée reliant chaque surface à son risque, et un énoncé explicite des zones mal couvertes. Il ne fournit pas de contrôle prêt à déployer, et ses verdicts de « risque le moins protégé » sont des jugements sur l’état de la littérature à la mi-2026, non des chiffres de benchmark.

Défenses

Le point actionnable : traiter chaque surface de données que l’agent touche comme un point d’application, pas seulement la réponse finale. Appliquez le moindre privilège à la frontière outil/données pour que l’agent ne détienne que les permissions nécessaires à la tâche courante, à granularité de tâche plutôt que de session. Isolez la mémoire par utilisateur et par finalité pour qu’un état écrit dans une session ne resurgisse pas dans une autre, et faites-la expirer délibérément. Contraignez et journalisez les canaux intermédiaires — requêtes générées, lignes récupérées, arguments d’outils — car c’est là que s’accumulent les fuites compositionnelles avant qu’un filtre de sortie ne les voie.

Quand c’est possible, préférez le contrôle de flux d’information aux vérifications ponctuelles : le constat récurrent de l’état de l’art est que c’est le seul mécanisme couvrant à la fois la fuite compositionnelle et la fuite inter-sessions, les deux angles morts de la plupart des défenses. Et considérez l’absence de benchmark inter-surfaces comme une lacune de test qui vous incombe : construisez des scénarios de red team qui font parcourir à un agent base de données, récupération, mémoire et messagerie inter-agents sous une politique unique, plutôt que de tester chaque surface isolément.

Statut

Il s’agit d’un état de l’art de recherche, pas d’une vulnérabilité produit avec un identifiant assigné.

Élément	Détail
Source	« Agents That Know Too Much: A Data-Centric Survey of Privacy in LLM Agents » (arXiv:2606.26627)
Affiliation	University of California, Irvine
Publication	25 juin 2026
Type	État de l’art / taxonomie (confidentialité centrée données)
Périmètre	RAG, text-to-SQL, mémoire d’agent, injection de prompt, contrôle d’accès, intégrité contextuelle
Lacunes signalées	Le contrôle de flux d’information est le seul mécanisme couvrant fuite compositionnelle et inter-sessions ; aucun benchmark ne parcourt toutes les surfaces sous une politique unique
Statut	Synthèse de recherche ; aucun contrôle ou exploit isolé

La source principale date des 30 derniers jours. La leçon dépasse l’état de l’art : pour un agent qui lit des données et agit dessus, la vie privée se protège tout au long du chemin d’exécution — la requête, la récupération, la mémoire, la transmission — et non à la phrase qu’il finit par afficher.