RAG et droits d’accès : filtrer avant de répondre

Un assistant documentaire ne doit recevoir que les extraits que son utilisateur a le droit de consulter. Une réponse correcte sur un document interdit reste une fuite. Le problème ne se règle donc pas en demandant au modèle de rester discret : il se règle dans la chaîne qui sélectionne les données, puis dans celle qui conserve les réponses.

Cette distinction devient décisive lorsque le même assistant sert les ressources humaines, le juridique et les opérations. Tous utilisent une interface identique ; leurs droits restent différents. Le projet doit conserver cette différence après la copie des documents dans un index, après leur découpage et après la mise en cache. Voici une méthode pour concevoir et tester ce périmètre avant la mise en production.

L’authentification établit une identité ; l’autorisation décide quels documents cette identité peut consulter. Une connexion réussie à l’application ne donne pas accès à tout ce que son compte technique a indexé. Confondre ces deux contrôles transforme un moteur documentaire interne en point de concentration des droits.

Microsoft distingue les filtres de sécurité applicatifs des mécanismes natifs qui exploitent les permissions documentaires dans sa documentation Azure AI Search. Cette distinction impose de choisir un mécanisme compatible avec la source et l’identité de l’utilisateur, plutôt que de considérer l’index comme implicitement autorisé.

Prenons un cas fictif : une équipe commerciale consulte des procédures générales, tandis qu’une équipe RH accède aussi aux dossiers individuels. Le compte d’ingestion lit les deux ensembles. Le compte d’ingestion ne doit jamais devenir l’identité de recherche de tous les salariés. Le produit peut proposer une seule zone de saisie tout en imposant des périmètres différents derrière cette zone.

Le contrôle à documenter est simple : à partir de quelle identité la requête est-elle exécutée, et où la décision d’accès intervient-elle ? Une architecture incapable de répondre précisément à ces questions doit revenir au cadrage. Ce point entre dans le périmètre d’un audit IA centré sur les défauts du système, avant le choix d’un autre modèle ou d’un nouveau prompt.

Le filtre doit empêcher les documents interdits d’entrer dans le contexte transmis au modèle. L’application doit également éviter qu’ils deviennent accessibles par les extraits de recherche, les titres, les citations ou les appels d’outils. Retirer une information de la réponse finale arrive trop tard si cette information a déjà circulé ailleurs.

Dans son guide sur les filtres de recherche, Microsoft décrit le filtrage comme une opération qui détermine les documents admissibles au traitement de recherche. Pour un RAG, le périmètre autorisé est une contrainte de sélection, distincte du score de pertinence.

Une mise en œuvre applicative peut construire ce périmètre à partir d’un identifiant de locataire, d’un utilisateur et de groupes reconnus côté serveur. Ces valeurs ne viennent pas d’une phrase du visiteur. Une consigne comme « réponds en tant que directeur » ne change pas l’identité authentifiée. La requête métier et les paramètres d’autorisation doivent suivre des chemins séparés.

Le filtre doit couvrir toutes les branches. Ajouter un contrôle à la recherche vectorielle tout en laissant une recherche lexicale ou un téléchargement direct sans contrôle ouvre une autre entrée. Le même examen s’applique à une recherche hybride combinant mots-clés et vecteurs : la fusion des résultats ne remplace pas la vérification des droits de chaque branche.

Chaque extrait doit rester rattaché à un document source et à une politique d’accès exploitable. Le texte seul ne suffit pas. L’index doit permettre de retrouver l’origine, le périmètre concerné et la version de la règle qui a permis la sélection.

Le guide Microsoft sur l’application des ACL et rôles à la requête décrit notamment des champs filtrables portant les identifiants autorisés. Les capacités exactes dépendent de l’approche et de la source ; plusieurs intégrations natives sont encore présentées en préversion dans la documentation consultée.

Pour cadrer un projet, je propose de relever les informations suivantes dans le contrat d’ingestion. Ce sont des éléments de conception à adapter au système, pas une liste universelle imposée par un éditeur :

Le découpage documentaire doit préserver ce rattachement. Un extrait ne devient pas public parce qu’il a été détaché de son PDF. Un résumé enregistré comme un nouveau document doit lui aussi recevoir un périmètre cohérent avec les sources qu’il synthétise.

Des règles individuellement restrictives peuvent produire un ensemble de droits plus large une fois combinées. La vérification doit porter sur les permissions effectives de l’utilisateur, pas seulement sur le rôle que l’équipe vient de créer pour l’assistant.

Elastic précise que les privilèges de plusieurs rôles sont réunis dans sa documentation de gestion des rôles. Sa documentation sur le contrôle au niveau document et champ indique aussi qu’une permission d’index sans restriction documentaire donne accès à tous les documents de cet index.

Il faut donc tester une identité réelle avec tous ses groupes. Tester seulement un rôle isolé dans une console d’administration peut valider une restriction qui ne tient plus une fois l’utilisateur connecté. Les comptes de support, les administrateurs fonctionnels et les comptes de service méritent un examen distinct : ils cumulent souvent des capacités utiles à l’exploitation, mais inadaptées à une consultation ordinaire.

L’objectif n’est pas de rendre chaque opérateur aveugle. L’objectif est de distinguer clairement la consultation métier, l’administration technique et l’investigation d’un incident. Chacune doit avoir une justification et une trace. Une fonction de support qui ouvre une conversation passée doit contrôler l’accès au contenu de cette conversation.

Une révocation doit atteindre l’index, les caches et les résultats déjà stockés qui pourraient être servis à nouveau. Modifier la permission dans le système source sans examiner ces copies laisse une fenêtre pendant laquelle le produit applique encore l’ancienne situation.

Microsoft signale, pour certaines intégrations SharePoint en préversion, que des changements de permissions exigent une réindexation des documents concernés dans ses bonnes pratiques de sécurité. La synchronisation des droits doit donc être vérifiée dans la configuration réellement déployée. Une démonstration d’ingestion ne prouve pas la propagation d’une révocation.

Je recommande de définir une règle opérationnelle explicite : quel composant reçoit le changement, quelles copies sont invalidées et que fait le service tant que la mise à jour n’est pas confirmée ? Pour un document sensible, une réponse temporairement indisponible peut être préférable à une réponse servie sous une autorisation périmée. Cet arbitrage appartient au propriétaire du risque.

Un cache applicatif de réponses doit tenir compte du périmètre d’accès. Deux utilisateurs posant la même question ne peuvent pas nécessairement partager le même résultat. Une clé composée uniquement du texte de la question est insuffisante dans ce cas. La stratégie peut inclure une version de politique ou un identifiant de périmètre, puis une vérification avant restitution.

Un jeu de documents fictifs peut révéler les erreurs d’autorisation avant d’introduire des dossiers sensibles. Les documents doivent porter des marqueurs inventés et uniques, pour que le test distingue une fuite du contenu protégé d’une réponse générale trouvable ailleurs.

Préparez des profils qui partagent certains documents et en excluent d’autres. Ajoutez un document commun, un document réservé, une pièce révoquée et un document supprimé. Le jeu n’a pas besoin d’imiter toute l’entreprise ; il doit rendre les frontières observables. Conservez les mêmes questions pour chaque identité afin de comparer les décisions d’accès.

Le protocole proposé examine plusieurs sorties : les identifiants retournés par la recherche, les extraits réellement envoyés au modèle, la réponse, les citations et les traces conservées. Il ne suffit pas que la réponse publique soit vide. La pièce interdite ne doit pas apparaître dans un aperçu, une erreur technique ou une conversation réutilisée.

Deux mesures sont à suivre séparément : la présence de contenu interdit dans le parcours et la capacité à répondre avec les documents autorisés. Un système qui bloque toutes les réponses peut réussir le premier contrôle tout en étant inutilisable. La qualité du RAG se mesure à l’intérieur du périmètre autorisé, jamais en échange d’un élargissement silencieux de ce périmètre.

Une trace d’autorisation doit permettre d’expliquer pourquoi un extrait a été sélectionné sans recopier inutilement son contenu sensible. L’identité, la version de politique, les identifiants documentaires et la décision du filtre sont souvent plus utiles à l’investigation qu’une copie exhaustive du prompt.

La journalisation doit posséder son propre contrôle d’accès et sa propre politique de conservation. Transformer un journal technique en archive lisible par toute l’équipe annulerait une partie de la protection recherchée. Ce sujet complète le choix des événements décrit dans l’observabilité d’un système d’IA.

Le livrable attendu est un dossier de test reproductible : profils fictifs, documents témoins, versions des règles, résultats attendus et résultats obtenus. Il doit aussi préciser ce qui n’a pas été couvert. Un test réussi sur une source ne valide pas automatiquement une autre source, un autre connecteur ou une mémoire de conversation ajoutée ensuite.

Le pilote doit commencer avec une identité, une frontière documentaire et un comportement de révocation définis. Ces trois éléments rendent les tests interprétables. Le choix du modèle, la recherche hybride et le cache viennent ensuite soutenir une architecture dont le périmètre est déjà explicite. Sans ce cadre, une bonne démonstration ne dit presque rien sur la sécurité du service réel.