Droits dans un RAG : vérifier ce qui entre dans le contexte

Une question sur un retour produit peut retrouver une procédure de la bonne équipe, une remise commerciale réservée ou une règle appartenant à une autre société. Les mots sont proches ; leurs lecteurs autorisés diffèrent. Le risque est une divulgation entre équipes ou clients. Si le RAG classe tout le corpus puis transmet ses meilleurs passages au modèle, une réponse pertinente peut déjà avoir franchi une frontière documentaire avant que le contrôle de l’écran intervienne.

En pratique, l’autorisation doit décider quels passages peuvent entrer dans le contexte et rester vérifiable à la restitution. Le score de recherche ne donne aucun droit de lecture. La conception d’un chatbot RAG d’entreprise doit garder cette frontière dans les extraits, citations et réponses en cache, y compris lorsque les permissions changent pendant une attente.

Six documents fictifs, trois lecteurs et vingt scénarios manuscrits font varier les passages disponibles pour une même question. La recherche lexicale FTS5 restitue des copies d’extraits autorisés ; aucun LLM, embedding ou moteur vectoriel n’intervient. Le test suit aussi une permission révoquée après sélection. L’accompagnement IA sur mesure de Dawap permet de prolonger cette recette sur les connecteurs documentaires réels, depuis la transmission des droits jusqu’au contrôle des citations et des résultats conservés.

Pour qui le RAG traverse équipes et entités

Repérer les lecteurs qui partagent une question mais pas une pièce

Le sujet concerne une assistance documentaire utilisée par plusieurs équipes ou sociétés. Une procédure générale peut être accessible à tous, alors qu’un accord commercial ou une pièce de dossier possède un périmètre plus étroit. La recherche doit tenir compte de ces différences sans demander à la personne de les rappeler dans chaque question. La formulation « explique la règle de retour » ne précise pas forcément la source qu’elle a le droit de lire.

Le propriétaire du corpus identifie les règles d’accès et la source qui fait autorité pour chacune. Le métier choisit les questions utiles ; l’équipe technique vérifie comment ces règles atteignent l’index et la restitution. Le service doit aussi définir le comportement lorsque l’état courant ne peut pas être établi. Une impossibilité de vérifier le droit ne doit pas être convertie en accès général pour éviter une réponse vide.

Ne pas confondre accès à l’application et accès au corpus entier

Un utilisateur autorisé à ouvrir le chatbot n’est pas nécessairement autorisé à lire tous les documents qu’il indexe. Les permissions d’une fonctionnalité et celles de ses sources doivent rester distinctes. Les traitements de recherche, de génération et de support possèdent également leurs capacités techniques ; celles-ci ne deviennent pas les droits de la personne qui pose la question.

La référence OWASP sur l’autorisation recommande notamment refus par défaut et vérification des permissions à chaque requête. Le banc fixe les identités à la main et applique ces conditions à ses objets. Il ne teste pas une authentification réelle, une fédération d’identité ou la propagation d’une révocation entre plusieurs services.

Écrire les droits de lecture avant la recherche

Distinguer équipe, société et autorisation explicite

Alice et Bob appartiennent à A, mais ne possèdent pas les mêmes pièces. Charlie appartient à B. Une table d’autorisations explicites relie chaque personne aux documents lisibles. La frontière de société est vérifiée séparément ; une autorisation incohérente ajoutée par erreur à Alice sur D3 de B ne suffit pas dans le banc. Ces conditions sont une politique locale choisie, à rapprocher du modèle d’habilitation réel.

D0 est qualifié public dans ce jeu, mais possède tout de même des entrées explicites pour les trois personnes. Le mot public n’active pas une dérogation cachée au contrôle. D4 manque de permission et reste exclu. Une production doit décider ce que signifient source publique, permission absente et métadonnée invalide ; ces états ne doivent pas être assimilés arbitrairement lors de l’ingestion ou de la recherche.

Vérifier les combinaisons que le moteur applique réellement

Une plateforme peut proposer une sécurité documentaire native, un filtrage de requête ou une séparation d’index. Les garanties varient selon interfaces, rôles et configuration. La documentation Elastic sur les permissions documentaires précise notamment qu’omettre la query de restriction désactive le contrôle documentaire pour l’entrée de permission concernée. La présence d’un rôle nommé « sécurisé » ne prouve donc pas son périmètre effectif.

Le laboratoire n’utilise pas Elastic DLS ni une barrière moteur. Ses filtres appartiennent au service Python et à sa requête SQLite. Un accès direct à la base pourrait contourner cette politique. La recette réelle doit vérifier le compte utilisé, les rôles cumulés, les chemins alternatifs et les opérations couvertes. Une protection native peut compléter le service sans remplacer les contrôles nécessaires sur ses caches et objets dérivés.

Conserver la frontière du document dans ses passages

Attacher l’extrait à sa pièce et à sa révision

Un passage doit conserver document d’origine, révision et périmètre de lecture. Une ligne d’index contenant seulement texte et vecteur serait insuffisante pour revalider ces conditions. La transformation documentaire doit propager les informations nécessaires au contrôle, avec un comportement défini lorsque l’origine manque. L’extrait ne devient pas public parce qu’il ne représente qu’une petite partie du document initial.

Nous utilisons un seul passage par document, sans découpage ni embedding. Le snapshot contient doc_id, tenant, revision et body. Ce choix réduit le laboratoire aux transitions d’accès. Une production avec plusieurs fragments doit tester héritage des permissions, changements de source et pièces partiellement accessibles. Elle doit aussi traiter les citations et métadonnées dérivées qui peuvent révéler une information même lorsque le corps complet n’est pas affiché.

Éviter qu’une transformation élargisse le périmètre

Un résumé mêlant plusieurs sources peut dépendre de la plus restrictive d’entre elles selon la politique retenue. La liste des documents contributeurs doit rester disponible pour vérifier la lecture du résultat. Retirer ensuite la citation visible d’une pièce privée ne retire pas automatiquement les faits qu’elle a introduits. Une transformation doit définir provenance et lecteur autorisé avant d’être stockée comme nouveau contenu documentaire.

Le banc restitue uniquement les passages copiés après contrôle ; il ne teste pas une synthèse libre contenant des faits implicites. Il ne fournit donc pas un vérificateur exhaustif de provenance pour une réponse LLM. Cette limite doit être conservée dans la recette de production, avec des cas de combinaison de sources, de correction et de suppression. La conformité d’une liste de citations ne démontre pas seule que toute la réponse reste dans le périmètre.

Filtrer avant la fenêtre de candidats

Classer les passages admissibles avant de prendre le top-k

La requête joint les autorisations et la frontière de société avant ORDER BY et LIMIT. Le classement lexical sélectionne ensuite le meilleur passage dans ce périmètre. Le sujet provient du service ; un argument qui demande de chercher au nom de Bob reçoit subject_argument_denied. Les questions du laboratoire sont des termes fixés à la main, pas des requêtes SQL ou des filtres fournis par un modèle.

SELECT doc.doc_id, doc.tenant, doc.revision, doc.body, bm25(chunk_fts)
FROM chunk_fts
JOIN document doc ON doc.doc_id = chunk_fts.doc_id
JOIN acl a ON a.doc_id = doc.doc_id AND a.subject = ?
WHERE chunk_fts MATCH ? AND (doc.tenant = ? OR doc.tenant = 'public')
ORDER BY bm25(chunk_fts), doc.doc_id
LIMIT ?

La documentation FTS5 de SQLite décrit son BM25 avec des scores où la meilleure correspondance possède la valeur numériquement la plus faible. Le banc est exécuté avec SQLite 3.53.1 et utilise ce tri, puis doc_id pour départager. Cette recherche lexicale ne reproduit pas un moteur vectoriel ; celui-ci doit être éprouvé avec ses propres règles de filtrage et de sélection.

Reconnaître la perte produite par un filtrage trop tardif

Cas concret : sur retour, le classement global place D3 de B en premier. Prendre ce seul résultat puis filtrer pour Alice produit zéro passage dans R35-08. Filtrer les droits avant la limite retrouve D1 dans R35-01. Paradoxalement, restreindre le corpus avant le classement retrouve ici une preuve utile que la sélection globale perdait. Ce test démontre une perte de couverture due à la fenêtre choisie, sans exécuter de modèle ni mesurer une exfiltration.

Augmenter k peut masquer cette perte sur quelques questions sans résoudre le contrat. Une sélection globale peut aussi manipuler des passages qui ne doivent jamais atteindre le contexte, les traces ou un composant externe. Le service doit définir où les droits sont appliqués et ce que chaque étape reçoit. Les statistiques et scores d’un index partagé peuvent avoir d’autres effets ; leur confidentialité n’est pas éprouvée par ce laboratoire.

Revalider avant d’utiliser les passages

Traiter la recherche comme une sélection datée

Un résultat admissible à la recherche peut ne plus l’être au moment de construire le contexte. Le banc récupère D1 pour Alice, puis retire sa permission avant utilisation : R35-10 refuse la transmission. R35-09 change la révision de la pièce après sélection et refuse aussi le snapshot. La vérification porte sur l’état courant, et non sur la seule présence d’un identifiant dans un résultat antérieur.

Le contrôle compare identité active, document existant, société, permission, révision et contenu exact. Il ne considère pas une ancienne révision comme acceptable parce que la dernière contient encore certains mots communs. Cette politique stricte choisit de demander une nouvelle sélection après modification. Une autre politique peut gérer des versions historiques, mais elle doit établir explicitement leur droit de lecture et leur pertinence pour la question actuelle.

Fermer le contexte si sa provenance a été altérée

R35-12 ajoute un snapshot D3 aux passages autorisés d’Alice ; la vérification refuse le contexte entier. Elle ne garde pas la partie douteuse en comptant sur le prompt pour l’ignorer. Cette décision évite une entrée documentaire dont la frontière est déjà rompue. Le banc ne prend pas de décision métier sur remboursement, et aucun refus n’exécute un effet externe ou ne restitue d’extrait.

La vérification locale ne rend pas atomiques toutes les étapes d’une production distribuée. Un droit peut encore changer après ce contrôle, pendant un appel de modèle ou avant affichage. Il faut définir le point d’autorité, les possibilités d’annulation et la dernière vérification exigée à la restitution. Un résultat déjà transmis à un tiers ne peut pas être rappelé par un simple refus ultérieur dans l’interface.

Contrôler l’ouverture et le contenu d’une citation

Vérifier la référence comme une demande de lecture

Une citation affichée dans une réponse ne constitue pas une autorisation de sa pièce. Le banc refuse D3 lorsque Alice essaie de l’ouvrir dans R35-11, et accepte D0 pour Bob dans R35-20. La référence retrouve le document et les droits courants ; elle ne restitue pas un extrait simplement parce qu’un identifiant est présent dans la réponse. Une URL signée éventuelle doit conserver la politique d’accès choisie.

Le titre, le nom du client ou le chemin d’une pièce peuvent déjà révéler une information. Une application doit décider quelles métadonnées sont affichables et comment répondre à une référence absente ou refusée. Ce laboratoire contrôle le corps des passages et ne prouve pas la confidentialité de tous les libellés d’une interface. Les écrans et liens réels doivent donc rejoindre la recette, avec des pièces portant des noms sensibles.

Distinguer une source accessible d’une affirmation soutenue

Deux questions restent séparées : la personne peut-elle lire cette source, et cette source soutient-elle la réponse ? Le contrôle d’accès peut répondre à la première sans résoudre la seconde. Une référence autorisée mais hors sujet ne prouve rien sur l’affirmation. La validation documentaire doit vérifier le passage cité et sa relation avec les faits avancés, particulièrement pour un montant, une exception ou une règle datée.

Notre sortie copie les extraits admis sans les interpréter ; elle ne mesure donc ni exactitude d’une synthèse ni fidélité de ses citations. Un essai avec un LLM doit conserver cette distinction dans ses verdicts. Il peut comporter une réponse fidèle mais interdite, ou une réponse autorisée mais fausse. Fusionner ces défauts dans une seule note empêcherait de choisir entre correction des droits et correction du mécanisme de réponse.

Bloquer un extrait conservé après retrait de droit

Associer la réutilisation à une provenance encore admissible

Le cache local est indexé par personne et question. Cette clé évite que la demande de Bob reprenne directement la sélection d’Alice, mais elle ne suffit pas à conserver les droits. Les valeurs stockées sont des snapshots documentaires, vérifiés à chaque lecture. R35-13 retire l’accès à D1 après mise en cache ; le retour reçoit cache_access_denied et ne contient aucun passage.

R35-14 modifie la révision de D1 et produit cache_revision_denied. R35-16 contamine la valeur d’Alice avec D3 de B ; la lecture est également refusée. Ces essais distinguent partition de clé et validité de la valeur. Une clé parfaitement isolée peut contenir un résultat obsolète ou mal assemblé. Le contrôle de provenance reste nécessaire avant toute réutilisation, avec une responsabilité claire lorsque la valeur est rejetée.

Choisir le traitement des réponses composées

Une réponse générée peut dépendre de plusieurs documents, de l’historique et d’une mémoire persistante. Revalider seulement la citation finalement visible ne couvre pas tous ses contributeurs. La production doit conserver une provenance suffisante ou refuser le partage de ces objets entre périmètres. Le cache de ce banc contient uniquement des extraits ; il ne résout pas la traçabilité complète d’une synthèse libre ni d’une réponse dérivée d’autres réponses.

Le refus local ne supprime pas automatiquement la valeur du cache et ne relance pas une recherche. Une application doit choisir entre invalidation, nouvelle sélection, réponse indisponible et reprise contrôlée. Le coût caché inclut propagation des changements, mémoire conservée, recherches répétées et investigations après refus. Une durée de vie courte réduit certaines fenêtres, mais ne prouve pas qu’un droit révoqué est pris en compte au moment de l’affichage.

Vingt scénarios et leurs résultats observés

Conserver des accès favorables dans une recette de refus

Les cas nominaux utilisent la même question retour pour trois utilisateurs. Alice retrouve D1, Bob D2 et Charlie D3. Le cas garantie retrouve D5 pour Alice, alors que les essais sur secret, stockb et remise ferment les lectures non admises. Le refus n’est donc pas produit en retirant toute recherche. Les résultats vérifient simultanément qu’un périmètre utile reste ouvert et que ses frontières ne sont pas franchies.

Le terme cache_miss désigne ici une lecture qui n’a pas trouvé de valeur préexistante et poursuit la sélection. Ce n’est pas un verdict d’échec documentaire. Passages_ready désigne l’ouverture nominale de la citation. Les sorties de refus et no_passage ne contiennent aucun extrait. Les vingt scénarios ont chacun zéro effet externe ; ils portent sur lecture et contrôle local, sans appel à un outil de modification du SI.

Interpréter les résultats au niveau réellement éprouvé

La réussite signifie que les conditions et sorties attendues correspondent à ces vingt manipulations locales. Le nombre de cas ne mesure pas une probabilité de fuite. Il n’existe ni échantillon de questions métier représentatif, ni test d’intrusion complet, ni population d’utilisateurs. La recette montre des mécanismes précis : sélection admissible, révision courante et provenance des valeurs conservées.

Exemple concret pour une exploitation réelle : un utilisateur qui ne reçoit plus de réponse après une réorganisation peut subir une révocation correcte, un index non synchronisé ou une recherche insuffisante. Les traces doivent distinguer ces causes sans exposer les passages interdits à cette personne. Le responsable autorisé peut diagnostiquer la transition ; l’utilisateur reçoit un état utilisable et la procédure de reprise prévue pour son périmètre.

Nommer les garanties absentes de ce laboratoire

Tester l’ingestion et le moteur avec leurs propres interfaces

Les permissions du corpus sont saisies dans le banc ; aucun connecteur ne les extrait d’un système documentaire. Une production doit vérifier création, suppression, héritage, groupes, liens de partage et changements d’appartenance selon les interfaces réellement utilisées. Un index initial correct peut devenir faux après une modification de source. Une synchronisation annoncée quotidienne ne définit pas à elle seule le comportement pendant son retard.

Le moteur de recherche réel peut appliquer des filtres différemment selon requête lexicale, vectorielle, hybride ou reranking. Il faut observer les candidats qui traversent chaque étape et les comptes techniques capables de lire les documents. La requête SQLite présentée ne certifie aucun de ces parcours. Un reranker externe doit recevoir seulement les passages admis par la politique du service et par les conditions de traitement choisies.

Conserver les effets auxiliaires dans le périmètre de revue

FTS5 calcule ici ses statistiques sur le corpus partagé. Le filtrage des lignes ne démontre pas l’absence d’influence de documents privés sur scores, rangs ou temps de réponse. Aucun canal auxiliaire n’est étudié. Une exigence de séparation plus forte peut demander des index distincts et une analyse propre au moteur, avec les coûts d’exploitation correspondants. Cette décision relève du risque réel, pas du seul résultat nominal de la requête.

Les logs, traces de prompts, exports de conversation et outils de support créent aussi des copies. Leur durée de conservation, leurs lecteurs et leur suppression doivent être décidés. Le banc ne contrôle pas ces services ni un fournisseur de modèle. Il prépare une liste de frontières à vérifier, sans transformer une réussite applicative en certification de confidentialité de l’ensemble des traitements.

Erreurs fréquentes dans un contrôle d’accès RAG

Confier au prompt une permission que le service doit établir

Demander au modèle de ne pas utiliser les documents d’une autre équipe intervient trop tard si leurs passages sont déjà dans son contexte. Le contrôle doit décider ce qui peut être transmis, à partir d’une identité fiable et des règles courantes. Une instruction trouvée dans une pièce ne peut pas changer l’utilisateur ou lui attribuer un rôle. L’autorité de lecture reste dans le service et le système d’habilitation.

Le filtrage après une sélection globale limitée crée également des réponses vides évitables, comme R35-08. L’équipe peut alors augmenter le volume de contexte et le coût sans corriger la frontière. Elle doit d’abord vérifier où la restriction entre dans la requête et quels objets sortent du moteur. Une mauvaise couverture et une mauvaise autorisation demandent des diagnostics séparés, même lorsqu’elles apparaissent sur la même question.

Réutiliser un résultat parce que son destinataire semble inchangé

Le même utilisateur peut perdre une permission sans changer de nom ou de société. Une réponse en cache n’est donc pas valide uniquement parce que sa clé contient son identifiant. Le service doit vérifier la provenance et les conditions retenues à chaque restitution. Il faut aussi prévoir le retrait d’un document dont le contenu reste dans une mémoire, une synthèse ou un historique, même après disparition de sa citation visible.

Un signal faible apparaît lorsque les refus augmentent après une migration du corpus, alors que la connexion au chatbot fonctionne. Les métadonnées d’accès peuvent avoir été perdues ou élargies. Un autre signal est une réponse identique entre deux équipes malgré des sources distinctes. La revue doit rechercher la cause dans index, contexte et cache, sans ouvrir des accès supplémentaires pour faire disparaître artificiellement les symptômes.

Plan d’action pour une recette documentaire complète

Le contrat définit l’entrée autorisée, les sources admissibles et la sortie qui peut être affichée. Le propriétaire documentaire décide les permissions ; l’équipe du service assure leur application jusqu’aux copies. L’instrumentation retrouve révision, moment du contrôle et motif de refus, avec un accès aux traces lui-même limité. Le repli ne choisit pas un compte plus puissant pour répondre à une question que la personne ne peut plus documenter.

1. Établir une matrice de lecture avec le propriétaire du corpus. Choisissez des personnes de même société mais d’équipes différentes, une autre entité et un état sans permission. Ajoutez une source commune explicitement accessible. Définissez ce qui doit rester inconnu, y compris titres et existence des pièces, avant de choisir les critères de réponse.
2. Suivre une pièce jusqu’à ses objets dérivés. Inspectez ingestion, fragments, métadonnées, index, contexte, citation, historique et cache. Identifiez le système qui fait autorité et le retard possible à chaque transformation. Conservez les contributeurs nécessaires à une revalidation ; refusez les objets dont la provenance ne permet pas de décider le droit de lecture.
3. Éprouver le parcours réel de sélection. Rendez un document privé très pertinent pour une question commune. Vérifiez le filtre avant les limites de candidats et les données envoyées au reranker ou au modèle. Gardez un passage autorisé moins bien classé pour distinguer recherche utile et fermeture générale du corpus.
4. Modifier les droits pendant les attentes. Retirez une permission après recherche, changez une révision et désactivez l’utilisateur. Rejouez aussi depuis cache, citation et conversation sauvegardée. Documentez les fenêtres qui restent ouvertes et le point de restitution choisi, avec les procédures d’annulation et de nouvelle sélection réellement disponibles.
5. Ouvrir selon les preuves et les limites acceptées. Commencez par les lectures dont la matrice et les transitions sont vérifiées. Différez les sources mal synchronisées ou les réponses partagées sans provenance complète. Déclarez les tests encore nécessaires sur moteur, authentification, génération, services externes et canaux auxiliaires, puis attribuez leur suivi avant élargissement.

Le seuil d’ouverture doit distinguer refus de sécurité et abstention documentaire. Une lecture interdite constitue un défaut bloquant dans le périmètre convenu ; une question sans pièce suffisante peut demander une amélioration de couverture ou un repli métier. Le délai accepté de propagation d’une révocation doit être fixé et mesuré séparément. Un taux global de réponses ne permet pas de les arbitrer. Conservez les accès nominaux et les transitions critiques dans la recette de chaque version.

Le contrat de retour arrière doit réduire le périmètre de lecture ou désactiver la capacité concernée, tout en conservant les preuves nécessaires à l’investigation. Il ne suffit pas de restaurer un ancien prompt si l’index ou les copies ont changé. La responsabilité de l’invalidation appartient au service qui conserve la valeur. Il précise les documents contributeurs, la traçabilité des refus et le repli manuel autorisé que les utilisateurs retrouveront pendant la correction.

Guides pour corpus, recherche et contextes partagés

Relier les permissions à une source exploitable

Le RAG fondé sur une preuve documentaire distingue passage disponible et réponse soutenue. Le contrôle d’accès ajoute une condition préalable de lecture. Le traitement des documents contradictoires dans un RAG conserve l’abstention lorsque les pièces admises ne permettent pas de choisir une règle applicable.

La comparaison du découpage d’un corpus RAG aide à vérifier les passages transmis et leur contexte. Les permissions doivent accompagner ces fragments sans être perdues lors de la transformation. Une amélioration de granularité ne doit pas détacher un extrait de son document d’origine ni rendre lisible une partie qui conserve une restriction.

Tester les autres frontières du système de recherche

La recherche hybride et le reranking dans un RAG demandent une recette de candidats et de classement. Les passages admissibles doivent rester le périmètre de cette comparaison. Une amélioration de pertinence sur un corpus global ne démontre pas qu’elle conserve les autorisations lors de la sélection ou du reclassement.

L’isolation des tenants d’un copilote IA traite contexte, files de travail et quotas du service complet. Elle ne remplace pas les permissions entre lecteurs d’une même société. Les deux recettes se complètent lorsqu’une application partagée possède des corpus dont les restrictions sont plus fines que sa seule frontière de tenant.

Conclusion : la pertinence ne remplace pas le droit

Le meilleur passage lexical peut appartenir à une autre société, et le même utilisateur peut perdre le droit de lire une pièce entre deux étapes. Le service doit conserver identité, périmètre et provenance jusqu’à la restitution. La recherche ne donne aucune autorité supplémentaire ; une citation ou une réponse en cache ne transforme pas non plus un accès ancien en permission actuelle.

Les vingt cas locaux montrent les résultats de ces conditions sur six documents fictifs. Le filtre avant limite conserve un passage utile pour Alice ; les changements de droit, de révision et de provenance ferment les sorties prévues. Aucun LLM ni moteur vectoriel n’est exécuté. Les scores partagés, les interfaces d’ingestion et les systèmes distribués restent des garanties à éprouver dans leur environnement réel.

La conception d’un RAG d’entreprise doit s’appuyer sur la matrice des lecteurs et sur les transitions documentaires. La recette garde à la fois les réponses admissibles et les refus, avec les limites de propagation et de stockage acceptées. Elle permet ainsi de décider quelles sources ouvrir et lesquelles doivent attendre une preuve de contrôle plus complète.

Notre expertise IA sur mesure peut vous aider à qualifier l’assistance documentaire en posant la même question à plusieurs lecteurs, puis en modifiant leurs droits entre recherche et restitution. Les contrôles doivent couvrir le filtre avant classement, les passages déjà copiés, les citations et le cache. Les garanties du moteur retenu restent à vérifier séparément, notamment lorsque plusieurs clients partagent un index ; un refus applicatif ne certifie pas toute son isolation.