RAG : quand votre base documentaire devient une surface d’attaque

Le RAG — génération augmentée par récupération — est devenu l’architecture par défaut des assistants d’entreprise : on branche le modèle sur vos documents, et il répond avec votre savoir. Encore faut-il qu’il réponde à la bonne personne, avec les bons documents.

Le principe, et son angle mort

Un RAG découpe vos documents en fragments, les transforme en vecteurs (embeddings), les stocke dans une base vectorielle, puis, à chaque question, récupère les fragments les plus proches et les donne au modèle pour construire sa réponse.

L’angle mort est simple : la base vectorielle ne connaît pas vos droits d’accès. Si rien n’est prévu, elle renvoie les fragments les plus pertinents — pas ceux que l’utilisateur a le droit de lire. L’OWASP classe ces risques dans LLM08:2025 Vector and Embedding Weaknesses.

Faille n°1 : l’effondrement des droits documentaires

Dans votre GED, le dossier « Rémunérations » est réservé aux RH. Dans l’index du RAG, il est un paquet de fragments parmi d’autres. Un stagiaire demande « quelle est la politique salariale ? » — et reçoit une synthèse nourrie de la grille de la direction.

La correction n’est pas un prompt « ne révèle pas d’informations confidentielles ». C’est un filtrage des résultats par les droits de l’utilisateur, appliqué au moment de la récupération, avant que le modèle ne voie quoi que ce soit.

Un RAG sans contrôle d’accès est une GED dont on aurait retiré toutes les serrures.

Faille n°2 : l’empoisonnement des sources

Tout document indexé peut influencer les réponses. Un contenu piégé — une page de wiki modifiée, un PDF de fournisseur, un e-mail archivé — peut :

• contenir une instruction cachée qui sera exécutée quand le fragment sera récupéré (injection indirecte) ;
• introduire de fausses informations qui seront présentées avec l’autorité de « votre documentation » ;
• être conçu pour remonter en priorité sur certaines questions.

Chaque source indexée doit donc être qualifiée : qui peut y écrire, avec quel contrôle, et à quelle fréquence est-elle réindexée ?

Faille n°3 : les embeddings ne sont pas anonymes

On imagine souvent qu’un vecteur est une représentation abstraite, sans valeur pour un attaquant. Des travaux de recherche ont montré qu’il est possible, dans certaines conditions, de reconstituer une partie du texte d’origine à partir de ses embeddings. Une base vectorielle doit donc être protégée comme les documents qu’elle représente : chiffrement, contrôle d’accès, cloisonnement entre clients ou entre entités.

Les contrôles d’un RAG sécurisé

1. Récupération filtrée par les droits de l’utilisateur, synchronisée avec vos annuaires et votre GED.
2. Qualification des sources : liste des corpus indexés, propriétaires, circuits de validation des contenus.
3. Cloisonnement des index par entité, client ou niveau de sensibilité.
4. Traitement des contenus récupérés comme non fiables : ils informent la réponse, ils ne donnent pas d’ordres.
5. Citations des sources dans les réponses, pour permettre la vérification.
6. Protection de la base vectorielle au même niveau que les documents d’origine.
7. Journalisation des questions, des fragments récupérés et des réponses.