RAG multi-tenant : sécuriser les droits d'accès

Un RAG mal isolé peut construire une réponse à partir d'un document que l'utilisateur n'a pas le droit de lire, ou pire, à partir des données d'un autre client dans un logiciel multi-tenant. Le risque ne vient presque jamais du modèle de langage lui-même : il vient d'un filtrage des droits appliqué trop tard, après la génération, ou absent au moment de la recherche vectorielle. La bonne pratique consiste à filtrer par les permissions au moment même de la recherche, avant que le modèle ne voie le moindre passage.

Ce sujet concerne autant l'entreprise qui déploie un assistant interne sur ses documents que l'éditeur de logiciel qui propose un RAG à plusieurs clients depuis la même infrastructure. Dans les deux cas, une seule règle de filtrage mal écrite suffit à transformer un incident mineur en fuite de données.

Cet article détaille où appliquer les droits, pourquoi le filtrage a posteriori ne suffit pas, le risque spécifique d'injection de prompt via les documents, comment journaliser les accès, et comment tester ces droits avant la mise en production.

Le risque concret : une réponse construite avec un document interdit

Le scénario le plus fréquent est interne : un RAG indexe les documents RH, financiers et contractuels d'une entreprise pour répondre aux questions des salariés. Sans filtrage par les droits, un collaborateur qui demande une information sur les grilles de rémunération peut recevoir une réponse construite à partir d'un document de paie qui ne lui était pas destiné, simplement parce que ce document contenait des passages sémantiquement proches de sa question.

Le second scénario touche les éditeurs de logiciels et les ETI qui proposent un agent IA de support client basé sur un RAG à plusieurs clients depuis la même plateforme. Si l'isolation entre clients n'est pas garantie au niveau de la base vectorielle, une réponse générée pour le client A peut s'appuyer sur des documents appartenant au client B. Ce n'est plus une maladresse interne, c'est une fuite de données contractuelle entre deux entreprises clientes.

Dans les deux cas, le mécanisme est le même : le système de recherche a remonté un passage pertinent sur le plan sémantique, mais interdit sur le plan des droits. Le modèle de langage ne fait aucune différence entre les deux, sauf si on le lui impose explicitement en amont.

Où appliquer les droits : filtrer au moment de la recherche

La règle de base d'un RAG en entreprise sécurisé est simple à énoncer et exigeante à tenir : le filtrage par les droits doit avoir lieu pendant la requête de recherche, avant que le moindre passage n'entre dans le contexte envoyé au modèle. Trois mécanismes s'articulent pour y parvenir.

Filtrage par métadonnées au moment de la recherche vectorielle

Chaque document indexé porte des métadonnées de droits : identifiant utilisateur ou groupe autorisé, client propriétaire, niveau de confidentialité. La requête de recherche vectorielle intègre systématiquement un filtre sur ces métadonnées, en plus de la similarité sémantique. Un passage dont les métadonnées ne correspondent pas au profil de l'utilisateur n'est jamais retourné, quelle que soit sa pertinence sémantique.

Collections séparées par client

Pour un éditeur qui héberge plusieurs clients, une isolation plus forte consiste à créer une collection ou un index vectoriel distinct par client, plutôt qu'un filtre appliqué sur une base commune. Le risque d'erreur de filtrage disparaît presque entièrement, au prix d'une infrastructure plus lourde à opérer et à faire évoluer. C'est le choix recommandé dès que le volume de clients ou la sensibilité des données le justifie.

Hériter les droits de la source (SharePoint, Google Drive, GED)

Quand un RAG indexe des documents déjà stockés dans SharePoint, Google Drive ou une gestion électronique de documents, les droits ne doivent pas être recréés manuellement dans le RAG. L'indexation doit interroger l'API de la source pour récupérer, avec le contenu, la liste des utilisateurs ou groupes autorisés à le consulter, puis resynchroniser régulièrement cette information. Un droit retiré dans SharePoint doit se répercuter dans le RAG sans intervention manuelle, sous peine de voir les deux systèmes diverger silencieusement.

Pourquoi filtrer après génération ne suffit pas

Une erreur récurrente consiste à laisser le retrieval remonter tous les passages pertinents, puis à masquer après coup les informations que l'utilisateur ne devrait pas voir, par exemple en filtrant la réponse finale ou en instruisant le modèle de ne pas mentionner certains sujets. Cette approche échoue pour deux raisons.

D'abord, au moment où le filtrage a lieu, le modèle a déjà lu le contenu interdit pour construire sa réponse. Une partie de cette information peut transparaître de façon indirecte, reformulée ou déduite, sans que le filtre final ne la détecte. Le Top 10 OWASP pour les applications LLM (édition 2025) classe d'ailleurs la divulgation d'informations sensibles au deuxième rang des risques, en forte progression par rapport à l'édition précédente.

Ensuite, un filtrage après génération repose sur des instructions données au modèle ou sur une couche de vérification supplémentaire, deux mécanismes probabilistes et contournables, alors qu'un filtre appliqué au niveau de la recherche est déterministe : un document non autorisé n'entre tout simplement jamais dans le contexte.

L'injection de prompt via les documents, un risque propre au RAG

Un RAG introduit un risque que les usages classiques d'un assistant IA ne connaissent pas : l'injection de prompt indirecte. Des instructions malveillantes peuvent être dissimulées dans un document légitimement indexé, par exemple un texte en police minuscule dans un PDF, un commentaire caché dans un fichier Word, ou une cellule masquée dans un tableur, demandant au modèle d'ignorer ses consignes initiales ou de révéler des informations confidentielles.

Ce risque n'est pas théorique : l'OWASP Gen AI Security Project place l'injection de prompt en tête de son Top 10 des risques pour les applications LLM depuis deux éditions consécutives, précisément parce qu'un modèle de langage ne distingue pas nativement une instruction d'un contenu à traiter comme simple donnée.

Se prémunir contre ce risque suppose plusieurs couches : traiter tout contenu récupéré comme une donnée à résumer, jamais comme une instruction ; limiter strictement ce qu'un agent connecté au RAG peut exécuter comme action ; et surveiller les réponses qui s'écartent du registre attendu, un signal souvent révélateur d'une tentative d'injection réussie.

Journaliser et auditer les accès et les réponses

Une politique de droits, aussi bien conçue soit-elle, ne vaut que si elle peut être vérifiée après coup. La journalisation doit conserver, pour chaque requête, l'utilisateur à l'origine de la question, les documents effectivement récupérés, et la réponse générée. C'est ce qui permet de reconstituer un incident, de démontrer une conformité, ou simplement de détecter qu'un filtre ne fonctionne plus comme prévu.

La CNIL recommande explicitement, dans ses lignes directrices sur le développement des systèmes d'IA, le contrôle d'accès aux modèles et aux jeux de données ainsi que la journalisation des accès et des requêtes. Ce n'est pas une bonne pratique optionnelle : c'est un élément attendu dans une analyse d'impact relative à la protection des données pour un système jugé sensible.

Comment tester les droits d'accès avant la mise en production

Un modèle de droits ne se valide pas en le lisant, il se valide en l'attaquant méthodiquement. La méthode la plus fiable consiste à construire plusieurs comptes de test représentant des profils d'accès distincts (un salarié standard, un manager, un prestataire externe, ou pour un éditeur, deux clients différents) puis à leur poser le même jeu de questions.

Pour chaque profil, il faut vérifier deux choses séparément : que les documents restreints n'apparaissent jamais parmi les passages récupérés par le retrieval, et que la réponse générée ne contient aucune information qui n'aurait dû provenir que de ces documents. Cette vérification rejoint la logique développée dans notre article sur la baseline d'évaluation d'un RAG : sans jeu de test rejouable, impossible de prouver qu'un correctif de sécurité fonctionne réellement.

• Construire un jeu de questions par profil, couvrant à la fois les questions légitimes et les questions qui tentent délibérément d'accéder à une information hors périmètre
• Vérifier les passages récupérés, pas seulement la réponse finale, pour localiser une fuite au niveau du retrieval avant qu'elle n'atteigne l'utilisateur
• Tester le changement de droits : retirer un accès et vérifier que le document disparaît immédiatement des résultats, sans attendre une réindexation complète
• Rejouer ces tests après chaque changement touchant les permissions, le pipeline d'indexation, ou l'ajout d'une nouvelle source documentaire

Pour la sécurité des données au sens large, notre checklist sécurité des données et RGPD pour l'IA en PME complète ces tests par les points de conformité à vérifier avant tout déploiement. Quand la contrainte de souveraineté s'ajoute à l'exigence de sécurité, l'architecture décrite dans notre retour d'expérience sur le RAG souverain avec Mistral montre comment ces deux exigences se combinent en production. Pour les documents les plus sensibles, l'anonymisation RGPD par IA avant indexation reste une couche de protection supplémentaire, indépendante du filtrage par droits.

Ces droits ne se figent pas une fois posés : de nouveaux documents arrivent, des collaborateurs changent d'équipe, un client résilie et ses données doivent être purgées. Notre article sur la maintenance d'un RAG en production détaille comment ces droits se maintiennent dans la durée, au même titre que les sources et les modèles.

Chez Tensoria, la conception des droits d'accès et de l'isolation multi-tenant fait partie du cadrage de tout projet de RAG sur mesure, avant même le choix technique du chunking ou du modèle : un système qui répond bien mais aux mauvaises personnes n'est pas un système qui fonctionne. L'accompagnement se fait sur devis, selon le nombre de sources à connecter et le niveau d'isolation requis.

Questions fréquentes

Articles recommandés

• Maintenir un RAG en production : comment les droits, les sources et les modèles se maintiennent dans la durée, une fois le système en ligne.
• RAG en entreprise : comprendre les fondamentaux du Retrieval-Augmented Generation avant d'aborder la sécurité des accès.
• Baseline d'évaluation RAG : la méthode pour prouver qu'un correctif de sécurité fonctionne réellement.
• Sécurité des données IA en PME : la checklist RGPD et souveraineté à vérifier avant tout déploiement.
• RAG souverain avec Mistral : l'architecture retenue quand la souveraineté des données s'ajoute à l'exigence de sécurité.
• 5 erreurs qui font échouer un projet RAG : les pièges les plus fréquents, dont l'absence de suivi après déploiement.