Comment cinq documents peuvent casser un système RAG et transformer une base de connaissances en vecteur d'attaque

Les systèmes RAG sont souvent perçus comme un moyen de réduire les hallucinations et de forcer les LLMs à s'appuyer sur des documents d'entreprise. Mais si la base de connaissances est considérée comme fiable par défaut, elle peut devenir le canal le plus pratique pour l'injection de prompts et la substitution silencieuse de réponses.

Où se trouve le point faible

Le problème ne vient pas du fait que le modèle « lit » mal les documents, mais du fait qu'il ne distingue pas les faits des instructions comme le ferait un humain. Si une base de connaissances reçoit plusieurs fichiers spécialement préparés, la couche de récupération du RAG peut régulièrement ramener ces documents dans le contexte de requêtes pertinentes. Alors le LLM voit les fragments comme faisant partie de son environnement de travail et commence à suivre des instructions cachées : ignorer le prompt système, modifier les priorités, insérer de fausses conclusions ou orienter le dialogue dans une direction favorable à l'attaquant.

Pour une équipe, c'est particulièrement dangereux car l'attaque se déguise en fonctionnement normal de la base de connaissances. Un utilisateur pose une question légitime, la récupération retourne des fragments « pertinents », et la réponse semble confiante et liée à la requête. Les journaux peuvent également sembler normaux : le modèle ne plante pas, n'entre pas dans un jailbreak évident et ne montre rien de suspect.

Mais la qualité de la solution chute, et avec elle—la confiance dans le produit, qui était censé s'appuyer sur des documents vérifiés.

Pourquoi cinq documents suffisent

Le principal risque est que la sécurité du RAG est souvent surestimée en raison des embeddings. Il semble que la recherche vectorielle transforme les textes sources en abstractions mathématiques sûres, mais ce n'est pas le cas. Les embeddings aident à trouver des fragments similaires, non à neutraliser leur sens.

Si cinq documents sont rédigés pour correspondre à des requêtes populaires d'utilisateurs et contiennent des instructions malveillantes aux bons endroits, le système inclura régulièrement ces documents dans le contexte. L'attaque ne nécessite pas un contrôle total de la base de connaissances : parfois, quelques notes, questions fréquemment posées ou politiques internes qui se retrouvent dans l'index sans vérification suffisent. L'effet est amplifié par la mécanique même de la récupération.

Le système alimente rarement le modèle avec l'intégralité du document—il le divise généralement en chunks et sélectionne les meilleures correspondances. Cela signifie que l'attaquant n'a pas besoin d'écrire un long texte malveillant : des fragments courts mais sémantiquement « collants » qui apparaissent dans les résultats top-k suffisent. En conséquence, le LLM reçoit non une référence neutre, mais un ensemble présélectionné de prompts influents, et l'opérateur du système peut ne pas remarquer longtemps que les réponses dérivent dans la direction établie par ces fragments.

Ce qui doit être protégé

En production, le RAG ne peut pas être protégé par un seul filtre à l'entrée. Vous avez besoin d'un schéma multicouche qui vérifie les documents, les chunks extraits et la réponse finale du modèle. Sinon, une équipe peut nettoyer la requête de l'utilisateur mais laisser passer la même injection dans la base de connaissances. Un problème séparé concerne les attaques « silencieuses », où le système ne plante pas ou n'affiche pas d'erreur évidente—il commence simplement à conseiller avec confiance des actions incorrectes, à substituer les priorités ou à révéler ce qu'il ne devrait pas montrer.

• Vérification des documents avant l'indexation pour détecter les instructions cachées et les motifs suspects
• Isolation des données par source, rôle et niveau de confiance
• Politiques de récupération : limites sur la dominance d'une seule source et contrôle de la diversité
• Filtrage du contexte avant de l'alimenter au LLM et guardrails séparés pour la réponse
• Logs, tests red-team et réévaluation régulière du corpus après les mises à jour

Les scénarios de démonstration cachent généralement ce problème car le corpus est petit, les sources sont connues à l'avance et les requêtes sont prévisibles. Dans un système fonctionnel, tout est différent : les documents sont chargés par lots, mis à jour sans modération manuelle, proviennent de différents départements et mélangent souvent des faits, des conseils, des modèles et des instructions de service. Dans un tel environnement, le RAG doit être conçu non comme « recherche + LLM », mais comme un pipeline sensible à la sécurité avec des zones de confiance claires, des audits de changements et des règles séparées pour différents types de contenu.

Ce que cela signifie

La principale vulnérabilité du RAG réside non seulement dans le modèle, mais dans la confiance placée dans le contexte fourni par l'infrastructure. Si le système fonctionne avec des données métier réelles, la protection doit commencer bien avant la génération de réponses : aux étapes de chargement de documents, de récupération et de post-traitement. Sinon, même un petit ensemble de fichiers empoisonnés peut distordre systématiquement le résultat.