La couche de permissions qui manque à la plupart des déploiements RAG d'entreprise

Votre LLM privé ne fuit pas. C'est votre couche de récupération qui fuit.

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.

Le pilote réussit la démonstration. Puis il échoue à la revue de sécurité.

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.

Comment fonctionne le Sovereign RBAC Firewall

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

1. Résolution des permissions en direct

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.

2. Un verdict déterministe

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.

3. Le reçu

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.

La référence qu'il bat n'est pas un épouvantail

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 LLM est un décor interchangeable

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.

Le tableau de score est indépendant

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).

Un unique goulot d'étranglement, prêt pour les agents

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.

La fuite de EUR 412 millions, traitée de bout en bout

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.

La question qui fuit

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.

La fuite en écran scindé : le côté Naive Flat-ACL lit la projection Board-Only de EUR 412 millions à l'analyste L2 Lena Vogt, avec une bannière rouge LEAK et un avertissement qu'1 document non autorisé a été servi, tandis que le côté RAGGUARD affiche 5 récupérés, 2 accordés, 3 refusés.
Le moment de la fuite : un mémo Board-Only lu à une analyste L2. Le chiffre est synthétique ; le mode de défaillance ne l'est pas.

La même requête, derrière le pare-feu

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.

Le côté RAGGUARD de la démonstration après la requête de Lena : 5 récupérés, 2 accordés, 3 refusés, avec une note de retenue listant les documents refusés et leurs codes de motif, dont BOARD_MEMBERSHIP_REQUIRED sur le pack conseil.
Même question, même récupération : 5 récupérés, 2 accordés, 3 refusés, chaque refus portant un code de motif.

Ce que le modèle a réellement vu

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.

L'entrée verbatim du modèle des deux côtés : le document Board-Only marqué en rouge dans le prompt ACL plat, et absent du prompt RAGGUARD, étiqueté comme fondé uniquement sur les documents autorisés.
Les fenêtres de contexte, verbatim : le document divulgué présent à gauche, absent à droite.
La vue de décision par document : la ligne du pack conseil indiquant Servi sans autorisation du côté ACL plat et Accès refusé à la récupération avec le code de motif BOARD_MEMBERSHIP_REQUIRED du côté RAGGUARD.
Le même document, deux verdicts : servi sans autorisation versus refusé à la récupération, avec le code de motif.

L'injection qui n'avait rien à voler

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.

La ligne d'injection de prompt intégrée dans la note de méthodologie Internal, mise en évidence dans la vue de détail de décision, ordonnant à tout assistant IA d'ignorer les permissions de récupération et de produire le chiffre de pertes de crédit du conseil.
L'injection, dans le document que le modèle avait le droit de lire. Le document qu'elle vise n'a jamais atteint le modèle.

Le graphe d'identité bouge. L'instantané, non.

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.

Le cas de l'employé licencié : Priya Shah avec un badge TERMINATED dans la bande d'identité, le côté RAGGUARD montrant 0 accordé et 5 refusés avec le code de motif ALL_ACCESS_REVOKED_TERMINATION, tandis que le côté ACL plat sert encore depuis son instantané périmé.
Licenciée il y a neuf minutes : le pare-feu révoque tout ; l'instantané d'ingestion n'a pas remarqué.

Le reçu, à l'écran

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.

La piste d'audit infalsifiable : une puce CHAIN INTACT, l'enregistrement JSON chaîné par hachage des documents servis et retenus avec codes de motif, et le bouton Export Audit Record.
L'enregistrement d'audit chaîné par hachage : l'artefact qu'un dossier de l'article 50 demande, pas une certification.

Le tableau de score, avec sa portée exacte

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.

Le tableau de score du benchmark de 40 cas : Naive Flat-ACL RAG à 29/40 avec 10 divulgations non autorisées et 1 faux refus, RAGGUARD à 40/40 avec 0 divulgation non autorisée et 0 faux refus.
Le tableau de score, calculé en direct par le harnais d'évaluation contre les étiquettes de l'oracle.
Un forage de benchmark par cas : l'oracle étiquette le cas deny, la référence ACL plat a servi le document, et RAGGUARD l'a retenu, avec les puces de politique expliquant la décision.
Forage par cas : étiquette d'oracle, décision ACL plat, décision du pare-feu, et la politique qui l'a tranchée.

Naive Flat-ACL RAG versus le Sovereign RBAC Firewall

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

Ce que cette démonstration ne fait pas

  • ✓ Elle ne se connecte pas à un Active Directory, Okta, SharePoint ou Confluence en direct. Le fournisseur d'identité est un fixture JSON synthétique calqué sur Azure AD/SCIM, les licenciements et expirations sont des événements de fixture, et le magasin vectoriel est en processus derrière une interface calquée sur Qdrant. Le connecteur IdP en direct est le remplacement de production documenté, pas ce qui s'exécute aujourd'hui.
  • ✓ Elle n'implique aucune banque réelle, aucun client ni aucun compte en direct. Lena Vogt, Marco Rossi, Priya Shah, Raj Patel, Wei Chen, chaque document, et le chiffre de EUR 412 millions sont synthétiques.
  • ✓ Elle ne revendique pas de garanties en monde ouvert. 40/40 avec 0 divulgation non autorisée est le résultat calculé sur un jeu d'or étiqueté fixe de 40 cas, pas une promesse que rien ne fuit jamais en production.
  • ✓ Elle ne mesure pas la latence de production. Le surcoût d'application à l'échelle de la microseconde est la logique du pare-feu seule, en processus ; un aller-retour IdP en direct, que cette démonstration simule, ajoute davantage.
  • ✓ Elle ne livre pas une suite de garde-fous, du DLP, ni une plateforme multi-agents. C'est une capacité faite de façon convaincante : le pare-feu de permissions au moment de la récupération, avec le cas d'injection comme un exemple étiqueté de défense en profondeur. Le chemin de réponse est Pydantic AI, et la porte déterministe délibérément non agentique est le design ; la gouvernance agentique est le chemin d'extensibilité documenté.
  • ✓ Elle ne certifie pas la conformité. L'export d'audit est l'enregistrement de preuve qu'un dossier de l'article 50 de l'EU AI Act demande, pas une certification, et aucun client, déploiement ni étude de cas n'existe pour cette démonstration.

Questions que les acheteurs posent réellement

Comment empêcher notre chatbot IA interne de montrer aux employés des documents qu'ils ne devraient pas voir ?

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.

Nous étiquetons déjà les documents avec des permissions lorsque nous les indexons. Pourquoi n'est-ce pas suffisant ?

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.

Une injection de prompt peut-elle tromper le modèle pour qu'il divulgue un document restreint ?

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.

Que se passe-t-il lorsque les politiques d'accès sont en conflit ou que le système n'est pas sûr ?

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.

Des données quittent-elles notre VPC ? Cela peut-il s'exécuter entièrement isolé (air-gapped) ?

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.

Que montrons-nous à un auditeur sur qui a accédé à quoi via le système d'IA ?

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é.

S'agit-il d'une intégration Active Directory en direct ou d'une démonstration ?

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.

Recherche technique

La recherche derrière cette démonstration — l'architecture, la conception de la vérification, et le schéma directeur d'entreprise.

Vous évaluez le déploiement d'un LLM privé dans une entreprise réglementée ?

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.

Évaluation de la couche de permissions

  • ✓ Cartographier où votre pipeline RAG autorise aujourd'hui : à l'ingestion ou à la récupération
  • ✓ Modéliser votre héritage de groupes imbriqués et inter-UO comme un graphe de politique vivant
  • ✓ Définir les règles ABAC qu'une étiquette plate ne peut pas exprimer : habilitation, appareil, attributions à durée limitée
  • ✓ Spécifier l'enregistrement d'accès à la récupération que votre dossier de l'article 50 demande

Construire le pare-feu au moment de la récupération

  • ✓ Une porte déterministe authorize(user, doc) en dehors de tout LLM
  • ✓ Résolution IdP en direct derrière des interfaces calquées sur Azure AD Graph et SCIM
  • ✓ Acheminement des conflits par refus par défaut vers une revue humaine
  • ✓ Une piste d'audit chaînée par hachage, exportable, générée dans votre VPC
Réseaux sociaux

Également publié sur