Empêcher les données sensibles de fuiter dans les chats LLM tiers
Un article de juillet 2026 construit un pare-feu open source côté client qui intercepte les prompts avant qu'ils n'atteignent ChatGPT, Claude ou Copilot et bloque PII, secrets et code propriétaire.
De quoi s’agit-il ?
Chaque fois qu’un employé colle une fiche client, une clé d’API ou un extrait de code interne dans un chatbot public, des données sensibles franchissent une frontière organisationnelle qu’aucun pare-feu ne surveillait. C’est le risque répertorié comme Sensitive Information Disclosure (LLM02) dans l’OWASP Top 10 pour applications LLM — et il tient moins aux attaquants qu’à la simple pression de productivité. Les avertissements statiques « ne collez pas de secrets » provoquent une fatigue d’alerte ; les interdictions générales poussent vers des outils fantômes.
Un article publié sur arXiv le 9 juillet 2026, Multi-Agent Firewall Architecture for Privacy Protection of Sensitive Data in Interactions with Language Models (2607.08282), signé Hugo García Cuesta, Pablo Mateo Torrejón et Alfonso Sánchez-Macián (Universidad Carlos III de Madrid), propose une réponse défensive : un pare-feu côté client qui inspecte ce que l’utilisateur s’apprête à envoyer à un modèle tiers et arrête le contenu sensible avant qu’il ne quitte la machine. Le système, Minos Verdict Mesh, est publié en open source (MIT). C’est une étude de prévention des fuites de données, pas une technique d’attaque.
Comment ça marche
La conception sépare l’interception de l’analyse. Deux capteurs saisissent le trafic sortant. Une extension de navigateur (Chromium, Manifest V3) s’accroche à l’interface de chat de chaque site via un adaptateur par plateforme, captant texte et fichiers avant qu’ils n’atteignent la page. Un proxy transparent (basé sur mitmproxy) couvre l’usage programmatique, en interceptant à la fois les requêtes HTTP(S) et les sessions WebSocket persistantes vers les fournisseurs LLM connus ; pour lire les corps chiffrés en TLS, il installe sa propre autorité de certification dans le magasin de confiance local, et il isole le contenu rédigé par l’utilisateur en filtrant sur le champ role du message.
Le contenu capturé est envoyé à un backend local (FastAPI) qui exécute un pipeline multi-agents orchestré comme un graphe orienté acyclique dans LangGraph. La topologie est volontairement statique : les auteurs ont prototypé un routeur piloté par LLM mais l’ont trouvé plus lent, plus coûteux et non déterministe ; un graphe fixe à arêtes conditionnelles l’a emporté. La détection procède par paliers pour garder le cas courant peu coûteux. Une première couche exécute trois détecteurs en parallèle — correspondance de motifs déterministe (regex avec fenêtres de mots-clés de proximité et validation par somme de contrôle, de sorte qu’une chaîne de 16 chiffres n’est signalée comme numéro de carte que si des termes liés aux cartes figurent à proximité), reconnaissance d’entités nommées zero-shot via GLiNER, et vérification floue de similarité de code (RapidFuzz sur des dépôts Git indexés) qui repère le code propriétaire même renommé ou légèrement remanié. Seuls les cas ambigus escaladent vers une seconde couche : un LLM raisonne sur une copie déjà anonymisée du prompt, si bien que les secrets en clair ne sont jamais transmis au modèle d’analyse.
Cet ordre « anonymiser d’abord » est essentiel. Les détections déterministes et NER sont caviardées en marqueurs typés avant qu’un modèle ne voie le texte, ce qui résout le paradoxe d’un outil de confidentialité qui fuiterait lui-même les données qu’il inspecte. Un score de risque pondéré agrège ensuite les résultats — plusieurs éléments à faible risque peuvent ensemble franchir un seuil — et se traduit par une politique par requête : autoriser, avertir ou bloquer. Dans le navigateur, un blocage est une fenêtre modale avec intervention humaine (annuler, forcer, ou envoyer une version auto-anonymisée) ; dans le proxy, l’application est automatique (HTTP 403, ou message WebSocket abandonné). Les deux échouent de façon fermée si le backend est injoignable.
Sur le benchmark Nemotron-PII (locale US, 500 cas), la meilleure configuration — un Gemma 3 4B local affiné — atteint 94,93 % de F1 (précision et rappel tous deux ≈ 94,9 %), tandis qu’un réglage privilégiant la latence garde des réponses sous la seconde à ~82 % de F1. Les chemins multimodal, similarité de code et fidélité d’anonymisation étaient désactivés pour ce benchmark et restent non mesurés.
Pourquoi c’est important
L’essentiel des travaux de sécurité LLM surveille ce qui sort d’un modèle — jailbreaks, instructions injectées, réponses dangereuses. Ici, on surveille ce qui entre, et du côté utilisateur de la frontière de confiance plutôt qu’en routant le trafic vers un énième fournisseur. Cela comble un vrai manque : les garde-fous au niveau du SDK exigent de modifier le code de l’application, et les services d’inspection cloud transfèrent précisément les données que l’on cherche à protéger vers un tiers. Un intercepteur local, agnostique de l’application, évite les deux écueils. La conception en paliers est aussi un modèle utile — règles déterministes pour l’évident, petit modèle local seulement pour l’ambigu — pour quiconque construit des contrôles de sortie autour des outils d’IA.
Défenses
Pour les équipes inquiètes de voir des données s’échapper par les chatbots :
- Traitez les prompts comme un canal de sortie. Les données sensibles partant vers un LLM tiers méritent la même posture DLP que l’e-mail ou les envois de fichiers ; inspectez-les au moment de l’envoi, pas après.
- Anonymisez avant d’inspecter. Caviardez les détections déterministes en marqueurs avant qu’un second modèle ne lise le texte, pour que la couche de sécurité ne devienne pas la fuite.
- Couvrez les deux surfaces. Chat dans le navigateur et trafic API/WebSocket programmatique sont deux canaux distincts ; un filtre texte-seul ou web-seul laisse l’autre grand ouvert.
- Gardez la détection locale et à échec fermé. Une analyse sur l’appareil évite d’exporter les données que vous protégez ; bloquez plutôt que laisser passer quand le contrôleur est indisponible.
- Lisez les chiffres comme un point de départ. Les résultats proviennent d’un seul jeu de données PII en anglais, chemins similarité de code et multimodal désactivés ; validez sur vos propres données avant de fixer un seuil.
Status
| Élément | Détail |
|---|---|
| Constat | Pare-feu côté client, agnostique de l’application, qui bloque PII, secrets et code propriétaire avant qu’ils n’atteignent des LLM tiers, rattaché à OWASP LLM02 |
| Source | Multi-Agent Firewall Architecture for Privacy Protection of Sensitive Data in Interactions with Language Models, García Cuesta, Mateo Torrejón, Sánchez-Macián, Universidad Carlos III de Madrid, arXiv, 9 juillet 2026 |
| Système | Minos Verdict Mesh — capteurs extension navigateur + mitmproxy, pipeline DAG LangGraph (déterministe + NER GLiNER + similarité de code + LLM conditionnel) ; open source, MIT |
| Résultat clé | 94,93 % de F1 sur Nemotron-PII (Gemma 3 4B local affiné) ; ~82 % de F1 sous la seconde en mode latence-first |
| Type | Recherche défensive / outil de prévention des fuites de données (préprint ; pas de CVE) |