💬 NLP

SlotGuard: Stop Oversharing Private Local Context in LLM Agent Transcri

SlotGuard est un système de délimitation de transcription local qui empêche de manière sécurisée les agents LLM de divulguer du contexte privé et des identifiants en réécrivant les données sensibles en créneaux synthétiques à conservation de format liés via un graphe de session, atteignant ainsi une absence totale de fuite d'identifiants et un succès de tâche quasi parfait sans la fragilité des méthodes de rédaction existantes.

Auteurs originaux : Haocheng Xia, Yongjoo Park

Publié 2026-07-21

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Haocheng Xia, Yongjoo Park

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous possédez un assistant robotique super intelligent capable de presque tout faire pour vous : il peut lire des fichiers sur votre ordinateur, envoyer des e-mails, exécuter du code et même communiquer avec d'autres logiciels. Pour accomplir ces tâches, le robot doit accéder à vos informations privées, comme vos chemins de fichiers, votre adresse e-mail et même vos mots de passe secrets. Mais voici le hic : pour déterminer ce qu'il doit faire ensuite, le robot doit souvent envoyer un résumé de son travail à un « cerveau » géant basé dans le cloud (un grand modèle de langage) appartenant à une entreprise technologique. Ce résumé est appelé un « transcript ».

Le problème est que ce transcript est comme une entrée de journal intime envoyée à un étranger. Si le robot écrit accidentellement votre mot de passe secret ou votre adresse personnelle dans ce journal, l'entreprise de cloud pourrait les voir, les stocker ou même les utiliser pour entraîner ses futurs robots. C'est comme demander à un ami de vous aider à faire un gâteau, mais vous devez lui envoyer une photo de votre cuisine, et sur cette photo, votre clé de maison est posée juste à côté de la farine. Vous voulez que votre ami voie la cuisine pour qu'il puisse vous dire comment mélanger la pâte, mais vous ne voulez absolument pas qu'il voie votre clé. Ce document traite de la question délicate de savoir comment permettre au robot de voir votre monde privé sans laisser le cerveau dans le cloud jeter un coup d'œil à vos secrets.

Entrez SlotGuard, un nouveau système ingénieux conçu pour agir comme un « videur de confidentialité » directement à l'intérieur de votre ordinateur. Voyez SlotGuard comme un traducteur magique qui se tient entre votre assistant robot et le cerveau dans le cloud. Son rôle est de réécrire le journal du robot avant qu'il ne quitte votre maison. Au lieu de laisser le robot écrire votre véritable mot de passe secret (comme SuperSecret123!), SlotGuard le remplace par un espace réservé fictif, mais parfaitement structuré (comme 🔑-SYNTHETIC-KEY-99).

Voici le tour de magie : l'espace réservé fictif ressemble et se comporte exactement comme le vrai pour le cerveau dans le cloud. Si le vrai mot de passe était une longue chaîne de lettres et de chiffres, le faux est aussi une longue chaîne de lettres et de chiffres. Si le vrai chemin de fichier était /Users/Alice/Secrets/Plan.pdf, le faux pourrait ressembler à [REPO_ROOT_1]/Secrets/Plan.pdf. Le cerveau dans le cloud peut toujours lire la structure — il sait qu'il s'agit d'un fichier, il sait que c'est un secret, et il sait comment en parler — mais il n'a aucune idée de quel est le véritable secret. C'est comme donner au cerveau dans le cloud une carte où le trésor est marqué d'un « X » générique au lieu des coordonnées réelles.

Mais la magie ne s'arrête pas là. Lorsque le cerveau dans le cloud renvoie des instructions telles que « Allez ouvrir ce fichier », SlotGuard intercepte le message avant qu'il n'atteigne votre robot. Il vérifie sa propre liste secrète, voit que [REPO_ROOT_1] signifie en réalité /Users/Alice/Secrets/Plan.pdf, et remplace le faux par le vrai uniquement à l'intérieur de votre ordinateur de confiance. Le robot ouvre alors le vrai fichier, et le cerveau dans le cloud n'a jamais su que le vrai nom existait.

Les chercheurs ont testé ce système avec des devoirs sérieux. Ils ont créé des milliers de scénarios fictifs où des robots essayaient d'accomplir des tâches impliquant des données sensibles, comme la lecture de documents privés ou l'utilisation de clés secrètes. Ils ont découvert que sans SlotGuard, les robots fuitaient presque tout — 100 % du temps. Même les méthodes simples de « rédaction » (redaction), qui consistent simplement à remplacer les secrets par des mots comme [PASSWORD], étaient un désastre ; elles brisaient la capacité du robot à faire son travail, provoquant un échec dans 97,5 % des cas car le robot était confus par les détails manquants.

SlotGuard, cependant, a changé la donne. Dans leurs tests, la version complète du système (qui inclut un graphe de suivi intelligent) a réussi à cacher tous les identifiants plantés et a stoppé toutes les fuites d'identifiants (0,0 % de fuite). Pour les données structurelles comme les chemins et les e-mails, il a supprimé 100 % des caractères sensibles visibles, à l'exception d'un cas particulier impliquant des chemins absolques appartenant à la racine (root), ce qui reste une légère lacune du prototype actuel. Mieux encore, cela n'a pas cassé le cerveau du robot. Les robots utilisant SlotGuard étaient presque aussi performants que s'ils avaient vu les vrais secrets, maintenant des taux de réussite élevés à travers différents modèles. Le système est également incroyablement rapide, prenant moins d'un clin d'œil (environ 14 microsecondes) pour réécrire un seul tour de conversation, de sorte qu'il ne ralentit rien.

Le document souligne également ce que SlotGuard ne fait pas. Ce n'est pas un bouclier de lecture de pensée ; si le cerveau dans le cloud est assez intelligent pour deviner votre secret simplement grâce au contexte de la conversation, SlotGuard ne peut pas l'empêcher. Il ne vous protège pas non plus si votre propre ordinateur est déjà piraté. Mais pour le problème spécifique de l'empêchement de la fuite de vos données privées dans les transcripts du cloud, SlotGuard offre une solution robuste, rapide et intelligente qui garde vos secrets en sécurité tout en laissant votre robot accomplir son travail.

Résumé Technique : SlotGuard

Énoncé du Problème

Les agents de Grands Modèles de Langage (LLM) divulguent fréquemment des informations locales sensibles, notamment des chemins de fichiers, des adresses e-mail, des noms d'hôtes et des identifiants (ex: clés d'API), dans les transcriptions envoyées aux fournisseurs de modèles en amont. Cette fuite se produit non seulement via les prompts de l'utilisateur, mais aussi à travers les observations d'outils, telles que les journaux de shell, les lectures de fichiers et les listes de processus (ex: la sortie de ps contenant des variables d'environnement de repli). Une fois que ces enregistrements entrent dans les transcriptions destinées au fournisseur, ils peuvent être conservés pour l'entraînement du modèle, journalisés par les systèmes de service ou exposés via des défaillances opérationnelles.

Les stratégies de mitigation existantes, principalement basées sur la rédaction par remplacement par des espaces réservés (placeholders), sont fragiles. Elles échouent souvent à détecter les références intégrées ou inter-tours, sur-rédactent des éléments bénins ressemblant à des données sensibles, et, surtout, détruisent la syntaxe structurelle (ex: formes de chemins, extensions de fichiers, grammaire URI) dont les agents ont besoin pour raisonner et exécuter des appels d'outils valides. Cela crée un arbitrage où une rédaction forte protège la vie privée mais brise les flux de travail des agents, tandis qu'une rédaction faible préserve l'utilité mais expose les données sensibles.

Méthodologie : SlotGuard

SlotGuard est une frontière de transcription locale conçue pour se situer entre le runtime de l'agent et le fournisseur de modèle en amont. Il fonctionne en réécrivant les transcriptions avant la soumission et en restaurant les valeurs brutes uniquement au sein du runtime local de confiance avant l'exécution. Le système emploie quatre mécanismes de base :

Abstraction Structurelle Typée : Au lieu d'espaces réservés génériques, SlotGuard convertit les liaisons structurelles (chemins, noms d'hôtes, e-mails) en créneaux (slots) typés et stables (ex: [REPO_ROOT_1], [EMAIL_1]). Ces créneaux sont déterministes au sein d'une session (en utilisant un HMAC avec un secret de session) mais impossibles à lier entre différentes sessions. Crucialement, le système effectue une abstraction sensible au suffixe, préservant l'extension de fichier et un suffixe limité et pertinent pour la tâche tout en remplaçant les composants sensibles de la racine et du milieu (ex: /Users/alice/acme/legal/... $\rightarrow$ [REPO_ROOT_1]/legal/[SENSITIVE_DOC_1].pdf).
Substitution Synthétique Préservant le Format (FPS) : Pour les valeurs secrètes (clés d'API, jetons), SlotGuard remplace les identifiants bruts par des jetons synthétiques qui adhèrent strictement à la classe de format d'origine (ex: une URI de base de données ou une chaîne de clé d'API d'apparence valide) mais ne contiennent aucun caractère dérivé du secret original. Cela garantit que le modèle voit des handles syntaxiquement valides et "exécutables" plutôt que des étiquettes opaques comme API_KEY.
Suivi par Session : SlotGuard maintient une table de créneaux par session ( $T$ ) faisant correspondre les valeurs brutes aux handles, ainsi qu'un Graphe d'Entités Sémantiques (SEG) léger. Le SEG suit la corréférence, la dérivation, l'inférence et les références basées sur des mots-clés à travers les tours, permettant au système de protéger les valeurs qui apparaissent indirectement ou sous des formes dérivées, et pas seulement par correspondance exacte de chaînes.
Re-liaison Gardée : Les valeurs brutes ne sont jamais envoyées au fournisseur. Elles ne sont restaurées qu'à l'intérieur du runtime de confiance lorsqu'une exécution d'outil est demandée. SlotGuard vérifie que les handles existent dans la table de session, correspondent aux types attendus et respectent les périmètres autorisés. Il rejette les handles usurpés, les chemins hors périmètre et les tentatives d'injection de métacaractères de shell.

Principales Contributions

Le document identifie deux surfaces de confidentialité orthogonales dans les transcriptions d'agents : les liaisons structurelles (identifiants comme les chemins et les e-mails) et les valeurs secrètes (identifiants). Les principales contributions sont :

Intégration Systématique : L'intégration de l'abstraction structurelle typée, de la substitution synthétique préservant le format, du suivi inter-tours (SEG) et de la re-liaison locale gardée dans une frontière unique et applicable.
Préservation de la Compatibilité : Démontrer que la préservation de la structure pertinente pour l'exécution (forme du chemin, type de fichier, syntaxe des identifiants) est critique pour les performances de l'agent en aval, un facteur souvent négligé par les outils de rédaction génériques.
Frontière Exécutoire : Positionner le système comme une barrière au niveau du harnais de l'agent (ou des couches de passerelle du système de fichiers/du modèle) qui s'interpose sur les sorties d'outils et les observations du runtime, plutôt que de compter uniquement sur les prompts de l'utilisateur.

Résultats d'Évaluation

Les auteurs ont évalué SlotGuard en utilisant des corpus de confidentialité synthétiques, des sondes de flux de travail contrôlés et un ensemble de rejeu dérivé de TheAgentCompany (TAC-lite) sur quatre modèles en amont (DeepSeek, gpt-5.4, Kimi, Llama).

Fuite de Confidentialité :
- Structurelle : SlotGuard a supprimé tous les 20 814 caractères sensibles annotés à travers 9 229 chemins, atteignant 0,0 % de fuite structurelle.
- Identifiants : À travers 852 valeurs d'identifiants plantées, SlotGuard a réduit la fuite à 0,0 %. En revanche, les bases de référence utilisant uniquement des espaces réservés typés ou la FPS sans le SEG ont laissé fuiter 23,5 % des identifiants en raison d'expositions fragmentées ou intégrées reconstructibles.
Compatibilité du Flux de Travail et Succès des Tâches :
- La rédaction générique a provoqué l'effondrement des taux de réussite des tâches à 2,5 % sur tous les modèles.
- SlotGuard a maintenu des performances proches des transcriptions brutes : égalant les scores bruts pour Kimi et Llama, restant à moins de 2,0 points pour gpt-5.4, et à moins de 10,5 points pour DeepSeek.
- Dans le benchmark de rejeu TAC-lite, SlotGuard a égalé les scores bruts pour trois des quatre modèles, alors que la rédaction générique a totalement échoué (0,0 %).
Surcharge de Temps d'Exécution : Le processus de réécriture est hautement efficace, avec une latence médiane de 14,424 µs par tour d'agent. Le détecteur sémantique optionnel (utilisé pour les noms de fichiers difficiles à détecter) ajoute de la latence (~742 ms à chaud) mais n'est pas requis pour le chemin rapide.

Signification et Revendications

L'article affirme que SlotGuard établit une "frontière locale préservant la compatibilité" qui assure la médiation entre la confidentialité de la transcription et l'accès aux outils. Il soutient que la clé de la confidentialité dans les systèmes d'agents n'est pas simplement de cacher les valeurs, mais de le faire sans détruire les indices syntaxiques et structurels nécessaires au raisonnement.

Les auteurs notent explicitement des limites et des revendications modestes :

SlotGuard n'est pas un système d'anonymisation complet ; il ne peut pas empêcher l'inférence sémantique à partir d'un contexte non littéral ni protéger contre un runtime local compromis.
L'évaluation actuelle repose sur des charges de travail synthétiques et de rejeu avec une vérité de terrain plantée ; la validation sur des traces de production avec des données sensibles naturelles est une étape future nécessaire.
Le Graphe d'Entités Sémantiques (SEG) est une implémentation précoce reposant sur des liens par mots-clés/motifs plutôt que sur une compréhension sémantique complète, représentant un premier pas conservateur vers la gestion des fuites indirectes.
Le système ne mesure pas la reconstruction par des attaquants capables tentant activement de récupérer les valeurs à partir du contexte résiduel.

Par conséquent, les auteurs positionnent SlotGuard comme une couche nécessaire dans une posture de confidentialité plus large, conçue pour réduire l'exposition inutile d'identifiants locaux et d'identifiants aux fournisseurs en amont tout en maintenant l'utilité de l'agent.