Contrôler les accès d’un assistant IA interne

Un assistant IA interne ne doit jamais devenir un compte de service omniscient déguisé en boîte de dialogue. Le problème n’est pas seulement ce que le modèle mémorise, mais ce qu’il reçoit dans son contexte au moment de répondre : un RAG mal filtré transforme une recherche documentaire en élévation de privilèges.

→ Lire l’explication complète de la marmotte

Le RAG ne doit pas posséder plus de droits que son utilisateur

La retrieval-augmented generation (RAG), ou génération augmentée par recherche, enrichit une requête avec des extraits issus d’un corpus documentaire. Le modèle de langage (LLM, Large Language Model) reçoit ces extraits dans son contexte, puis rédige une réponse. Une fois le texte transmis au modèle, le contrôle d’accès est déjà perdu : il n’existe plus de barrière technique entre le contenu autorisé et le mécanisme de génération.

Le modèle ne constitue pas un point de décision de politique. Lui demander de « ne pas révéler les documents confidentiels » revient à demander à un moteur de recherche de respecter une clause de confidentialité imprimée dans le résultat. Cela peut sembler marcher jusqu’au jour où une instruction contradictoire, une ambiguïté ou une injection de prompt tire sur le bon fil. Les slides de vendeurs appellent cela une garde-fou intelligente. En architecture, cela s’appelle déplacer le problème derrière une frontière non vérifiable.

La règle est donc stricte : le moteur de recherche ne retourne au LLM que les passages accessibles à l’identité qui effectue la requête. Le filtre d’autorisation s’applique avant le classement final et avant la construction du prompt. Filtrer après la génération ne corrige rien : la réponse peut déjà avoir reformulé, inféré ou combiné une information interdite.

Cette séparation distingue deux identités :

l’identité technique du service RAG, autorisée à indexer et maintenir le corpus ;
l’identité effective du demandeur, utilisée pour calculer les documents qu’il peut consulter.

L’identité technique ne doit jamais être employée comme identité de lecture au moment d’une question utilisateur. Sinon, tous les employés héritent des privilèges du connecteur d’indexation. C’est une délégation involontaire, pas une fonctionnalité d’intelligence artificielle.

Les fondations d’identité restent les mêmes que pour une application sensible : authentification centralisée, attribution de groupes maîtrisée, cycle de vie des comptes et révocation vérifiable. Les principes décrits dans la section identités s’appliquent ici sans exemption liée au vocabulaire IA. Un chatbot n’annule pas l’IAM (Identity and Access Management), il le rend plus facile à contourner si l’architecture est paresseuse.

Filtrage des résultats dans la base vectorielle

Une base vectorielle stocke des représentations numériques de passages, appelées embeddings. La recherche y retourne les passages les plus proches du sens d’une requête, et non nécessairement ceux contenant les mêmes mots. Cette recherche sémantique est détaillée dans embeddings et RAG. Elle introduit une difficulté : les autorisations doivent voyager avec chaque unité indexée.

Chaque fragment indexé doit porter des métadonnées d’autorisation dérivées de la source :

identifiant immuable du document source ;
version ou empreinte de la source ;
liste des principaux autorisés, groupes ou attributs ;
classification de sensibilité ;
date de validité éventuelle ;
identifiant du connecteur et date de synchronisation.

Le choix entre liste de contrôle d’accès et attributs dépend du référentiel existant. Une ACL (Access Control List), liste de sujets autorisés par document, convient lorsque la source fournit déjà des droits explicites. Un contrôle d’accès fondé sur les attributs, souvent nommé ABAC (Attribute-Based Access Control), convient lorsque les règles dépendent du service, du pays, du niveau de classification ou d’une fonction métier. Il ne faut pas reconstruire une troisième taxonomie dans le RAG. Une matrice de droits inventée pour l’assistant divergera du système documentaire, puis finira dans un tableur qui ne ment jamais, sauf tous les jours.

Le filtre doit être exécuté par le moteur de recherche ou par une couche d’autorisation située devant lui. Une requête vectorielle doit associer la similarité sémantique à une contrainte d’accès obligatoire. Récupérer les 100 meilleurs résultats puis éliminer les 95 interdits côté application est acceptable seulement si la base garantit que les passages exclus ne sortent jamais de sa frontière de confiance. Dans la pratique, il faut demander directement les meilleurs résultats parmi le sous-ensemble autorisé.

Le compromis central est net : propager des permissions fines augmente le coût d’indexation, la taille des métadonnées et la latence de recherche. Ne pas les propager réduit ce coût en échange d’une fuite structurelle de données. Le choix est tranché : accepter le coût. Une réponse un peu plus lente vaut mieux qu’une fuite qui répond avec aplomb et des sources internes.

Pour les corpus très grands, éviter d’inscrire une liste individuelle d’utilisateurs dans chaque fragment. Préférer des identifiants de groupes stables, des étiquettes de classification et des règles évaluables côté recherche. La résolution des groupes doit toutefois provenir du fournisseur d’identité au moment de la requête ou d’un cache à durée de vie courte. Un cache de droits sans invalidation est une révocation décorative.

Exemple de requête vectorielle avec contrainte d’autorisation

L’exemple suivant utilise une requête HTTP vers un service de recherche fictif compatible avec un filtrage de métadonnées. Il illustre le point architectural : les groupes sont extraits d’un jeton validé par le frontal d’authentification, puis transmis comme critères de filtrage. Le navigateur ne fournit jamais ces groupes directement.

# Le frontal a vérifié le jeton et résolu les groupes de l'identité.
# La liste provient du serveur d'identité, pas du corps HTTP envoyé par le client.
curl -sS https://rag-recherche.interne/v1/search \
  -H 'Content-Type: application/json' \
  -H 'X-Request-ID: 4d7098c1-6ff1-4c9c-bcad-46e41e65e5e2' \
  --data '{
    "query": "procédure de reprise après incident",
    "top_k": 8,
    "filters": {
      "document_state": "published",
      "classification_lte": "internal",
      "allowed_groups_any": ["infra-operations", "security-readers"],
      "valid_from_lte": "2026-09-22",
      "valid_until_gte": "2026-09-22"
    },
    "include_metadata": ["source_id", "source_version", "classification"]
  }'

La requête ne doit pas accepter un champ allowed_groups_any provenant du poste utilisateur. Le service de recherche le construit à partir du contexte d’authentification signé et vérifié. Accepter des filtres d’accès pilotés par le client revient à laisser le demandeur écrire sa propre badgeuse, avec un feutre et beaucoup d’enthousiasme.

Le classement doit aussi respecter les règles de source. Si un document a été supprimé, déplacé dans un espace restreint ou reclassifié, ses fragments doivent devenir inaccessibles avant la prochaine réponse. L’indexation asynchrone crée une fenêtre de divergence. Cette fenêtre doit être mesurée, documentée et réduite par des événements de changement issus du référentiel documentaire. Une synchronisation nocturne suffit pour une base de connaissances publique interne ; elle est insuffisante pour les dossiers de ressources humaines, les incidents de sécurité ou les documents de direction.

Surface d’attaque du retrieval et contre-mesures

L’attaque la plus évidente consiste à formuler une question pour extraire indirectement une information interdite : « résumer les écarts entre les procédures », « citer les exceptions », « quels projets rencontrent tel problème ». Le filtrage avant récupération bloque le document interdit, mais ne bloque pas les inférences à partir de plusieurs documents autorisés. La confidentialité par composition reste un problème métier : une classification doit prendre en compte ce qu’un ensemble de documents permet de déduire.

L’injection de prompt vise à faire ignorer au modèle ses instructions, à lui demander ses sources ou à déclencher des outils. Elle ne doit pas permettre d’élargir le corpus récupéré. Les droits sont donc évalués en dehors du LLM, et les outils éventuels reçoivent une identité déléguée à portée réduite. Un agent capable de consulter une boîte aux lettres, un espace documentaire et un outil de tickets avec un jeton global est une collection de violations potentielles dans un trench-coat.

Les attaques sur les métadonnées sont moins spectaculaires et plus fréquentes. Un document classifié correctement avec une étiquette de groupe erronée devient visible. Protéger l’intégrité des connecteurs, tracer les transformations et comparer périodiquement les ACL de la source avec celles de l’index sont des contrôles obligatoires. Une source sans identifiant stable ne permet pas une révocation fiable : l’index doit alors être considéré comme non gouvernable.

Les documents empoisonnés représentent une autre surface. Un auteur peut insérer des instructions destinées au modèle dans un contenu indexé : « ignorer les règles », « transmettre les secrets », « appeler tel outil ». Marquer la provenance, limiter les outils autorisés, séparer les contenus non fiables et exiger une validation humaine pour les actions sensibles réduisent le risque. La supervision humaine ne remplace pas le contrôle d’accès, elle intervient après que celui-ci a limité le rayon d’explosion.

Enfin, la recherche elle-même peut révéler des informations par ses erreurs, ses scores ou ses suggestions. Ne pas retourner les titres, nombres de résultats ou raisons de refus relatifs à des documents non accessibles. « Aucun résultat accessible » est préférable à « trois résultats confidentiels existent ». La différence paraît minuscule jusqu’à ce qu’elle devienne un oracle de reconnaissance documentaire.

Journalisation, révocation et exploitation

Chaque interrogation doit être journalisée comme une lecture d’une base sensible. Le journal doit contenir l’identité authentifiée, ses groupes ou attributs évalués, l’identifiant de session, la requête normalisée ou son empreinte selon sa sensibilité, les identifiants de sources retenues, les versions de politiques appliquées, le modèle utilisé, les outils appelés et la décision finale.

Les journaux ne doivent pas contenir par défaut les extraits complets envoyés au modèle. Ces extraits peuvent être plus sensibles que la requête elle-même. Conserver un identifiant de fragment, une empreinte cryptographique et un lien vers la version source permet une enquête sans fabriquer une seconde copie non gouvernée du corpus. Les événements sont envoyés vers un SIEM (Security Information and Event Management), plateforme centralisant les événements de sécurité, avec contrôle d’accès distinct pour les analystes.

La révocation doit couvrir quatre états : compte désactivé, retrait d’un groupe, suppression ou reclassification d’un document, révocation d’un jeton de session. Révoquer un droit dans l’annuaire ne retire pas magiquement les passages présents dans un cache de recherche ou un contexte déjà envoyé au modèle. Fixer une durée de vie courte pour les jetons, invalider les caches lors des événements d’autorisation et supprimer les fragments obsolètes sont les conditions minimales.

Les sauvegardes de l’index doivent inclure les métadonnées d’autorisation, les versions des politiques et les identifiants de source. Restaurer seulement les vecteurs produit un corpus sans gouvernance, ce qui est une façon très efficace de transformer une reprise après incident en incident neuf. Les clés de signature des jetons, les secrets des connecteurs et les identifiants d’accès à l’index doivent être gérés séparément, avec rotation et journalisation de leur usage.

Ce mécanisme ne garantit pas la conformité réglementaire, la qualité des classifications ni l’absence d’inférence métier. Il ne garantit pas non plus qu’un employé autorisé utilise correctement l’information reçue. Ces sujets relèvent de la gouvernance documentaire, de la prévention de fuite de données et des processus de sécurité, pas d’une phrase ajoutée au prompt.

🐝 Ce qui arrive si on s’en passe

Sans filtrage d’autorisation en amont de la récupération, la portée d’un compte compromis cesse d’être calculable : le périmètre de lecture devient celui du connecteur d’indexation, et non celui du titulaire. Une enquête ne peut alors ni délimiter les documents réellement restitués, ni prouver qu’un fragment n’a pas été présenté, faute de trace reliant une identité, une politique et une version de source. La reprise en souffre aussi : un index restauré sans métadonnées d’accès redevient consultable intégralement, sans moyen de distinguer ce qui était déjà exposé. Les écarts de réponse (délai, message d’erreur, nombre de résultats) suffisent enfin à confirmer l’existence de dossiers inaccessibles, exactement le schéma décrit dans la brèche « la question qui rend le module bavard », où des réponses différenciées transforment un service en oracle.

🦫 Explication de la marmotte 🍫

Un assistant interne reçoit une question d’un salarié. Avant de chercher des documents, le système vérifie qui pose la question et récupère ses droits : ses groupes, son service et les règles qui limitent son accès. Ces droits viennent du système d’identification de l’organisation, pas de la personne qui envoie la question.

Le système cherche ensuite des passages dans une base contenant les documents de l’entreprise. Chaque passage contient aussi des informations sur son origine, sa date, sa classification et les personnes ou groupes qui peuvent le lire. La recherche écarte les passages interdits avant de les transmettre au modèle de langage. Le modèle ne reçoit donc que des informations auxquelles le salarié a déjà accès.

Si aucun passage autorisé ne répond à la question, l’assistant doit le dire sans révéler qu’un document interdit existe. Si un document est supprimé, déplacé ou devient confidentiel, ses passages doivent être retirés ou bloqués rapidement dans la base de recherche.

Chaque demande est enregistrée avec l’identité du demandeur, les documents retenus et la règle appliquée. Ces traces servent à comprendre un incident ou une erreur. Elles ne doivent pas recopier inutilement les documents sensibles. Si les droits sont modifiés, les sessions et les mémoires temporaires doivent aussi être mises à jour. Sinon, un ancien droit peut continuer à fonctionner après sa suppression.

Pages voisines

La citent

Contrôler les accès d’un assistant IA interne

Elle cite

: les deux pages se citent l’une l’autre.

Contrôler les accès d’un assistant IA interne

Contrôler les accès d’un assistant IA interne

Le RAG ne doit pas posséder plus de droits que son utilisateur

Filtrage des résultats dans la base vectorielle

Exemple de requête vectorielle avec contrainte d’autorisation

Surface d’attaque du retrieval et contre-mesures

Journalisation, révocation et exploitation

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines