Le moindre privilège au niveau des données : l'autorisation relationnelle pour le RAG
Cet article fait partie de la série Les défis d’authentification et d’autorisation de l’IA agentique.
Tout ce qui a été couvert jusqu’ici dans cette série répond à une seule forme de question : cet agent peut-il appeler cette API. C’est nécessaire, mais c’est une question plus grossière que celle qui compte réellement une fois qu’un agent récupère des documents pour répondre à quelque chose en langage naturel. La question qui compte est : cet agent peut-il récupérer cet enregistrement précis, pour cet utilisateur précis, maintenant — et si la réponse est non, le système empêche-t-il réellement cet enregistrement d’atteindre le contexte du modèle, plutôt que de simplement journaliser qu’il n’aurait pas dû ? C’est la faille de scoping des données, et c’est celle le plus souvent découverte après une fuite plutôt qu’avant.
Pourquoi les scopes et les rôles sous-spécifient ce problème
Un scope comme documents:read ou un rôle comme « employé » répond bien à une question de niveau catégorie : cette classe de principal peut généralement lire cette classe de ressource. Aucun des deux ne répond à la question de niveau instance dont un pipeline de retrieval-augmented generation a réellement besoin avant d’assembler le contexte pour un modèle : parmi les millions de documents derrière cette API, lesquels précisément ce demandeur, agissant pour cet utilisateur précis, est-il actuellement autorisé à voir ?
Le contrôle d’accès basé sur les rôles a été conçu pour un monde où les permissions étaient relativement statiques et à granularité grossière — une poignée de rôles, chacun associé à une poignée de catégories de ressources. Il s’effondre précisément là où vit le RAG : des permissions qui varient par document, par dossier, par projet, par tenant dans un système multi-tenant, changeant constamment à mesure que les documents sont créés, repartagés et réorganisés. Tenter de forcer ce niveau de granularité dans une hiérarchie de rôles produit généralement soit une explosion de rôles (un nouveau rôle pour chaque combinaison significative d’accès aux documents), soit un repli vers des rôles trop larges accordant plus que prévu parce que modéliser la frontière précise en termes RBAC est devenu impraticable.
La conséquence pour un agent est précise et sérieuse : si la couche de retrieval ne peut pas répondre à la question de niveau instance, le modèle se retrouve avec des documents dans sa fenêtre de contexte que l’utilisateur demandeur n’a jamais été autorisé à voir. Rien dans cette défaillance ne ressemble, sur le moment, à un incident de sécurité conventionnel — pas d’échec d’authentification, pas d’appel API rejeté, pas d’erreur dans un journal. Le mauvais document devient simplement, silencieusement, partie intégrante d’une réponse. Le prompt injection aggrave cela, non pas en créant la faille de permission sous-jacente, mais en donnant à un attaquant un levier pour orienter activement un modèle vers la récupération ou la mise en avant de quelque chose auquel il avait techniquement accès mais qui n’était jamais censé être exposé — un levier qui ne fonctionne que si la couche de retrieval a d’abord échoué à restreindre l’ensemble des candidats.
Le pattern : le contrôle d’accès basé sur les relations
Le Relationship-Based Access Control (ReBAC), popularisé par le modèle derrière le système d’autorisation interne Zanzibar de Google, répond à une question différente, plus précise, que le RBAC. Plutôt que de stocker « l’utilisateur X a le rôle Y », il stocke des faits sous forme de tuples de relation — objet, relation, sujet — tels que « document 42, owned-by, utilisateur X » ou « dossier A, parent-of, document 42 » ou « utilisateur X, member-of, équipe B ». Une vérification d’autorisation parcourt alors ce graphe de relations en temps réel : existe-t-il un chemin reliant cet utilisateur précis à ce document précis, à travers une combinaison de propriété, d’appartenance à un groupe ou de conteneur hiérarchique, qui satisfait la relation demandée ?
C’est un sur-ensemble strict du RBAC, pas un remplacement — un rôle s’exprime facilement comme une relation (« utilisateur X, has-role, éditeur, on, document 42 »), donc la pensée basée sur les rôles existante n’est pas jetée, elle est absorbée dans un modèle plus riche qui peut aussi exprimer des relations que les rôles ne peuvent pas : « le dossier parent de ce document », « le propriétaire actuel », « un membre de l’équipe à laquelle appartient ce projet ». Beaucoup des distinctions qui exigeraient autrement de l’attribute-based access control — des attributs comme le département, l’ancienneté ou l’appartenance à un projet — s’avèrent également exprimables comme des relations, dès qu’on remarque que « le département de l’utilisateur » ou « le projet du document » sont eux-mêmes des faits relationnels, pas des propriétés statiques figées dans un token au moment de l’authentification.
Appliquer cela précisément au retrieval
L’élément qui compte spécifiquement pour les pipelines RAG agentiques : la vérification relationnelle doit s’exécuter avant qu’un document ne fasse partie de ce que voit le modèle, pas après, comme une validation a posteriori de la sortie du modèle. L’étape de retrieval devrait filtrer son ensemble de documents candidats pour ne garder que ce que le demandeur — l’agent, agissant pour un utilisateur précis, dans une session précise — est réellement autorisé à voir, et ce n’est qu’alors que cet ensemble restreint doit être transmis au modèle pour qu’il raisonne dessus.
Cela compte car cela change ce à quoi ressemble réellement une attaque réussie. Si le retrieval est correctement scopé, une tentative de prompt injection visant à exfiltrer des données ne peut jamais faire remonter que quelque chose auquel le demandeur avait déjà légitimement accès — la surface d’attaque se réduit à « cela peut-il divulguer des faits à l’intérieur du scope autorisé de l’utilisateur d’une façon non prévue », ce qui est un problème sensiblement plus petit et plus contenu que « cela peut-il divulguer n’importe quoi dans l’ensemble du stockage documentaire ». Le moindre privilège au niveau des données n’élimine pas le risque de prompt injection, mais il place une frontière stricte autour de ses conséquences.
Recommandations de conception
Modélisez les relations réelles, ne les forcez pas dans des rôles plats. Si votre modèle d’accès a régulièrement besoin de nouveaux rôles juste pour exprimer des combinaisons légèrement différentes de propriété, d’appartenance à une équipe ou de hiérarchie de dossiers, c’est le signe que le pattern d’accès sous-jacent est relationnel, pas basé sur les rôles, et le modéliser comme des rôles produit soit une explosion de rôles quasi identiques, soit des permissions plus larges que prévu.
Appliquez la vérification au moment du retrieval, comme un filtre, pas comme une étape d’audit après coup. La décision d’autorisation doit façonner quels documents entrent d’abord dans le contexte du modèle. Une vérification qui ne valide qu’après la génération — « le modèle avait-il le droit de dire ça » — arrive trop tard ; le document a déjà influencé la sortie au moment où cette vérification s’exécute.
Concevez pour une évaluation en temps réel à l’échelle, dès le départ. Un pipeline de retrieval servant des agents peut avoir besoin d’évaluer des décisions d’accès sur un ensemble de documents très large à chaque requête, pas occasionnellement dans un batch. Cela doit être un système conçu pour ce pattern d’accès — un service d’autorisation relationnelle construit à cet effet, évalué avec les mêmes exigences de performance que toute autre dépendance sur le chemin de requête — pas un ensemble de jointures ad hoc greffées sur une base de données applicative après coup.
Gardez la logique d’autorisation hors du code applicatif, et journalisez ce qui s’est réellement passé. Découpler le modèle relationnel de l’application de retrieval elle-même signifie que la politique d’accès peut être auditée, modifiée et raisonnée indépendamment de tout codebase unique — et, tout aussi important, cela signifie que vous pouvez journaliser quels documents précis ont été inclus ou exclus d’une décision de retrieval donnée, plutôt que de simplement journaliser que « l’appel API a réussi ». Quand quelqu’un finira par demander si un agent aurait dû pouvoir voir un document donné, ce journal fait la différence entre une réponse rapide et sûre et une reconstruction forensique de plusieurs jours.
Considérez cela comme complémentaire à tout le reste de la série, pas comme un substitut. Scoper correctement le retrieval ne supprime pas le besoin d’un principal agent correctement délégué et correctement identifié appelant l’API de retrieval en premier lieu — cela répond à une question un niveau plus profond que celles couvertes par les articles précédents de cette série, et cela dépend de la solidité de ces couches précédentes pour avoir la moindre importance.
Prochain article de la série : Gouverner les systèmes autonomes : auditabilité, non-répudiation et révocation, qui referme la boucle sur tout ce qui a été couvert jusqu’ici — non pas en empêchant un mauvais résultat sur le moment, mais en étant capable de prouver, après coup, exactement ce qui s’est passé et pourquoi.