Chapitre 7 — Implémenter le contrôle d'accès

Septième billet de la tournée chapitre par chapitre de LLM Primer III : Améliorer l'IA d'entreprise avec RAG. Les modèles de permissions conçus pour les bases de données relationnelles et les systèmes de fichiers ne s'ajustent pas tout à fait à la recherche. L'unité d'accès n'est plus une ligne ou un fichier mais un embedding — et un embedding peut faire fuiter l'original par similarité même quand le document lui-même est verrouillé.

Pourquoi ce chapitre existe

Le Chapitre 6 a produit le modèle de menaces. Le contrôle le plus important qu'il implique — et celui que la plupart des premiers systèmes de production se trompent — est le contrôle d'accès à la couche de recherche, pour que le LLM ne voie jamais de contenu auquel l'utilisateur n'a pas accès. L'alternative naïve, « filtrer au moment de la génération », fabrique un deputy confus : le modèle a déjà lu les documents verrouillés et fera fuiter leur substance par paraphrase.

Ce chapitre parcourt les quatre mécanismes qui se composent en une pile de contrôle d'accès fonctionnelle — les ACL au niveau document comme fondation, le RBAC intégré aux étiquettes de sensibilité existantes de l'entreprise, le ReBAC pour la réalité en forme de relation de la connaissance d'entreprise, et la discipline pré-filtre contre post-filtre qui tourne sous tous.

7.1 ACL au niveau document et filtrage par métadonnées

Chaque morceau sait qui a le droit de le voir. La mise en œuvre est simple à décrire ; les modes d'échec sont assez subtils pour que presque tout premier système de production se trompe au moins une fois. Trois détails comptent le plus. La granularité : un long rapport peut avoir un résumé public et une annexe confidentielle, et une seule ACL au niveau document copiée uniformément vers les morceaux soit sur-partage l'annexe, soit sous-partage le résumé. Le patron qui passe à l'échelle est de porter les permissions au niveau section à travers une analyse sensible à la mise en page.

La fraîcheur : les permissions changent. Inscrire l'ACL dans le morceau au moment de l'indexation et ne jamais la réévaluer donne un système qui ment. Stockez un identifiant stable dans les métadonnées du morceau et résolvez l'ACL en direct contre le système source au moment de la requête, derrière un cache à courte durée de vie. L'espace négatif : si la réponse vit dans un document verrouillé, le système ne devrait pas halluciner ni dire avec confiance « je ne sais pas » — il devrait dire « il existe du matériel sur ce sujet que vous n'êtes pas autorisé à voir ». Cela exige soit un second appel non filtré, soit une base vectorielle qui distingue « pas de match » de « matché mais filtré », et la plupart des implémentations dégagent.

7.2 RBAC et les étiquettes de sensibilité Microsoft Purview

Le RBAC compresse l'espace des permissions — au lieu de millions d'arêtes utilisateur-vers-document, la politique se réduit à quelques centaines d'arêtes rôle-vers-classification, ce qui est à la fois auditable et maintenable. Il s'adapte proprement au RAG quand l'entreprise tourne déjà dessus. Dans les environnements Microsoft, cela signifie groupes Entra ID et étiquettes de sensibilité Purview : Public, Général, Confidentiel, Hautement Confidentiel, avec des sous-étiquettes optionnelles. L'étiquette se déplace avec le document ; le parseur la lit au moment de l'indexation et écrit l'ID stable d'étiquette dans les métadonnées du morceau.

L'intégration est simple, la dérive ne l'est pas. Si l'indexeur tourne comme un compte de service qui peut tout déchiffrer mais que le système de recherche applique un filtre par rôle au-dessus de l'index, un document réétiqueté de Général à Confidentiel n'aura pas ses morceaux déjà indexés ré-étiquetés à moins que l'indexeur ne remarque le changement. Les systèmes qui réussissent cela font tourner une réconciliation continue contre la source. Ceux qui se trompent découvrent la dérive lors d'un audit, et la conclusion est sévère.

7.3 ReBAC avec Zanzibar et SpiceDB

Le RBAC ne peut pas exprimer « toute personne du Service Ventes qui est aussi assignée au dossier Acme Corp ». Cela demande de raisonner sur une relation entre l'utilisateur et la ressource, pas seulement sur un rôle. Le contrôle d'accès basé sur les relations, formalisé dans l'article Zanzibar de Google et disponible en open source sous SpiceDB et OpenFGA, stocke un graphe : « Alice est membre d'Ingénierie », « Ingénierie est lecteur du dossier Specs », « Spec-101 est dans Specs ». Les vérifications de permissions deviennent des traversées de graphe.

Le patron d'intégration avec RAG est propre. SpiceDB reçoit la question quels documents cet utilisateur peut-il voir ? et renvoie une liste d'identifiants de documents ; le système de recherche passe cette liste comme filtre de métadonnées à la recherche vectorielle. Les zookies de Zanzibar permettent à l'appel de recherche d'exiger une cohérence au moins aussi récente qu'un accès fraîchement accordé — un utilisateur ajouté à un projet à 10:00 et qui pose une question à 10:01 verra les nouveaux documents. Le coût opérationnel est que SpiceDB devient une dépendance critique du chemin de requête qui a besoin de haute disponibilité et d'un cache agressif à courte TTL des listes de documents par utilisateur. Les systèmes mûrs utilisent souvent à la fois RBAC et ReBAC — RBAC pour la politique de sensibilité large, ReBAC pour la politique de relation fine, combinés comme l'intersection des ensembles autorisés.

7.4 Pré-filtre, post-filtre, et la discipline qui tourne sous les deux

Le pré-filtrage applique le prédicat d'autorisation avant la recherche vectorielle — l'index restreint d'abord l'ensemble de candidats, puis lance la similarité sur la restriction. C'est conceptuellement propre et le défaut le plus sûr, mais sa performance dépend de la structure d'index. HNSW avec un filtre très sélectif peut se dégrader fortement à mesure que la traversée du graphe passe par beaucoup de nœuds non matchants ; les variantes filtrables-HNSW de Weaviate et Qdrant et les espaces de noms par tenant de Pinecone et Milvus atténuent mais n'éliminent pas le coût.

Le post-filtrage inverse l'ordre. Pleine vitesse HNSW, sécurité plus faible : la fuite par le top-K, la fuite d'information par timing, et la fuite de correction quand tout le top-K est filtré. La réponse pragmatique de production est de superposer les deux — pré-filtrer sur le prédicat le plus grossier et le plus rapide (tenant, rôle large), post-filtrer sur les prédicats précis et coûteux (listes SpiceDB, étiquettes Purview), et sur-fetcher le top-50 au lieu du top-10 pour que le post-filtre laisse encore un ensemble classé complet. Deux autres endroits fuient : le gabarit de prompt qui cite le titre d'un document confidentiel, et le cache de réponse à clé seulement sur la chaîne de requête. Les deux doivent faire partie de la surface d'autorisation.

Ce que prépare le Chapitre 7

Le contrôle d'accès répond à qui peut voir quoi. Il suppose qu'il y a quelque chose à verrouiller. Il ne demande pas si le morceau aurait dû être embarqué dans la forme qu'il a — si les noms de clients, les numéros de sécurité sociale, les chemins de code propriétaires devaient être dans le magasin de vecteurs, attendant la bonne autorisation pour remonter. C'est la question de l'anonymisation, et c'est le sujet du chapitre suivant.

Prochaine étape — Chapitre 8 : Anonymisation des données dans la chaîne RAG. Pré-génération contre post-génération, masquage contre remplacement synthétique contre confidentialité différentielle, et le compromis utilité-confidentialité que chaque choix doit naviguer.