Une prépublication publiée le 20 août 2026 indique que de grands modèles de langage peuvent révéler des secrets présents dans leur contexte par des réponses apparemment anodines, même lorsqu'ils refusent une demande directe visant ces secrets. Les auteurs parlent de fuite involontaire du contexte. Leur conclusion n'est pas que chaque modèle ou agent divulgue chaque secret. Elle est que les mécanismes de refus peuvent ne pas suffire à empêcher un contexte caché d'influencer des réponses ultérieures.
Ce résultat concerne les organisations qui placent des identifiants, des données personnelles, des dossiers, des documents récupérés ou une mémoire persistante dans le contexte de travail d'un agent. Si un modèle encode une information relative à ce contexte dans un texte banal, un attaquant peut ne pas avoir besoin d'une injection de prompt classique ni d'une divulgation littérale. Des observations répétées pourraient suffire pour déduire un fait protégé.
Ce que l'étude sur les fuites de contexte des LLM a testé
L'article Inadvertent Context Leakage in Language Models est une prépublication arXiv en version un, signée par Jaiden Fairoze, Neal Mangaokar, Kamalika Chaudhuri, Sanjam Garg et Saeed Mahloujifar. Les chercheurs ont conduit des expériences en boîte noire sur huit modèles propriétaires. Ils ont placé un secret dans le contexte du modèle, posé des questions sans rapport et vérifié si des motifs statistiques dans les réponses anodines permettaient de retrouver le secret.
Dans des expériences contrôlées portant sur des chiffres, les auteurs rapportent une récupération presque parfaite des secrets à deux chiffres et un taux de correspondance exacte de 82 pour cent pour les secrets à quatre chiffres. Ils affirment aussi qu'un classificateur a pu déduire des propriétés sémantiques d'informations cachées à partir de sorties qui ne les répétaient pas explicitement. Dans une expérience distincte d'apprentissage par renforcement, un adversaire a reconstruit des numéros de sécurité sociale américains complets dans ce que l'article décrit comme un environnement d'agent proche de la production.
Ces chiffres sont les résultats annoncés par les auteurs. Ils n'établissent pas un taux général de fuite pour les agents en production et ne doivent pas être transposés à un autre modèle, prompt, flux de travail ou type de données sans test. L'article indique aussi que des modèles plus performants ont parfois davantage divulgué dans son protocole, ce qui remet en cause l'idée qu'un meilleur raisonnement améliore automatiquement la confidentialité.
Pourquoi des sorties anodines modifient le modèle de sécurité des agents
De nombreux contrôles se concentrent sur des événements manifestement dangereux: une réponse interdite, un appel d'outil malveillant ou un prompt qui contourne des instructions. Une fuite de contexte est plus discrète. Une sortie autorisée peut néanmoins être corrélée avec un contexte protégé. Une série de réponses apparemment peu risquées peut donc devenir un canal d'information.
Le risque est particulièrement important lorsqu'un agent combine les demandes de l'utilisateur avec des instructions système, des documents récupérés, une mémoire, des résultats d'outils et des éléments d'authentification. Les recommandations de l'OWASP sur la divulgation d'informations sensibles identifient les prompts système, fichiers, résultats d'outils, données métier et données personnelles comme des éléments susceptibles d'être exposés par une application LLM. L'OWASP ne valide pas indépendamment les résultats du nouvel article, mais son modèle de risque confirme que le contexte actif constitue une surface de données sensibles.
Les organisations devraient donc traiter la construction du contexte comme une frontière de sécurité. Le guide Maetra sur les contrôles contre l'injection de prompt pour les agents IA explique comment articuler isolation des entrées, autorisation des outils et contrôle des sorties. La fuite de contexte fournit une raison supplémentaire de réduire les données avant toute génération.
Une réponse pratique pour les responsables d'agents
Les équipes de sécurité, de protection des données et de plateforme IA peuvent appliquer sept contrôles:
- Réduire le contexte actif. N'envoyer que les champs nécessaires à la décision en cours. Les identifiants réutilisables, dossiers d'identité complets et collections de documents sans restriction ne doivent pas entrer dans un contexte généraliste.
- Séparer les zones de confiance. Isoler les données de différents utilisateurs, dossiers, locataires et niveaux de privilège dans des mémoires et systèmes de recherche distincts. Autoriser avant la récupération, et non seulement après la génération.
- Tokeniser les valeurs sensibles. Remplacer les secrets et identifiants directs par des références éphémères lorsque le modèle n'a pas besoin de la valeur réelle. Résoudre la référence uniquement dans un outil contrôlé.
- Limiter les sorties et les répétitions. Réduire les réponses libres inutiles, limiter les séries de sondage et surveiller les questions anodines répétées qui pourraient faciliter une inférence statistique.
- Tester l'extraction indirecte. Ajouter des valeurs témoins et des tentatives d'inférence sur plusieurs tours aux évaluations offensives. Le test doit chercher des corrélations entre sorties, pas uniquement la répétition d'un secret.
- Isoler les outils à fort impact. Fournir aux agents des identifiants éphémères et de moindre privilège par un courtier. Exiger une autorisation déterministe et un contrôle humain pour les actions externes importantes.
- Conserver des preuves utiles. Consigner la version du modèle et de la politique, les sources du contexte, le résultat d'autorisation, les appels d'outils, les occultations, la décision du contrôleur et la réponse à l'incident sans conserver inutilement le secret.
La preuve doit permettre d'expliquer pourquoi une donnée est entrée dans le contexte et quel contrôle l'a autorisée. Le guide Maetra des journaux d'audit IA décrit un dossier minimal pour des décisions d'agent traçables.
Limites et décision à prendre maintenant
Il s'agit d'une recherche préliminaire, et non d'une mesure évaluée par les pairs de tous les systèmes déployés. La prépublication étudie certains modèles propriétaires dans des conditions contrôlées, tandis que les modèles commerciaux peuvent changer. Les exercices sur les chiffres ne prouvent pas qu'un secret de production quelconque est récupérable au même taux. L'expérience proche de la production est une preuve issue du protocole des auteurs, pas une violation réelle divulguée.
La conclusion prudente est plus étroite: réussir un test de refus ne suffit pas à démontrer qu'un contexte confidentiel ne peut pas influencer des sorties autorisées. Les responsables doivent identifier les flux qui placent des données à fort impact dans le contexte, les réduire avant la génération et inclure les fuites sur plusieurs tours dans l'autorisation de mise en production.
Analyse Maetra: la minimisation du contexte, la séparation des privilèges et la collecte de preuves devraient être des critères de lancement pour tout agent traitant des données réglementées ou confidentielles. Les équipes peuvent utiliser Maetra Secure pour relier ces contrôles aux risques d'exposition et aux responsables désignés.