RAG poisoning : quand la base de connaissances devient l’arme de cyberattaque

Un cas rapporté par AI Alert illustre le risque d’empoisonnement d’une base de connaissances (RAG) en entreprise. Au sein d’une société de services financiers, un assistant RH interne alimenté par un corpus RAG de politiques RH, aurait fourni un seuil erroné de remboursement de notes de frais après l’intégration, dans le SharePoint partagé, d’un fichier contenant des instructions malveillantes dissimulées. L’anomalie a échappé aux mécanismes de contrôle habituels et n’aurait été détectée qu’à l’occasion d’un audit. Cet incident, qui s’ajoute à d’autres cas documentés en 2025-2026, illustre pourquoi le RAG poisoning est aujourd’hui considéré comme l’un des vecteurs les plus sournois ciblant les déploiements IA en entreprise.

Attaque RAG poisoning : un mécanisme de piratage qui cible la donnée, pas le modèle LLM

Le RAG (Retrieval Augmented Generation) enrichit les réponses d’un modèle avec des documents récupérés dans une base de connaissances au moment de la requête, pour ancrer ses réponses dans des données propriétaires ou à jour plutôt que dans ses seules connaissances d’entraînement.

Le RAG poisoning consiste à injecter du contenu malveillant dans cette base, de sorte que le système de récupération renvoie ce contenu empoisonné aux côtés de résultats légitimes, le modèle incorpore alors la charge malveillante dans sa réponse sans distinguer une source fiable d’une source compromise. C’est ce qui le distingue structurellement du prompt injection classique : celui-ci cible le comportement d’obéissance du modèle en session, le poisoning corrompt la couche de récupération elle-même, en amont de toute interaction avec l’utilisateur final.

Vecteur d’attaque RAG : une efficacité démontrée avec une quantité de données dérisoire

L’étude PoisonedRAG, publiée au 34e symposium USENIX Security en 2025, montre que les bases de connaissances utilisées par les systèmes de génération augmentée par récupération (RAG) peuvent être manipulées par l’injection de textes malveillants. De façon très concrète, les expériences ont révélé qu’il suffit d’injecter seulement cinq documents empoisonnés par question cible, c’est-à-dire la requête spécifique qu’un attaquant cherche à détourner, pour atteindre un taux de réussite de 90 %, et ce même au sein d’une base massive contenant des millions de textes légitimes. Ce résultat met en évidence une asymétrie entre la taille d’une base documentaire et le faible nombre de textes nécessaires pour influencer certaines réponses.

Une technique appelée Phantom pousse la discrétion plus loin encore : elle propose une attaque par porte dérobée contre les systèmes RAG, au moyen d’un seul document malveillant injecté dans la base de connaissances. Ce document est conçu pour être récupéré principalement lorsque la requête contient une séquence de déclenchement spécifique (telle qu’un mot-clé) ; il peut alors influencer la réponse du modèle ou poursuivre d’autres objectifs adverses. L’attaque reste ainsi inactive pour les requêtes ne contenant pas ce déclencheur, ce qui peut compliquer sa détection par des contrôles reposant uniquement sur des requêtes ordinaires ou sur des indicateurs agrégés.

Sécurité IA et empoisonnement de données : pourquoi ce vecteur échappe aux défenses classiques

Le RAG poisoning partage avec les autres formes d’empoisonnement de données une caractéristique qui le rend particulièrement difficile à détecter : il ne provoque ni panne ni erreur visible. Les journaux restent propres, les réponses demeurent fluides et confiantes, et le système continue à fonctionner normalement en apparence pendant qu’il diffuse silencieusement une information manipulée. Une étude réalisée sur le système de navigation Waze illustre ce principe hors du contexte strict de l’IA générative : un attaquant pouvait utiliser des dispositifs Sybil, c’est-à-dire des clients logiciels simulant des véhicules, pour transmettre de fausses données de congestion ou de signalement routier. Ces données pouvaient ensuite influencer l’estimation du trafic et provoquer le réacheminement automatique d’utilisateurs, sans modification du code ou des paramètres internes du système.

Le caractère probabiliste des modèles et la variété des contenus malveillants rendent insuffisant un simple filtrage par mots interdits ou un score de confiance isolé. L’édition 2025 de l’OWASP Top 10 LLM  distingue deux risques pertinents : LLM05:2026 – Data and Model Poisoning et LLM09:2026 – Vector and Embedding Weaknesses, qui couvre notamment les bases vectorielles et les mécanismes de récupération des systèmes RAG.

LLM08 constitue une évolution de la taxonomie OWASP visant à mieux prendre en compte les risques liés aux embeddings et à la recherche vectorielle ; cette classification ne suffit toutefois pas, à elle seule, à démontrer la maturité croissante des attaques RAG.

Protection RAG et cybersécurité : une défense multicouche, pas une mesure unique

• Sécuriser le pipeline d’ingestion en amont : considérer les documents provenant de connecteurs, d’API, de fichiers ou de dépôts partagés comme des entrées à vérifier avant leur indexation. Il est recommandé de contrôler la provenance, de détecter les instructions dissimulées et de prévoir une validation pour les nouvelles sources.
• Isoler la récupération selon le niveau de confiance : distinguer les sources officielles des contenus déposés par des utilisateurs ou des tiers, et appliquer des métadonnées de provenance, de classification et d’autorisation afin d’éviter qu’un contenu non validé soit récupéré au même niveau qu’une documentation de référence.
• Surveiller les réponses et les récupérations dans la durée : instrumenter le pipeline RAG avec des outils d’observabilité (Langfuse, LangSmith, Arize Phoenix) pour tracer requêtes, chunks et réponses. Suiver sur un tableau de bord la qualité (faithfulness, pertinence, hallucinations) et la sécurité (injections, dérives). Cette surveillance continue complète les contrôles d’ingestion sans les remplacer.
• Auditer régulièrement le contenu indexé : effectuer des contrôles périodiques du corpus, de la provenance des documents, de leurs modifications et des droits d’accès, indépendamment des signalements des utilisateurs. Ces audits peuvent contribuer à repérer des contenus anormaux ou empoisonnés avant qu’ils ne produisent un impact.

→ Voir notre guide des architectures et vecteurs de risques IA pour resituer ce vecteur parmi les autres risques propres au RAG.

FAQ : Sécurité RAG et vulnérabilités LLM

Audit de sécurité RAG : sécuriser votre pipeline contre l’empoisonnement de données

Nos experts auditent la gouvernance de vos bases de connaissances RAG et testent leur résistance à l’empoisonnement dans le cadre de notre offre de pentest IA. Vous souhaitez échanger sur votre projet ou évaluer vos besoins ? Contactez nos experts.