RAG en production : sécurité et permissions

Le risque d'un RAG qui ignore les permissions

Un système RAG naïf indexe tous les documents disponibles dans une seule base de connaissances, accessible sans distinction à tout utilisateur de l'agent. Un employé pourrait alors, sans intention malveillante, recevoir via l'agent une information issue d'un document auquel il n'aurait normalement pas dû avoir accès (salaires, données RH confidentielles).

Le RAG doit respecter les permissions existantes

Un système RAG en production doit filtrer les résultats de recherche selon les permissions réelles de l'utilisateur qui pose la question, exactement comme un système de fichiers ou une base de données classique appliquerait un contrôle d'accès, pas une simple indexation globale sans distinction.

flowchart TD
    A[Question utilisateur] --> B[Recherche dans la\nbase de connaissances]
    B --> C[Résultats trouvés]
    C --> D{Filtrage selon les\npermissions de l'utilisateur}
    D -- Document autorisé --> E[Inclus dans le contexte\nenvoyé au modèle]
    D -- Document non autorisé --> F[Exclu, même si\npertinent sémantiquement]

Auditer ce qui est réellement indexé

Avant de déployer un système RAG en production, un audit de ce qui est effectivement indexé (et donc potentiellement récupérable via une question bien formulée) est indispensable, particulièrement si l'indexation a été faite automatiquement sur un large ensemble de documents sans tri préalable.

Cas concret

Une entreprise déploie un agent RAG connecté à l'ensemble de son wiki interne, sans distinction de permissions, en pensant simplifier le déploiement initial. Un employé junior demande innocemment "quel est le salaire moyen dans l'équipe marketing ?" et l'agent, ayant indexé un document RH normalement réservé aux managers, répond avec cette information confidentielle, une fuite de données involontaire causée uniquement par une architecture RAG mal conçue, sans aucune intention malveillante de l'utilisateur.

Erreurs fréquentes

• Indexer l'ensemble des documents d'une entreprise sans distinction de permissions, pour simplifier le déploiement initial, sans anticiper le risque de fuite de données confidentielles.
• Ne jamais auditer le contenu réellement indexé dans une base de connaissances RAG avant sa mise en production, découvrant les problèmes seulement après un incident.
• Croire qu'un système RAG "interne" à l'entreprise est automatiquement sûr, alors que le risque de fuite entre équipes ou niveaux hiérarchiques reste réel sans filtrage explicite par permissions.

À retenir

• Un système RAG en production doit filtrer les résultats de recherche selon les permissions réelles de l'utilisateur, pas indexer sans distinction tous les documents disponibles.
• Un document trouvé pertinent sémantiquement doit être exclu du contexte s'il n'est pas autorisé pour l'utilisateur qui pose la question.
• Un audit du contenu effectivement indexé est indispensable avant tout déploiement en production d'un système RAG connecté à des documents internes sensibles.

Mini-exercice

Une entreprise veut déployer un agent RAG connecté à son wiki interne, contenant à la fois des documents publics à toute l'équipe et des documents RH confidentiels réservés aux managers. Quelle mesure architecturale est indispensable avant la mise en production ?

Réponse : implémenter un filtrage des résultats de recherche RAG selon les permissions réelles de l'utilisateur posant la question, excluant les documents RH confidentiels des réponses pour tout utilisateur non autorisé, même si ces documents sont sémantiquement pertinents à la question posée.