Fuite d'information par un LLM : quand vos données ressortent côté utilisateur

Un assistant IA peut restituer à un utilisateur une donnée qu'il n'aurait jamais dû voir, un secret interne, un extrait de contrat ou l'information d'un autre client, sans qu'aucune alarme ne se déclenche. La bonne nouvelle : cette fuite n'est pas une fatalité, elle se ferme en empilant quatre couches de défense simples à décrire et vérifiables une par une. Dans cet article, je vous explique par où l'information s'échappe d'un modèle de langage, puis la méthode couche par couche pour que votre IA cesse d'être une passoire à données sensibles.

Le problème : un LLM ne sait pas ce qu'il a le droit de dire

Un modèle de langage n'a aucune notion d'habilitation. Il complète du texte à partir de tout ce qu'on lui a appris et de tout ce qu'on lui donne à lire dans l'instant. Si une information sensible se trouve à portée, rien en lui ne l'empêche de la recracher à la première question habile. C'est le deuxième risque de l'OWASP LLM Top 10, celui de la fuite d'information sensible, et il se nourrit de trois canaux qu'il faut savoir distinguer avant de vouloir les fermer.

Ces trois canaux se combinent souvent dans une même application. C'est pourquoi une réponse unique ne suffit pas : il faut une défense en couches, chacune attrapant ce que la précédente a laissé passer.

La méthode : quatre couches de défense

Voici la méthode que j'applique pour rendre étanche un assistant IA. Chaque couche est indépendante et se vérifie séparément, mais c'est leur empilement qui fait la solidité de l'ensemble.

Couche 1 : cloisonner les accès

Le principe est simple : l'IA ne doit jamais voir plus que l'utilisateur qui l'interroge. En pratique, cela veut dire que la requête hérite des droits de cet utilisateur, et que le modèle n'interroge vos bases qu'au travers de ces droits, jamais avec un compte de service qui voit tout. Si l'utilisateur n'a pas accès à un document, le moteur de recherche qui alimente l'IA ne doit même pas le lui remonter. C'est le contrôle d'accès de vos applications classiques, appliqué à la lettre au pipeline IA.

• Propager l'identité de l'utilisateur jusqu'à la couche de recherche, pas seulement à l'interface.
• Bannir le super-compte qui lit toutes les données, source numéro un des fuites inter-utilisateurs.
• Filtrer les résultats du RAG selon les habilitations avant qu'ils n'atteignent le modèle.

Couche 2 : minimiser le contexte

Tout ce que vous placez dans le prompt peut ressortir dans la réponse. La règle est donc de n'y mettre que le strict nécessaire à la tâche. Un assistant qui répond à une question sur une facture n'a pas besoin de la fiche RH complète du client. Réduisez le périmètre des données rapatriées, masquez les champs inutiles à la source, et ne conservez jamais dans l'historique de conversation des informations sensibles qui pourraient être rejouées plus tard. Moins il y a de données dans le contexte, moins il y a de matière à faire fuir.

Couche 3 : filtrer les sorties

Malgré tout, une donnée sensible peut se glisser dans une réponse. La troisième couche inspecte donc chaque sortie avant qu'elle n'atteigne l'écran, pour y détecter et masquer ce qui ne doit pas sortir : numéros de sécurité sociale, coordonnées bancaires, secrets d'authentification, données de santé. C'est exactement le rôle qu'un filtre de prévention des fuites de données joue déjà sur votre messagerie, transposé aux réponses de l'IA. Cette couche est votre dernier rempart, celui qui rattrape ce que les deux premières ont laissé passer.

Une donnée que le modèle n'a jamais vue ne peut pas fuir. Une donnée qu'il a vue mais que le filtre de sortie masque ne fuit pas non plus. La sécurité naît de ce double verrou, pas d'une confiance aveugle dans le modèle.

Couche 4 : tracer et tester

On ne sécurise que ce que l'on observe. Journalisez chaque requête et chaque réponse de façon à pouvoir reconstituer, après coup, qui a demandé quoi et ce que l'IA a répondu. Puis éprouvez réellement le dispositif : demandez à l'assistant de révéler ses instructions, de citer des données d'un autre utilisateur, de restituer un secret. Cette démarche offensive porte un nom, c'est le red teaming de votre LLM, et c'est elle qui transforme une intuition de sécurité en preuve de robustesse. Une couche que l'on n'a jamais attaquée n'est qu'une hypothèse.

Le résultat : une fuite qui n'a plus de chemin

En empilant ces quatre couches, vous fermez chacun des trois canaux de fuite. Le cloisonnement neutralise les fuites inter-utilisateurs, la minimisation assèche le contexte, le filtrage de sortie rattrape les débordements, et la traçabilité couplée au test vous donne la preuve que l'ensemble tient. Voici ce que chaque couche verrouille :

Cette exigence rejoint directement le RGPD : une donnée personnelle qui ressort côté utilisateur sans base légale est une violation, au même titre qu'une fuite par piratage. Si vos équipes utilisent déjà des IA génériques sur vos données, les cinq risques RGPD de ChatGPT en entreprise complètent utilement cette lecture technique.

Questions fréquentes

Un modèle qui tourne chez nous, sans connexion externe, peut-il quand même faire fuiter des données ?

Oui. La fuite n'est pas forcément une donnée qui part vers l'extérieur : c'est le plus souvent une donnée interne restituée à la mauvaise personne interne. Un modèle hébergé chez vous reste exposé aux fuites par le contexte et par un cloisonnement défaillant. La localisation protège la souveraineté, pas l'étanchéité entre utilisateurs.

Suffit-il de dire au modèle, dans ses instructions, de ne pas révéler d'informations confidentielles ?

Non, et c'est le piège le plus courant. Une consigne dans le prompt est une intention, pas un contrôle de sécurité : elle se contourne avec une formulation habile. La consigne peut compléter le dispositif, mais elle ne remplace jamais le cloisonnement des accès ni le filtrage des sorties, qui eux ne dépendent pas de la bonne volonté du modèle.

Faut-il renoncer au RAG pour éviter ces fuites ?

Non. Le RAG bien construit est au contraire une bonne architecture, à condition de filtrer les documents selon les habilitations de l'utilisateur avant de les remonter au modèle. Le problème n'est pas de brancher l'IA sur vos documents, c'est de le faire sans propager les droits d'accès.

Comment savoir si notre assistant IA fuit déjà, aujourd'hui ?

En le testant activement, avec des scénarios d'extraction pensés pour le mettre en défaut, et en relisant ses journaux. C'est précisément l'objet d'un audit de sécurité de votre application IA, qui cartographie les canaux de fuite avant qu'un utilisateur ne les trouve à votre place.

Reprendre la main sur ce que votre IA a le droit de dire est exactement le travail de mon audit Sécurité & Conformité IA : en quelques jours, on identifie les canaux de fuite ouverts et on pose les couches qui les ferment. Pour en parler sur votre cas, un premier échange de trente minutes suffit à situer votre exposition.

Cet article a une visée pédagogique et ne constitue pas un conseil juridique. Chaque situation mérite une analyse au cas par cas.