Votre assistant interne donne une réponse exacte à partir d’un document que le collaborateur ne peut pas ouvrir dans Google Drive.
La réponse est peut-être juste. Le contrôle d’accès a échoué.
Un RAG sécurisé - une IA qui recherche dans les connaissances de l’entreprise avant de répondre - ne se résume pas à masquer le lien source après coup. Le système doit connaître l’identité de la personne, vérifier les habilitations actuelles, décider quels extraits peuvent atteindre le modèle et propager retraits d’accès, suppressions et règles de conservation.
Cette partie traite des habilitations de recherche : qui peut chercher quel contenu, et ce qui doit changer quand l’accès change. Maintenir l’index lui-même à jour (identité des documents, mises à jour et suppressions) relève de la partie 5 ; décider ce que l’assistant peut faire de ce qu’il trouve relève de la partie 7. Le parcours complet figure sur la page du guide.
La réponse en 60 secondes
Une recherche d’entreprise respectueuse des permissions suit une chaîne :
- authentifier la personne ou le service qui interroge ;
- conserver l’identité, la classification et la référence d’habilitation du document source ;
- filtrer les contenus éligibles pour cette identité ;
- réautoriser les contenus sensibles avant leur entrée dans le contexte du modèle ;
- ne citer que des sources que l’utilisateur peut ouvrir ;
- propager révocations, suppressions et fins de conservation ;
- journaliser la décision sans créer une nouvelle copie incontrôlée.
Si l’index utilise un seul compte de service très puissant et ne peut pas expliquer pourquoi un utilisateur a reçu un document, il n’est pas encore sensible aux permissions.
Dans cet article
- Partir d’une identité, pas de la fenêtre de chat
- Choisir le modèle d’accès aux sources
- Transporter habilitations et classification dans la couche de connaissances
- Autoriser avant que le contenu n’atteigne le modèle
- Propager révocation, suppression et conservation
- Tester et exploiter la chaîne d’autorisation
1. Partir d’une identité, pas de la fenêtre de chat
Chaque recherche doit avoir un demandeur nommé : utilisateur, identité déléguée tenant compte de ses groupes, ou compte de service borné. « C’est l’IA de l’entreprise » ne suffit pas.
Les sources appliquent des règles différentes :
- Google Drive associe fichiers et dossiers à des listes d’accès et calcule les capacités de l’utilisateur courant ;
- les périmètres d’autorisation Slack bornent les données et fonctions accessibles à l’application ou au jeton utilisateur ;
- les permissions d’une GitHub App s’articulent avec l’installation, les dépôts et parfois les droits de la personne.
L’authentification répond : « Qui est-ce ? » La permission technique : « Que peut atteindre cette identité ? » La conception métier doit encore répondre : « Ce contenu peut-il être utilisé pour cette finalité ? »
Gardez la source comme autorité d’accès lorsque c’est possible. L’index facilite la recherche ; il ne devient pas le nouveau propriétaire de la confidentialité.
2. Choisir le modèle d’accès aux sources
Deux modèles dominent.
L’accès délégué interroge la source au nom de la personne. Il reflète naturellement une partie de ses droits actuels, mais exige de gérer cycle de vie des jetons, groupes et sémantique propre à chaque source.
L’accès par compte de service utilise une identité d’intégration. Il simplifie l’indexation planifiée, mais l’index peut hériter de tout ce que ce compte voit. Un même compte couvrant RH, finance, commerce et delivery peut effacer les frontières conservées dans les outils sources.
Notion rend le risque concret : son guide d’autorisation indique qu’une connexion interne doit recevoir explicitement l’accès aux pages. Le fait que le robot puisse lire une page ne démontre pas que chaque utilisateur de l’assistant y est habilité.
Pour chaque connecteur, documentez :
- identité technique et propriétaire ;
- domaines et droits accordés ;
- accès délégué ou compte de service ;
- contrôles de groupes et d’objets ;
- expiration, rotation et révocation des jetons ;
- procédure de mobilité et de départ ;
- catégories de données et finalités concernées.
Le guide de sécurité de la CNIL recommande de définir, attribuer, revoir et retirer les habilitations selon les besoins. Appliquez-le au traitement réel ; la présence d’un tableau d’accès ne prouve pas la conformité.
3. Transporter habilitations et classification dans la couche de connaissances
Un index ne doit pas réduire un document à du texte et un vecteur. Conservez au minimum :
source_system, source_id, source_url, owner, classification, acl_reference, version, modified_at, retention_state, deleted_at.
Une représentation vectorielle n’est pas une donnée technique sans risque. L’OWASP recense, pour les vecteurs et embeddings, accès non autorisé, fuite entre contextes, empoisonnement et journalisation insuffisante. Sa catégorie divulgation d’informations sensibles inclut données personnelles, financières, juridiques et informations propriétaires.
Utilisez partitions et filtres de métadonnées pour réduire les candidats, sans confondre filtre et autorisation. Une copie d’ACL peut vieillir entre deux synchronisations. Un document déplacé vers un dossier confidentiel peut garder son ancienne étiquette dans l’index.
Dans la couche d’orchestration, les rôles et projets n8n peuvent limiter qui manipule workflows et identifiants. Les coffres de secrets externes, selon l’édition, améliorent le stockage de certains identifiants. Aucune de ces fonctions ne reproduit automatiquement les permissions documentaires dans la base vectorielle.
4. Autoriser avant que le contenu n’atteigne le modèle
Règle de conception : si la personne ne peut pas consulter le document, son texte ne doit pas entrer dans le contexte du modèle.
Une suppression après génération intervient trop tard. Le modèle a déjà reçu l’information et peut la révéler dans une réponse, un résumé, une comparaison ou même une formulation indirecte.
| Couche | Question | Comportement fermé en cas d’échec |
|---|---|---|
| Identité | Qui interroge, dans quelle organisation et quel rôle ? | Refuser l’identité absente ou ambiguë |
| Préfiltre | Quels domaines et classifications sont éligibles ? | Écarter le contenu non classé |
| Autorisation source | Cette personne peut-elle lire ces objets maintenant ? | Retirer les extraits avant le modèle |
| Génération | La réponse repose-t-elle uniquement sur les preuves autorisées ? | S’abstenir si elles manquent |
| Restitution | Chaque citation est-elle ouvrable ? | Bloquer la réponse, pas seulement le lien |
| Trace | Peut-on reconstruire la décision ? | Enregistrer un événement borné |
Pour les domaines sensibles, vérifiez l’accès contre la source au moment de la récupération. Le modèle d’autorisation RAG présenté par AWS Security explique pourquoi des métadonnées synchronisées périodiquement peuvent être en retard, puis vérifie l’accès avant que les extraits n’atteignent le modèle. C’est un exemple d’architecture éditeur, pas l’unique solution.
L’ANSSI place identités, sources, base vectorielle, filtres, administration et supervision dans une architecture de sécurité en profondeur. Là encore, le périmètre et le niveau de contrôle dépendent du risque réel.
5. Propager révocation, suppression et conservation
Le contrôle doit rester juste après la mise en production.
Les journaux de changements Drive exposent l’état courant des éléments modifiés pour un utilisateur ou un drive partagé. Couvrir les sources pertinentes, gérer les erreurs et rapprocher l’état restent votre responsabilité.
Définissez le comportement lorsque :
- une personne quitte un groupe ou l’entreprise ;
- une page est déplacée ou reclassée ;
- un document est supprimé ou remplacé ;
- un jeton perd son accès ;
- la synchronisation échoue à mi-parcours ;
- la durée de conservation arrive à son terme.
La suppression peut devoir couvrir copie brute, texte extrait, segments, embeddings, caches et productions dérivées selon le cas. La CNIL rappelle que les données personnelles ne se conservent pas indéfiniment : la durée dépend de la finalité et, le cas échéant, des obligations applicables. Il n’existe pas une durée universelle « pour le RAG ».
Le RGPD officiel, notamment ses articles 5, 25 et 32, porte les principes de minimisation, limitation de conservation, protection dès la conception et sécurité adaptée au risque. Cette lecture ne remplace pas l’analyse du traitement, du rôle des parties, des bases légales ou des obligations sectorielles.
À lire aussi : gérer les accès et autorisations des agents IA.
6. Tester et exploiter la chaîne d’autorisation
Testez les refus aussi sérieusement que les bonnes réponses :
- utilisateur autorisé : bonne source retrouvée et ouvrable ;
- utilisateur non autorisé : aucun extrait du domaine ;
- retrait d’un groupe : accès fermé ;
- reclassification : résultat modifié ;
- suppression : toutes les représentations concernées retirées ;
- ACL périmée ou synchronisation en échec : abstention, pas ouverture permissive ;
- traces : décision reconstructible sans recopier inutilement le contenu sensible.
La journalisation recommandée par la CNIL vise la détection, l’investigation et la traçabilité ; les journaux doivent eux-mêmes être protégés, utiles et conservés de manière proportionnée.
Le cadre AI RMF du NIST traite l’évaluation et le suivi comme des activités continues. Dans n8n, l’audit de sécurité peut signaler certains risques liés aux identifiants, nœuds, fichiers ou à l’instance ; la diffusion des logs peut envoyer des événements sélectionnés vers votre supervision sur les offres éligibles. Aucun des deux ne prouve que la chaîne complète d’autorisation fonctionne : testez-la.
Exemple Atlas
Atlas possède un espace confidentiel consacré à une acquisition. Léa peut le rechercher tant qu’elle appartient à l’équipe du projet. Lorsqu’elle rejoint le delivery, la source retire son groupe.
Un système correct détecte ce changement, exclut le contenu du périmètre éligible, invalide les caches concernés et vérifie qu’une question sur l’acquisition produit désormais une abstention. Un index qui continue de répondre jusqu’à la reconstruction hebdomadaire a échoué, même si sa réponse est exacte.
Atlas est illustratif, pas un cas client IZZY. Aucun résultat n’est revendiqué.
Conclusion : préserver la frontière de la source
La recherche d’entreprise doit faciliter l’accès aux connaissances autorisées, pas contourner la confidentialité.
Nommez l’identité. Conservez source et classification. Autorisez avant le modèle. Propagez révocation, suppression et conservation. Testez le chemin négatif et gardez la source comme autorité.
Auditons un domaine sensible avec IZZY
Apportez un domaine - RH, finance, propositions commerciales ou delivery client - avec sa source, ses groupes, sa règle de conservation et un exemple de changement d’accès. Nous cartographions la chaîne et identifions où déléguer, filtrer, réautoriser, s’abstenir ou arrêter.
Le résultat peut être un pilote borné, un connecteur plus étroit - ou la remise en ordre des habilitations avant l’ajout d’une IA.
C’est exactement le périmètre de notre service Automatisation IA n8n.
Questions fréquentes
Elles sont le point de départ. La couche de recherche doit transporter identité et métadonnées de contrôle, les maintenir à jour et empêcher tout extrait non autorisé d’atteindre le modèle.
Il réduit les candidats, mais une copie d’ACL peut vieillir. Un domaine sensible peut exiger une vérification actuelle contre la source.
Seulement si son accès large et l’autorisation en aval sont conçus, justifiés et testés. Sinon, ce compte peut effacer les frontières entre équipes et clients.
Fermer le périmètre concerné : s’abstenir, signaler l’échec de contrôle et rapprocher l’état. Une preuve manquante ne vaut jamais autorisation.
Sources et périmètre de preuve
Recherche vérifiée le 28 juillet 2026 à partir des sources officielles ou primaires liées dans l’article. La chaîne d’autorisation, le schéma et Atlas relèvent de la méthode IZZY.
Aucun annuaire, ACL, connecteur, jeton, index, modèle, cache, suppression, durée, workflow n8n, refus d’accès ou résultat métier n’a été testé. Les références RGPD, CNIL et ANSSI éclairent la conception ; cet article ne formule ni avis juridique ni constat de conformité. Les documentations peuvent évoluer après la date de recherche.