La vie privée d'un agent est un problème de trajectoire : OCELOT budgétise la fuite par inférence à l'exécution
Un article arXiv daté du 10 juin 2026 redéfinit la vie privée des agents LLM comme un contrôle du risque a posteriori : non plus filtrer chaque sortie, mais budgétiser de combien la croyance d'un adversaire sur un secret peut progresser sur toute une trajectoire.
De quoi s’agit-il ?
Le 10 juin 2026, un article intitulé OCELOT: Inference-Leakage Budgets for Privacy-Preserving LLM Agents (arXiv:2606.12341, cs.CR) avance un argument précis : pourquoi les filtres de confidentialité appliqués à chaque sortie échouent sur des agents qui lisent vos fichiers, appellent des outils et transigent avec des services externes. La thèse : la vie privée d’un agent n’est pas une propriété d’une sortie isolée, mais de la trajectoire entière — et les défenses que la plupart des équipes déploient portent sur la mauvaise unité.
L’article identifie trois propriétés qui rendent le problème difficile. La fuite est cumulative : des divulgations isolément anodines s’additionnent, à travers des destinataires (« puits ») honnêtes-mais-curieux ou complices, en une inférence sur un secret protégé. Elle est bidirectionnelle : une observation malveillante peut injecter des instructions qui retournent le propre modèle de raisonnement de l’agent contre son utilisateur — la triade létale vue côté vie privée. Et elle est dépendante de la tâche : le même champ est nécessaire pour un destinataire et superflu pour un autre.
Comment ça marche
L’idée clé : un filtre qui décide « cette divulgation isolée est-elle acceptable ? » ne peut pas voir l’accumulation. Les filtres d’intégrité contextuelle par sortie comme AirGapAgent (CCS’24), le contrôle de flux d’information classique et les moniteurs de fuite a posteriori couvrent chacun une partie du problème, mais aucun ne maîtrise la fuite cumulative par inférence à l’exécution.
OCELOT reformule le problème en contrôle du risque a posteriori : un médiateur d’exécution budgétise de combien la croyance d’un adversaire sur un secret peut progresser au fil d’une trajectoire, au lieu d’inspecter les sorties une à une.
filtre par sortie : divulgation_i -> "OK isolément ?" -> autoriser (aveugle à l'accumulation)
risque a posteriori : croyance(secret | divulgations_1..i) <= budget -> autoriser la variante la moins divulgante
chaque divulgation impute un coût certifié en min-entropie à un budget pondéré par puits
Son mécanisme, la déclassification vérifiée par témoin (Witness-Verified Declassification), sépare délibérément le jugement de la confiance. Un modèle « défenseur » non fiable, affiné localement, inspecte chaque divulgation candidate et émet des preuves structurées — des atomes étiquetés et des opérateurs de déclassification proposés. Un vérificateur déterministe audite ensuite ces preuves, impute un coût certifié en min-entropie à la variante choisie, et autorise la divulgation utile la moins divulgante sous un budget pondéré par la confiance des puits, consigné dans un registre infalsifiable. Comme le vérificateur est déterministe et que c’est le budget qui est appliqué, un modèle défenseur compromis ou manipulé peut dégrader l’utilité mais ne peut pas dépasser le budget de confidentialité en silence — ce qui rend la conception résistante au cas bidirectionnel où un contenu non fiable tente de subvertir le raisonnement de l’agent.
Les auteurs rapportent que, sur divers bancs d’essai d’agents et face à des défenses récentes, OCELOT obtient moins de fuite pour une utilité supérieure, et résiste à l’injection adaptative, au jailbreak, à l’inférence cumulative et à la collusion de puits, avec un surcoût modéré. (Les chiffres précis figurent dans l’article ; retenez surtout le cadrage comparatif — budget de trajectoire vs filtre par sortie.)
Pourquoi c’est important
C’est un argument d’architecture, pas un bug d’un produit isolé. À mesure que les agents migrent vers des tuyauteries MCP et agent-à-agent, la surface de fuite lente et distribuée s’élargit : un agent peut divulguer un nom à un service, une date à un autre, une localisation à un troisième, rien d’alarmant individuellement, mais conjointement suffisant pour reconstruire un secret. Si votre contrôle est un classifieur par message, vous pouvez passer chaque vérification et fuiter quand même le secret sur la trajectoire. Le risque se concentre là où les agents sont les plus utiles : assistants à mémoire longue durée, flux multi-outils, et fuite de vie privée multi-agents où les sorties circulent entre des modèles que vous ne contrôlez pas pleinement.
Défenses
OCELOT est lui-même la défense ; ce qu’il faut retenir, ce sont les leçons d’ingénierie transposables.
- Budgétisez sur la trajectoire, pas sur le message. Suivez la divulgation cumulative relative à chaque secret protégé et imposez un plafond, plutôt que de noter chaque sortie indépendamment. C’est le seul changement qui ferme le canal de fuite cumulative.
- Séparez le jugement de la confiance. Laissez un modèle (non fiable) proposer ce qui peut être divulgué et un vérificateur déterministe décider et mesurer le coût. Un juge subverti doit pouvoir réduire l’utilité, jamais dépasser le budget en silence.
- Pondérez le budget par la confiance des puits. Un champ envoyé à un service de première partie n’est pas la même divulgation que le même champ envoyé à un tiers inconnu. Faites de la confiance du destinataire un terme explicite, et supposez que les puits peuvent être complices.
- Tenez un registre en ajout-seul des divulgations. Une trace infalsifiable de ce qui a été divulgué, à qui et à quel coût certifié rend la décision d’intégrité contextuelle auditable après coup — et soutient la logique « au plus deux sur trois » d’Agents Rule of Two.
Statut
| Élément | Référence | Date | Notes |
|---|---|---|---|
| OCELOT: Inference-Leakage Budgets for Privacy-Preserving LLM Agents | arXiv:2606.12341 | 2026-06-10 | Médiateur de risque a posteriori à l’exécution ; déclassification vérifiée par témoin ; budget min-entropie sur registre infalsifiable |
| Privacy in Action (PrivacyChecker / PrivacyLens-Live) | arXiv:2509.17488 | 2025-09-22 | Mitigation par sortie fondée sur l’intégrité contextuelle ; évaluation dynamique MCP/A2A (EMNLP 2025 Findings) |
| AirGapAgent | arXiv:2405.05175 | 2024-05-08 | Minimisation par intégrité contextuelle contre le détournement de contexte (CCS’24) |
La leçon n’est pas que les filtres d’intégrité contextuelle sont inutiles — c’est que l’unité d’application est la mauvaise. La vie privée d’un agent se décide sur une trajectoire, et un budget qui mesure l’inférence cumulative est le point de contrôle qu’un filtre par sortie ne pourra jamais être.