Contrôle d'accès RAG : vérifier les droits en temps réel
Le contrôle d'accès RAG est en train de devenir le vrai sujet des assistants IA d'entreprise. Le 7 octobre 2026, AWS a publié un retour d'expérience sur la manière dont Amazon Quick et Amazon Bedrock Knowledge Bases vérifient désormais les permissions des documents en temps réel, au moment même où l'utilisateur pose sa question. Ce n'est pas une nouveauté spectaculaire sur le papier. C'est pourtant l'aveu, par un grand fournisseur cloud, que le modèle dominant jusqu'ici, copier les droits dans l'index puis filtrer, ne suffit pas.
Pour une équipe qui industrialise un RAG branché sur SharePoint, Google Drive ou Confluence, la question n'est plus « est-ce que l'assistant trouve la bonne réponse ? » mais « est-ce que l'assistant a le droit de la montrer à cette personne, maintenant ? ». Cet article décortique l'approche, ses limites et ce qu'elle implique pour vos propres pipelines.
Le contexte
Un système RAG (Retrieval Augmented Generation) fonctionne en deux temps. D'abord, il cherche dans une base de documents les passages les plus proches de la question, généralement via une recherche sémantique dans un index vectoriel. Ensuite, il donne ces passages à un LLM comme contexte pour rédiger la réponse.
Le problème de sécurité est simple à formuler : le LLM ne sait rien des permissions. Si un passage d'un document confidentiel arrive dans son contexte, il peut le résumer, le citer ou le paraphraser dans la réponse. Tout le contrôle d'accès doit donc se jouer avant que le passage n'atteigne le modèle.
AWS résume l'enjeu sans détour : un seul document non autorisé dans une réponse IA peut exposer des documents de stratégie confidentiels, des données financières non publiées ou des informations RH sensibles. L'OWASP classe d'ailleurs ce risque dans son Top 10 des applications LLM 2025, sous l'entrée LLM08 : faiblesses des vecteurs et des embeddings, qui cite explicitement l'accès non autorisé et les fuites entre groupes d'utilisateurs dans une base vectorielle partagée.
Pourquoi le contrôle d'accès RAG par réplication des ACL ne suffit plus
La méthode la plus répandue consiste à copier les listes de contrôle d'accès (ACL) des sources dans l'index. Chaque fragment de document est stocké avec des métadonnées du type « visible par tel groupe ». Au moment de la recherche, on filtre sur ces métadonnées. C'est rapide, c'est simple, et c'est ce que proposent la plupart des bases vectorielles.
AWS identifie trois faiblesses structurelles à ce modèle.
La copie des droits ne fait pas autorité
L'index n'est pas la source de vérité des permissions : c'est une copie. Le connecteur doit traduire fidèlement des modèles de droits très différents d'une source à l'autre. Les partages de Google Drive, les héritages de sites SharePoint et les restrictions de pages Confluence n'obéissent pas aux mêmes règles. Chaque traduction est une occasion d'erreur.
Les droits sont périmés entre deux synchronisations
Les ACL sont récupérées par des tâches de synchronisation périodiques. Entre deux passages, l'index reflète un état ancien. Comme le dit l'article, un utilisateur dont l'accès a été révoqué peut continuer à recevoir des réponses construites à partir de documents qu'il ne devrait plus voir. Le cas typique : un collaborateur change d'équipe, ou quitte un projet sensible, et son assistant IA continue de puiser dans les documents de l'ancien périmètre jusqu'à la prochaine synchronisation.
La logique des connecteurs est fragile
Quand une source ajoute une nouvelle fonctionnalité de permission, le connecteur ne la connaît pas encore. Tant qu'il n'est pas mis à jour, il existe un trou dans l'application des droits. Ce trou est silencieux : rien ne casse, les réponses continuent d'arriver.
L'architecture en deux étapes proposée par AWS
La réponse d'AWS n'est pas d'abandonner le filtrage dans l'index, mais de lui ajouter une seconde barrière.
Étape 1 : le préfiltrage dans l'index
Amazon Quick effectue d'abord sa recherche sémantique dans un index vectoriel qui stocke des attributs de contrôle d'accès. Cette étape produit une liste de documents candidats, déjà réduite aux documents que l'utilisateur est censé pouvoir lire selon la dernière synchronisation.
AWS justifie le maintien de cette étape par le coût : appeler en temps réel l'API de la source pour chaque document de l'index serait trop coûteux à grande échelle. Le préfiltrage sert donc à réduire le volume, pas à garantir la sécurité.
Étape 2 : la vérification en temps réel auprès de la source
Pour les seuls documents candidats, le système interroge ensuite les API de la source faisant autorité. Dans l'exemple détaillé par AWS, il s'agit des API Google Drive. La vérification utilise un compte de service et l'impersonation de l'utilisateur, ce qui permet de demander à Google Drive, au nom de cette personne précise, si elle a accès au document. Seuls les passages autorisés atteignent ensuite le LLM.
Résultat annoncé : une révocation de droit se répercute dans les réponses de l'IA « en quelques instants, pas en heures ou en jours ». AWS cite le déploiement chez Mondelēz International, où plus de 35 000 collaborateurs répartis sur quatre régions utilisent Amazon Quick.
L'article indique que cette vérification en temps réel s'ajoute au préfiltrage pour Amazon Quick et pour Amazon Bedrock Knowledge Bases. En revanche, seul le cas Google Drive est détaillé : l'article ne précise ni la liste des connecteurs couverts, ni le comportement en cas d'indisponibilité de l'API source, ni le surcoût de latence. Avant de vous appuyer dessus, vérifiez ces points dans la documentation de votre service.
Contrôle d'accès RAG en temps réel : coûts et angles morts
Le double contrôle a un prix. Chaque requête déclenche des appels supplémentaires vers les API des sources. Trois conséquences pratiques en découlent.
La latence. Une vérification par document candidat ajoute un aller-retour réseau, même si les appels sont parallélisés. Sur un assistant conversationnel, chaque centaine de millisecondes compte.
Les quotas. Les API de Google Drive, de Microsoft Graph ou de Confluence ont des limites de débit. Un assistant utilisé par des milliers de personnes peut consommer une part significative de ces quotas, au détriment d'autres intégrations.
La disponibilité. Si l'API source répond mal, il faut choisir : refuser la réponse (sécurité d'abord) ou se rabattre sur les droits en cache (disponibilité d'abord). AWS n'aborde pas ce cas. Dans un contexte où la fuite est le risque principal, le choix par défaut devrait être de refuser.
Ce modèle ne règle pas non plus deux risques voisins. Le premier est la fuite par le contenu indexé lui-même : si un document mal classé est accessible à tous dans la source, la vérification en temps réel confirmera qu'il est accessible à tous. Le second est l'empoisonnement de l'index, que l'OWASP range dans la même catégorie LLM08 : un document piégé, légitimement accessible, peut toujours injecter des instructions dans le contexte.
Ce que ça change pour les équipes IA
Vous n'utilisez pas forcément Amazon Quick, mais le schéma est réutilisable dans n'importe quel pipeline RAG. Voici ce que nous recommandons de vérifier sur un projet en production.
Traitez l'index comme un cache, pas comme une autorité. Les ACL stockées dans votre base vectorielle servent à réduire l'espace de recherche. La décision finale doit revenir à la source, ou à défaut à un service d'autorisation qui en est le reflet fidèle et récent.
Mesurez l'écart de synchronisation. Combien de temps s'écoule entre une révocation dans SharePoint et sa prise en compte par votre assistant ? Si vous ne savez pas répondre, c'est la première chose à instrumenter. Un test simple : retirer un accès à un compte de test et chronométrer le moment où l'assistant cesse de citer le document.
Limitez la vérification aux candidats. Le contrôle d'accès RAG en temps réel n'est tenable que s'il porte sur une poignée de documents par requête. Gardez un top-k raisonnable avant vérification, et mettez en cache les décisions positives sur une durée courte, de l'ordre de la minute, en assumant explicitement ce délai.
Décidez du comportement en cas de panne. Documentez ce que fait l'assistant quand l'API source ne répond pas, et testez-le. Un refus clair (« je ne peux pas vérifier vos droits sur ces documents pour le moment ») vaut mieux qu'une fuite silencieuse.
Tracez chaque décision. Pour chaque réponse, conservez la liste des documents candidats, ceux qui ont été écartés et la raison. L'OWASP recommande des journaux d'audit immuables des accès en lecture. C'est aussi ce qui vous permettra de répondre à un DPO ou à un audit après un incident.
Testez avec des comptes à droits différents. Les jeux d'évaluation RAG mesurent presque toujours la pertinence des réponses, rarement le respect des droits. Ajoutez des cas de test où la bonne réponse est « je n'ai pas accès à cette information » pour un profil donné.
Ces points s'intègrent naturellement dans une démarche MLOps : le contrôle d'accès RAG devient une propriété mesurable du système, suivie comme la latence ou le coût par requête.
En bref
- AWS ajoute une vérification des permissions en temps réel, auprès de la source, au filtrage classique dans l'index vectoriel, pour Amazon Quick et Amazon Bedrock Knowledge Bases.
- Le préfiltrage par ACL répliquées reste utile pour la performance, mais il est périmé entre deux synchronisations et dépend de connecteurs fragiles.
- Le gain annoncé : une révocation prise en compte en quelques instants. Le prix : latence, quotas d'API et une politique à définir en cas de panne de la source.
- L'OWASP classe ces risques sous LLM08 et recommande des bases vectorielles sensibles aux permissions et des journaux d'audit.
- Pour vos propres pipelines, le contrôle d'accès RAG doit être mesuré, testé avec plusieurs profils et tracé, comme toute autre propriété de production.
Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.
Photo de couverture : Photo by Towfiqu barbhuiya on Unsplash.