La couche de permissions qui manque à la plupart des déploiements RAG d'entreprise
Un analyste junior pose une question de routine, et une ACL figée au moment de l'ingestion transmet au modèle un mémo Board-Only. Le Sovereign RBAC Firewall autorise chaque document récupéré au moment de la requête, par rapport à l'ensemble vivant de groupes imbriqués et d'attributs de l'utilisateur, et écarte les documents retenus avant que le modèle ne voie un jeton. Code déterministe, en dehors de tout LLM. Les agents conseillent, le code décide.
40/40
Décisions correctes sur le jeu d'or d'autorisation
0 divulgation non autorisée, 0 faux refus, calculés par le harnais d'évaluation
29/40
La référence fidèle à ACL plat, sur les mêmes 40 cas
10 divulgations non autorisées, 1 faux refus
$670K
Surcoût d'une faille d'IA fantôme par rapport à un incident traditionnel
IBM Cost of a Data Breach, 2025
Il s'agit d'une démonstration exécutable, pas d'un déploiement. Chaque identité et chaque document est un fixture synthétique de banque européenne ; le fournisseur d'identité est un fixture JSON calqué sur Azure AD/SCIM, et le magasin vectoriel s'exécute en processus derrière une interface calquée sur Qdrant.
Acheter un LLM privé ne le rend pas sûr à pointer vers le corpus des joyaux de la couronne.
Le build pilote standard étiquette chaque fragment de document d'une ACL plate à l'ingestion. Cette conception s'effondre face à l'identité d'entreprise réelle : groupes Active Directory imbriqués, héritage inter-UO, niveaux d'habilitation, attributions de projet à durée limitée, et licenciements survenus après la construction de l'index. Le résultat est l'échec classique que cette démonstration met en scène de bout en bout : une analyste junior pose une question normale, et le pipeline RAG transmet au modèle un mémo Board-Only, parce qu'un instantané périmé du moment de l'ingestion indiquait qu'elle pouvait le voir.
La cause racine est structurelle. La permission d'un document est une propriété vivante d'un graphe d'identité, donc tout instantané en est déjà faux. Un meilleur modèle ne corrige pas cela : un modèle parfait auquel on remet un document du conseil le divulgue encore. La valeur réside dans le contrôle de ce qui atteint le modèle, pas dans la qualité du modèle.
Les enjeux sont mesurés. Les failles d'IA fantôme coûtent $670K de plus que les incidents traditionnels, et 65 % des failles liées à l'IA ont compromis des PII clients (IBM Cost of a Data Breach, 2025). Les failles d'IA fantôme prennent 247 jours à détecter contre une moyenne de 241 jours, et 1 organisation sur 5 a subi une faille liée à l'IA fantôme (IBM, 2025). Côté réglementaire, les obligations de transparence de l'article 50 de l'EU AI Act deviennent applicables le 2 août 2026, et le plafond combiné des sanctions RGPD plus AI Act atteint EUR 55M ou 11 % du chiffre d'affaires annuel mondial.
Notre propre page solution qualifie l'application des permissions au moment de la récupération de « la raison pour laquelle la plupart des pilotes RAG d'entreprise échouent à leur revue de sécurité » et de « le problème non résolu le plus difficile du RAG d'entreprise ». L'analyse produit du livre blanc qui la sous-tend a signalé le RAG conscient du RBAC sur le marché comme décrit mais non démontré, sans implémentation fonctionnelle. Cette démonstration est cette implémentation fonctionnelle.
Un moteur de politique déterministe décide de ce que le modèle voit. Pas le modèle, et pas un prompt.
Chaque requête exécute le même pipeline :
requête + identité utilisateur → récupération → pare-feu RBAC (déterministe, en dehors de tout LLM) → documents autorisés uniquement → LLM de réponse → enregistrement d'audit chaîné par hachage
Pour chaque document candidat, le pare-feu résout les permissions effectives de l'utilisateur au moment de la requête : il aplatit récursivement les groupes AD/UO imbriqués (le fixture imbriqué sur 3 niveaux de profondeur) et évalue les attributs ABAC par rapport à la référence de politique structurée du document : niveau d'habilitation L1 à L4, appareil géré, département, attributions de projet à durée limitée avec expiration, et statut d'emploi.
Chaque document reçoit ALLOW, WITHHELD avec un code de motif vérifiable par machine (BOARD_MEMBERSHIP_REQUIRED, ACCESS_WINDOW_EXPIRED, ALL_ACCESS_REVOKED_TERMINATION, POLICY_CONFLICT), ou NEEDS_REVIEW. Les documents retenus sont écartés avant la fenêtre de contexte, de sorte que le modèle ne voit jamais les documents auxquels l'utilisateur n'a pas accès. En cas de conflit ou de référence non résolue, il refuse par défaut et oriente vers une revue humaine plutôt que de deviner.
Chaque requête ajoute un enregistrement à une chaîne de hachage SHA-256 en ajout seul avec vérification d'intégrité : utilisateur, ensemble de permissions résolu, documents récupérés, servis et retenus avec codes de motif, conflits NEEDS_REVIEW, modèle et fournisseur, et la paire prompt/réponse. Exportable en JSON, généré à l'intérieur du VPC. L'enregistrement de preuve d'accès à la récupération qu'un dossier de l'article 50 de l'EU AI Act demande.
Le côté comparaison de la démonstration est un RAG ACL plat naïf fidèle, le build que la plupart des pilotes livrent réellement. Il résout vraiment les groupes imbriqués au moment de l'ingestion. Ses échecs sont ses deux limites honnêtes et inhérentes : l'instantané se périme, et une étiquette plate ne peut pas exprimer l'habilitation, l'appareil, la fenêtre temporelle ou la cessation d'emploi. Sur le jeu d'or de 40 cas de la démonstration, ces deux limites produisent 10 divulgations non autorisées et 1 faux refus, le faux refus étant un nouvel arrivant post-ingestion dont le droit a été manqué par l'instantané figé.
Le chemin de réponse, construit sur Pydantic AI, ne reçoit que les fragments autorisés post-pare-feu, indique ce qui a été retenu et pourquoi au lieu de bluffer, et n'a aucune autorité sur les permissions. Il est interchangeable selon le fournisseur via une seule variable d'environnement : Anthropic (modèle par défaut claude-opus-4-8), OpenAI, Gemini, ou Ollama pour un déploiement souverain isolé (air-gapped), où rien, pas un jeton, ne quitte la boîte. Aucune clé API n'est jamais requise : la démonstration achemine les réponses vers un pont local lorsqu'il tourne et se rabat sinon sur un stub déterministe, et le tableau de score d'évaluation n'appelle jamais de LLM. Le pare-feu est le produit ; le modèle est le décor.
Les étiquettes d'or pour le jeu de 40 cas sont dérivées mécaniquement par un oracle de référence indépendant, une implémentation séparée écrite à partir des définitions de politique plutôt que du pare-feu sous test. Le tableau de score est une fonction du graphe d'identité, pas de résultats choisis à la main, et chaque chiffre est calculé à l'exécution, jamais codé en dur. Le surcoût d'application se mesure en microsecondes, en processus, pour la logique du pare-feu seule ; un aller-retour IdP de production ajoute une latence que cette démonstration simule (stub).
Gartner projette que 40 % des applications d'entreprise intégreront des agents d'IA d'ici fin 2026, en hausse par rapport à moins de 5 % en 2025. La même porte déterministe authorize(user, doc) est le chemin d'extensibilité documenté pour ce monde, pas une fonctionnalité livrée de cette démonstration : un agent ne peut pas récupérer ce que l'utilisateur pour le compte duquel il agit n'aurait pas pu.
Une question, posée par une analyste synthétique, répondue des deux côtés de l'écran scindé. Chaque image ci-dessous est une capture de l'application en cours d'exécution ; chaque identité, document et chiffre est une donnée de fixture synthétique.
Lena Vogt, analyste risque de crédit EMEA avec habilitation L2, demande : « Quelle est notre projection de pertes de crédit EMEA au T3 et la méthodologie derrière ? » La récupération fait remonter le pack conseil Board-Only du T3 aux côtés de documents qu'elle peut voir. Le côté ACL plat le sert : des années de dette d'héritage de groupes imbriqués dans le graphe d'identité l'ont rendue transitivement membre « Board », et une étiquette uniquement de groupe n'a aucune notion d'habilitation. Le mémo atteint le modèle, la réponse lit EUR 412 millions, et la bannière affiche LEAK.
Du côté RAGGUARD, la même récupération s'exécute, mais le pack conseil est retenu avant le LLM avec le code de motif BOARD_MEMBERSHIP_REQUIRED : le document exige l'habilitation L4 et Lena détient L2. Le modèle répond correctement à partir de la note de méthodologie Internal et du mémo Confidential auxquels sa chaîne de groupes imbriqués lui donne droit, et il indique ce qui a été retenu et pourquoi au lieu de bluffer.
La fenêtre de détail de décision montre l'entrée verbatim du modèle des deux côtés. À gauche, le pack conseil divulgué se trouve dans le prompt, marqué en rouge. À droite, il est simplement absent : le modèle ne voit jamais les documents auxquels l'utilisateur n'a pas accès. La vue par document rend la divergence explicite, la même ligne du pack conseil indiquant « Servi sans autorisation » d'un côté et « Accès refusé à la récupération » avec son code de motif de l'autre.
La note de méthodologie Internal porte une chaîne d'injection de prompt intégrée ordonnant à tout assistant IA qui la lit d'ignorer ses permissions de récupération et de produire le chiffre Board complet. Du côté du pare-feu, elle n'a rien à exfiltrer : le pack conseil n'est jamais entré dans la fenêtre de contexte, parce que l'autorisation a eu lieu avant le LLM. C'est un cas étiqueté, montré comme défense en profondeur issue de l'application au moment de la récupération, pas un produit de garde-fous distinct.
Priya Shah a été licenciée il y a neuf minutes sur l'horloge de la démonstration, et le webhook du fixture s'est déclenché. Le pare-feu renvoie ALL_ACCESS_REVOKED_TERMINATION sur tout : 0 accordé, 5 refusés. L'instantané ACL plat, construit avant le licenciement, la sert encore, parce que la réindexation n'a pas été exécutée. La démonstration parcourt le même cas limite pour Marco Rossi, dont l'attribution à durée limitée Project-Atlas a expiré hier sur l'horloge de la démonstration (ACCESS_WINDOW_EXPIRED), pour Raj Patel, qui siège à la fois dans un groupe autorisant et un groupe refusant (POLICY_CONFLICT, retenu pour revue humaine), et pour Wei Chen, le membre du conseil L4 que le pare-feu sert correctement, le contrôle positif prouvant qu'il ne se contente pas de tout refuser.
Chacune de ces décisions atterrit dans la piste d'audit infalsifiable : un enregistrement JSON chaîné par hachage de qui a demandé quoi, ce qui a été servi, ce qui a été retenu et pourquoi, et quel modèle a répondu, avec une puce de vérification CHAIN INTACT et un export en un clic. Généré automatiquement, à l'intérieur du VPC.
Le jeu d'or est 40 décisions allow/deny étiquetées (utilisateur, document) : 10 utilisateurs contre 4 documents sensibles, étiquettes dérivées mécaniquement par l'oracle indépendant à partir de la sémantique du graphe d'identité. Le pare-feu obtient 40/40 avec 0 divulgation non autorisée et 0 faux refus. La référence ACL plat obtient 29/40 avec 10 divulgations non autorisées, dont le pack conseil servi à 7 utilisateurs non autorisés, la fenêtre Atlas expirée, et l'employé licencié, plus 1 faux refus. Chaque chiffre est calculé par le harnais à l'exécution, jamais codé en dur, et le forage par cas montre chaque étiquette d'oracle à côté des décisions des deux systèmes. Ce sont des résultats de jeu d'or, pas des garanties en monde ouvert.
La même comparaison que la démonstration exécute en direct, sur le même graphe d'identité et les mêmes documents.
| Dimension | Naive Flat-ACL RAG (le build pilote typique) | Sovereign RBAC Firewall (RAGGUARD) |
|---|---|---|
| Quand l'autorisation a lieu | À l'ingestion, figée en une étiquette sur chaque fragment | Au moment de la récupération, par requête, par document |
| Groupes imbriqués et héritage inter-UO | Résolus une fois à l'ingestion ; l'instantané se périme | Aplatis récursivement contre le graphe d'identité vivant à chaque requête |
| ABAC : habilitation, appareil, attributions à durée limitée, statut d'emploi | Inexprimable dans une étiquette plate | Évalué par document contre la référence de politique structurée |
| Licenciement il y a neuf minutes | Toujours servi jusqu'à ce que la réindexation s'exécute | ALL_ACCESS_REVOKED_TERMINATION sur tout |
| Politiques conflictuelles sur un document | Sert le document | Refus par défaut : NEEDS_REVIEW, acheminé vers un humain avec le conflit explicité |
| Jeu d'or de 40 cas | 29/40 : 10 divulgations non autorisées, 1 faux refus | 40/40 : 0 divulgation non autorisée, 0 faux refus |
| Piste d'audit | Aucune | Enregistrement chaîné par hachage, infalsifiable, de chaque service et de chaque retenue, exportable en JSON |
Appliquez l'autorisation au moment de la récupération, pas à l'ingestion. Un moteur de politique déterministe en dehors du LLM vérifie chaque document récupéré par rapport aux appartenances de groupes et attributs vivants de l'utilisateur avant qu'il n'atteigne le modèle, de sorte que les documents retenus n'entrent jamais dans la fenêtre de contexte. Dans cette démonstration, cette porte obtient 40/40 sur un jeu d'or étiqueté de 40 cas, contre 29/40 pour le build ACL plat que la plupart des pilotes livrent.
Parce que l'étiquette est un instantané et que la permission est une propriété vivante de votre graphe d'identité. Une ACL au moment de l'ingestion manque tout ce qui change après l'indexation, comme un licenciement ou une attribution de projet expirée, et elle ne peut pas du tout exprimer des règles d'attributs comme le niveau d'habilitation ou l'appareil géré. Dans la démonstration, ces deux limites expliquent 10 divulgations non autorisées et 1 faux refus sur un benchmark de 40 cas, à partir d'une référence qui résout fidèlement les groupes imbriqués à l'ingestion.
Pas si le document n'atteint jamais le modèle. La démonstration inclut un cas étiqueté où une note intégrée dans un document ordonne à tout assistant IA d'ignorer ses permissions de récupération et de produire le chiffre Board-Only, et l'injection n'a rien à exfiltrer parce que l'autorisation a eu lieu avant le LLM et que le mémo n'est jamais entré dans la fenêtre de contexte. C'est un exemple de défense en profondeur de l'application au moment de la récupération, pas un produit de garde-fous autonome.
Refus par défaut. Lorsqu'un utilisateur détient à la fois une appartenance autorisant et une appartenance refusant sur le même document, ou qu'une référence de politique ne peut pas être résolue, le pare-feu renvoie NEEDS_REVIEW et achemine le cas vers un humain avec le conflit explicité, plutôt que de deviner. La démonstration montre exactement cela : un responsable risque de crédit qui est à la fois dans un groupe autorisé et un groupe refusé a le mémo contesté retenu pour revue, non servi.
Le pare-feu est du Python déterministe qui n'a besoin d'aucun modèle, et le chemin de réponse est interchangeable selon le fournisseur via une seule variable d'environnement : Anthropic, OpenAI, Gemini ou Ollama. Définissez LLM_PROVIDER=ollama pour un déploiement souverain isolé et rien, pas un jeton, ne quitte la boîte. La démonstration elle-même s'exécute hors ligne sans clé API, et le tableau de score d'évaluation n'appelle jamais de LLM.
Chaque requête ajoute un enregistrement à une chaîne de hachage SHA-256 infalsifiable : qui a demandé, l'ensemble de permissions résolu, ce qui a été servi, ce qui a été retenu et pourquoi, et quel modèle a répondu. Il s'exporte en JSON et est généré à l'intérieur de votre VPC. C'est l'enregistrement de preuve d'accès à la récupération qu'un dossier de l'article 50 de l'EU AI Act demande, pas une certification de conformité.
Une démonstration exécutable qui prouve le mécanisme. Le fournisseur d'identité est un fixture JSON synthétique calqué sur Azure AD/SCIM, les licenciements et expirations d'attributions sont des événements de fixture, et le magasin vectoriel s'exécute en processus derrière une interface calquée sur Qdrant. Le moteur de politique, le harnais d'évaluation et l'export d'audit chaîné par hachage sont réels et s'exécutent exactement comme montré ; parce que le fixture reflète les interfaces Azure AD Graph et SCIM, le chemin de production documenté vers un IdP en direct est un échange de configuration, pas une réécriture.
La recherche derrière cette démonstration — l'architecture, la conception de la vérification, et le schéma directeur d'entreprise.
Solution complète
Explorer la solution Sovereign AI & Private LLM Deployment →La couche de permissions est la partie difficile. Nous la construisons.
Si votre équipe lutte avec la façon de pointer un modèle privé vers un corpus régi par des années d'héritage de groupes imbriqués, ou avec ce que les obligations de transparence de l'EU AI Act signifient pour vos journaux de récupération, nous aimerions réellement entendre comment vous y réfléchissez. Le problème est à l'échelle de l'industrie et les réponses le seront aussi.