Attaques par inférence de contexte : fuiter sans jailbreak
Un article d'août 2026 formalise les attaques par inférence de contexte : un agent laisse fuiter des signaux exploitables sur les documents qu'il a chargés, sans jamais les divulguer.
De quoi s’agit-il ?
La recherche sur la vie privée des systèmes LLM a surtout mesuré une chose : un attaquant peut-il faire dire le secret au modèle ? Extraction par jailbreak, vidage du system prompt, régurgitation verbatim. Un article soumis à arXiv le 31 août 2026, Context Inference Attacks Without Jailbreaks (arXiv:2609.01663), signé Prince Jha, Samuele Poppi et Nils Lukas, soutient que ce cadrage passe complètement à côté du cas agentique.
Dans un déploiement agentique, la matière sensible — dossiers de santé, documents financiers, tickets internes — n’est pas collée par l’utilisateur. Elle est assemblée dans un contexte caché par les propres appels d’outils de l’agent, qui répond ensuite à des questions ordinaires et anodines par-dessus. Les auteurs formalisent les attaques par inférence de contexte : un attaquant qui n’obtient jamais la moindre divulgation peut tout de même déterminer quels documents ont été chargés, à partir des seules réponses normales de l’agent.
Comment ça marche
L’article pose le problème comme un jeu de sécurité. L’attaquant soumet des requêtes anodines, observe les réponses et note des contextes candidats — l’objectif est d’identifier le vrai parmi un ensemble de candidats, pas de faire réciter le modèle. Rien dans l’interaction ne ressemble à une attaque : pas de suffixe adverse, pas de jeu de rôle, pas de refus à contourner.
Trois configurations sont évaluées, à connaissance décroissante de l’attaquant et à livraison du contexte de plus en plus indirecte :
- Contexte connu — l’attaquant connaît les documents candidats.
- Contexte inconnu — le template de prompt et les documents environnants sont inconnus.
- Contexte récupéré par l’agent — les documents arrivent via les propres appels de récupération de l’agent, sans que l’attaquant ne touche au chemin de chargement.
Les auteurs distinguent également un réglage grey-box, où le modèle cible sert lui-même à scorer les observations, d’un réglage black-box, où l’attaquant score avec un modèle de substitution qu’il contrôle. La même attaque traverse les trois configurations sans modification.
Les chiffres rapportés, face à des taux de hasard de 1/|candidats| et 50 AUROC respectivement : 100 % de succès sur de petits ensembles de candidats et 63 % à 1 024 candidats avec un contexte connu ; 78,9 AUROC lorsque le template et les documents environnants sont inconnus ; 92,5 AUROC lorsqu’un modèle de substitution de 14 milliards de paramètres score une cible de 32 milliards ; 81,8 AUROC lorsque les documents arrivent par les retours de récupération de l’agent. La fuite est caractérisée en fonction du budget de requêtes, de la taille du contexte et de la taille du modèle cible.
Pourquoi c’est important
Le point inconfortable, c’est l’ensemble des contrôles testés. Les auteurs indiquent que les agents évalués sont restés vulnérables malgré les mitigations opposées : une instruction de ne pas divulguer le contexte, la suppression de logits et la dilution du contexte. Ces trois mesures sont, en pratique, ce sur quoi repose une large part des déploiements en production — une clause ferme dans le system prompt, un filtre en sortie, et beaucoup de texte autour.
Aucune ne traite la fuite réelle, parce que celle-ci ne se trouve pas dans le texte de sortie. Elle se trouve dans la distribution des sorties anodines conditionnée par le contexte. Un agent de navigation web qui répond à une question inoffensive porte toujours un signal exploitable sur ce qui a été chargé silencieusement. Or l’appartenance d’un document — « ce dossier patient était-il dans le périmètre ? » — constitue souvent à elle seule le fait sensible, indépendamment du contenu.
Une étude contrôlée distincte, publiée le 1er septembre 2026 (arXiv:2609.01693), converge sur le sujet des étiquettes de sensibilité placées dans le contexte. Sur 480 essais dans une configuration MCP-vers-A2A unique, un en-tête PUBLIC - OK TO SHARE était descriptivement associé à davantage de fuite verbatim de champs qu’une absence d’en-tête, avec une forte dépendance au modèle ; le contraste entre « confidentiel » et « non étiqueté » restait limité par un effet plancher et non concluant. L’auteur précise explicitement qu’il s’agit d’une association dans une configuration, et non d’un effet causal ou général — mais c’est une raison de plus de ne pas traiter une étiquette de sensibilité placée dans le contexte comme un mécanisme d’application.
Défenses
L’apport de l’article sur ce terrain est négatif — il montre quels contrôles n’ont pas tenu. Les recommandations ci-dessous découlent donc du modèle de menace, et non de mitigations mesurées.
Cessez de compter le secret au niveau du prompt comme un contrôle. « Ne révèle pas le contexte » est une instruction adressée à un composant qui fuit par sa distribution de sortie, pas une frontière. Traitez-la comme de l’hygiène, jamais comme la raison pour laquelle une évaluation est validée.
Faites du périmètre de récupération une décision d’autorisation, pas un détail de prompt. Si un document ne doit pas être inférable par un appelant donné, il ne doit pas entrer dans le contexte de cet appelant. Filtrez au niveau de la récupération et des permissions d’outils, par identité du demandeur, avant l’assemblage.
Plafonnez et surveillez les requêtes par session. La fuite croît avec le budget de requêtes. Limites de débit, plafonds de session et détection d’anomalies sur des requêtes répétitives et quasi identiques renchérissent nettement le jeu de distinction.
Supposez un scoring par modèle de substitution. Black-box ne veut pas dire sûr : un petit modèle open-weight a scoré une cible plus grande à 92,5 AUROC. Contrôler l’accès aux logits ou au modèle cible ne suffit pas.
Caviardez et généralisez au moment de l’assemblage. Lorsque l’appartenance elle-même est sensible, préférez des représentations agrégées, regroupées ou synthétisées aux documents verbatim dans la fenêtre de contexte.
Traitez les étiquettes du contexte comme des métadonnées, pas comme une politique. Appliquez les décisions de partage dans la couche outils et transport entre agents, pas via un en-tête que l’on demande au modèle de respecter.
Statut
| Aspect | Détail |
|---|---|
| Source principale | Context Inference Attacks Without Jailbreaks (arXiv:2609.01663), soumis le 31 août 2026 |
| Classe | Attaque par inférence / vie privée sur le contexte caché d’un agent — sans jailbreak ni divulgation |
| Contrôles jugés inefficaces | Instruction de non-divulgation, suppression de logits, dilution du contexte |
| Résultats clés | 100 % de succès sur petits ensembles ; 63 % à 1 024 candidats ; 78,9 AUROC contexte inconnu ; 92,5 AUROC substitution 14B contre cible 32B ; 81,8 AUROC contexte récupéré par l’agent |
| Travaux convergents | Étude sur la fuite verbatim de champs en MCP-vers-A2A (arXiv:2609.01693), 1er septembre 2026 |
| Nature | Résultat de recherche — pas de CVE ni d’advisory éditeur ; concerne les architectures agentiques en général, pas un produit |