Appliquer les permissions documentaires avant ou pendant la recherche RAG, jamais après
Le filtre d'autorisation est calculé côté serveur à partir de l'identité SSO et imposé au moteur de recherche ; un prompt système n'est jamais une protection.
- Identifiant
- ADR-003
- Statut
- Acceptée
- Date
- 16 septembre 2026
- Décision
- Chaque chunk porte ses ACL en métadonnées ; toute recherche vectorielle ou lexicale est pré-filtrée par ces ACL à partir de l'identité authentifiée ; une seconde barrière est imposée par le moteur (filtre JWT Qdrant ou RLS PostgreSQL).
- Options étudiées
- Filtrage par le prompt système
- Post-filtrage des résultats dans l'application
- Pré-filtrage par métadonnées ACL + barrière dans le moteur
- Une base vectorielle par dossier
Contexte
Dans un cabinet d'avocats, un avocat ne doit jamais obtenir, même par recoupement, une information d'un dossier auquel il n'a pas accès. Le RAG est précisément un mécanisme qui va chercher des passages dans tous les documents indexés : sans filtre, il devient une machine à fuites. Les CVE publiées en 2026 sur le contrôle d'accès aux fichiers et aux connaissances d'Open WebUI (dont CVE-2026-44560, requêtes vectorielles sans vérification d'autorisation) montrent qu'un contrôle uniquement applicatif est fragile.
Options étudiées
- Prompt système (« ne réponds qu'avec les dossiers de l'utilisateur ») : aucune garantie, contournable par injection ; rejeté.
- Post-filtrage : on cherche dans tout, puis on retire les passages interdits. Les passages interdits ont déjà été lus par l'application ; le top-k est faussé ; une erreur de code suffit à fuir. Rejeté comme mécanisme principal.
- Pré-filtrage par ACL : le filtre fait partie de la requête au moteur ; les passages interdits ne sont jamais retournés. Retenu.
- Isolation physique par dossier (une collection par dossier) : robuste mais lourd à exploiter quand un utilisateur accède à des dizaines de dossiers ; conservée comme option pour des clients isolés (multi-tenant).
Décision
- Chaque document et chaque chunk portent des métadonnées d'autorisation (dossier, groupes autorisés, client).
- L'identité vient du SSO ; le filtre est calculé côté serveur, jamais fourni par le client.
- Le filtre est imposé par le moteur lui-même en seconde barrière : JWT avec filtre de payload obligatoire dans Qdrant, ou Row-Level Security dans PostgreSQL/pgvector.
- Toute révocation de droit déclenche une resynchronisation des métadonnées.
- Un test automatique de non-fuite (« l'avocat B ne voit jamais un passage du dossier A ») fait partie de la recette de chaque version.
Pourquoi
C'est le consensus documenté des acteurs du domaine (Azure AI Search, AWS Bedrock, Glean, Pinecone, OWASP LLM08:2025) et la seule approche qui résiste à une erreur applicative isolée.
Conséquences
- Le choix de la base vectorielle dépend de sa capacité à imposer un filtre côté serveur (Q-004).
- L'interface de chat doit accepter un RAG externe qui applique ces règles, ou fournir des garanties équivalentes (Q-005).
- La propagation des ACL depuis la source (SMB, SharePoint) devient un composant à part entière du pipeline d'ingestion.