Empoisonnement RAG : 3 faux documents suffisent à pirater votre IA

Chez Bridgers, nous concevons et déployons des systèmes RAG pour nos clients dans la finance, le juridique et les ressources humaines. Lorsque nous construisons un assistant IA connecté à une base de connaissances interne, la sécurité de cette base n'est pas un détail technique : c'est la fondation de tout le projet. Le 12 mars 2026, le chercheur en sécurité IA Amine Raji a publié une démonstration qui devrait inquiéter toute entreprise utilisant un système RAG : en moins de trois minutes, avec trois faux documents, il a transformé les résultats financiers d'une entreprise fictive de 24,7 millions de dollars de chiffre d'affaires en 8,3 millions, avec un plan de licenciement inventé de toutes pièces. Aucune faille logicielle exploitée. Aucun jailbreak. Juste trois fichiers glissés dans la bonne base de données. Voici ce que vous devez savoir, et ce que nous recommandons à chaque client qui nous confie un projet RAG.

C'est quoi le RAG et pourquoi c'est vulnérable

Le RAG (Retrieval-Augmented Generation) est devenu l'architecture standard pour déployer des LLM en entreprise. Le principe est simple : plutôt que de compter uniquement sur la mémoire interne du modèle, le système interroge une base de connaissances externe au moment de chaque requête. Les documents pertinents sont récupérés, puis injectés dans le contexte du modèle avant qu'il ne génère sa réponse. C'est ce qui permet à votre assistant IA interne de répondre avec des données actualisées, spécifiques à votre organisation.

Le problème fondamental est que toute l'architecture repose sur une hypothèse implicite : la base de connaissances est fiable. Quand cette hypothèse tombe, chaque requête envoyée au système devient un vecteur potentiel de désinformation.

Contrairement à l'injection de prompt, qui cible une requête individuelle et affecte un seul utilisateur pendant une seule session, l'empoisonnement de documents persiste indéfiniment. Un seul événement de contamination affecte silencieusement tous les utilisateurs qui posent une question sur le sujet concerné, pendant des semaines ou des mois, jusqu'à ce que quelqu'un détecte le problème.

L'OWASP Top 10 pour les applications LLM 2025 classe formellement cette menace sous la catégorie LLM08:2025, reconnaissant la base de connaissances et la couche d'embedding comme une surface d'attaque distincte du modèle lui-même.

Et les bases de connaissances d'entreprise ont de nombreux points d'entrée en écriture : wikis Confluence, dépôts SharePoint, archives Slack, PDF uploadés par des collaborateurs, sorties de pipelines automatisés. Chacun de ces chemins est un vecteur d'injection potentiel.

Comment fonctionne une attaque par empoisonnement

Pour comprendre la menace, il faut comprendre la mécanique. L'attaque démontrée par Amine Raji repose sur un cadre théorique formalisé par Zou et al. dans leurs recherches publiées à USENIX Security 2025, et se décompose en cinq étapes.

Étape 1 : Reconnaissance

L'attaquant identifie un sujet à forte valeur dans la base de connaissances : résultats financiers, politiques RH, procédures de conformité, configurations de sécurité. Il interroge le système RAG pour comprendre quels documents existent déjà et quel vocabulaire ils utilisent.

Étape 2 : Ingénierie du vocabulaire

L'attaquant rédige des documents fabriqués qui reproduisent le vocabulaire métier des documents ciblés. En utilisant les mêmes termes (« Q4 2025 », « Résultats Financiers », « Chiffre d'affaires », « CHIFFRES CORRIGÉS »), il maximise la similarité cosinus entre ses faux documents et les requêtes pertinentes. Il ajoute des marqueurs d'autorité : « approuvé par le DAF », « remplace toutes les versions précédentes », « correction officielle ».

Étape 3 : Injection multi-documents

C'est le point crucial. L'attaquant n'injecte pas un seul document, mais trois à cinq, chacun racontant la même fausse histoire sous un angle différent :

• Document 1 (« Correction approuvée par le DAF ») : présente les chiffres « corrigés » avec une autorisation du directeur financier, qualifiant explicitement les vrais chiffres d'erreur.

• Document 2 (« Notification réglementaire ») : cite les deux séries de chiffres, présentant les vrais (24,7 M$) comme « initialement rapportés » (donc remplacés). Introduit une fausse enquête de la SEC pour amplifier l'autorité.

• Document 3 (« Notes du conseil d'administration ») : troisième source corroborante, montrant que le conseil a examiné et accepté les chiffres « corrigés ».

Trois sources qui se confirment mutuellement. Toutes utilisent le même vocabulaire financier. Le document légitime est mis en minorité.

Étape 4 : Déplacement dans la récupération

Quand un utilisateur pose une question pertinente, le système de récupération calcule la similarité cosinus entre la requête et tous les documents. Les documents empoisonnés, conçus pour être sémantiquement proches de la requête, obtiennent les meilleurs scores et dominent les résultats top-k. Le document légitime peut encore être récupéré, mais il est désormais en infériorité numérique.

Étape 5 : Génération biaisée par l'autorité

Le LLM lit tous les chunks récupérés. Les documents empoisonnés contiennent un cadrage d'autorité (« correction approuvée par le DAF », « retraitement validé par le conseil ») tandis que le document légitime n'a aucun signal d'autorité particulier. Le modèle traite le récit de correction comme plus crédible. Il produit la réponse souhaitée par l'attaquant, avec confiance.

Point essentiel : dans la démonstration de Raji, les vrais chiffres (24,7 M$ de CA) étaient bien présents dans la fenêtre de contexte. Le document légitime a été récupéré. Le LLM a quand même choisi de le contredire, parce que le cadrage narratif des documents empoisonnés a prévalu sur le contenu factuel.

95% de réussite : les chiffres qui font peur

Les résultats mesurés par Raji sur son laboratoire local sont sans appel. L'attaque a réussi dans 19 cas sur 20 à temperature=0.1, soit un taux de succès de 95%. Le seul échec était une réponse mitigée qui mentionnait les deux séries de chiffres sans trancher.

Mais le plus inquiétant, c'est que ces résultats sont cohérents avec la recherche académique à grande échelle :

Le point critique révélé par PoisonedRAG : 5 documents suffisent pour atteindre 90% de succès dans une base contenant des millions de documents. L'attaque ne nécessite pas de compromettre une proportion significative du corpus. Elle fonctionne par précision chirurgicale sur la similarité sémantique.

Et le matériel nécessaire ? Un MacBook Pro, sans GPU, sans cloud, sans clé API. Raji a exécuté l'ensemble de sa démonstration en local avec LM Studio, ChromaDB et un modèle Qwen2.5-7B. Le code est disponible sur GitHub.

Quelques statistiques complémentaires qui situent le contexte global : selon une enquête relayée par Dark Reading, 48% des professionnels de la cybersécurité identifient l'IA agentique comme le principal vecteur d'attaque pour 2026. D'après le rapport Metomic, 68% des organisations ont déjà subi des fuites de données liées à l'utilisation d'outils IA, et seulement 23% disposent de politiques de sécurité IA formalisées.

Qui est réellement menacé par l'empoisonnement RAG

Risque maximal

Les organisations avec des bases de connaissances ouvertes en écriture. Si vos collaborateurs peuvent uploader des documents dans un SharePoint, Confluence, Notion ou tout système similaire qui alimente un pipeline RAG, vous êtes exposé. L'attaque ne nécessite qu'un accès en écriture à la base de connaissances, et cet accès est généralement distribué largement.

Les systèmes RAG multi-tenants avec bases partagées. Les plateformes SaaS où les clients contribuent des documents à un corpus partagé. Un document malveillant d'un client peut affecter les requêtes de tous les autres.

Les pipelines d'ingestion automatisés sans revue humaine. Synchronisations Confluence-vers-RAG, archivage Slack-vers-RAG, collecteurs web. Tout pipeline qui ingère du contenu automatiquement sans validation humaine est un chemin d'injection à faible friction.

Scénarios concrets par secteur

Finance et relations investisseurs : un contractuel avec un accès Confluence injecte trois faux mémos de correction dans la base financière. Chaque dirigeant qui interroge l'assistant IA interne sur les performances du trimestre reçoit des chiffres falsifiés. Les décisions stratégiques, les présentations au conseil et les communications aux investisseurs sont corrompues avant que quiconque ne s'en aperçoive.

Juridique et conformité : un document de politique empoisonné affirme qu'une exigence réglementaire spécifique a été « mise à jour » et ne s'applique plus à l'entreprise. L'assistant juridique, utilisé par des non-spécialistes pour répondre aux questions de conformité, produit systématiquement des conseils incorrects. Des violations de conformité surviennent avant la découverte du document.

RH et gestion des effectifs : des documents fabriqués prétendant être une « politique de rémunération mise à jour » ou des « conditions de licenciement révisées » sont injectés. Les employés qui interrogent le chatbot RH reçoivent des informations erronées sur leurs avantages ou leurs droits.

Opérations de sécurité : un document empoisonné contient une instruction déguisée en « mise à jour de la procédure de réponse aux incidents » : lorsque les employés rencontrent une erreur spécifique, ils doivent « réinitialiser leurs identifiants via un lien contrôlé par l'attaquant ». L'assistant de sécurité alimenté par RAG récupère cette instruction et transmet le lien de phishing aux utilisateurs avec toute l'autorité d'un guide officiel. Ce scénario d'attaque « Confused Deputy » a été documenté par Deconvolute Labs.

Comment protéger votre système RAG (checklist)

L'enseignement principal des recherches de Raji est clair : les défenses appliquées au niveau de la génération (prompt hardening, filtrage des sorties) sont systématiquement moins efficaces que celles appliquées au niveau de l'ingestion (détection d'anomalies d'embedding, contrôle d'accès). Le bon endroit pour arrêter une attaque d'empoisonnement, c'est avant que le document n'entre dans la collection, pas après qu'il a été récupéré.

Voici les 7 couches de défense, classées par efficacité mesurée :

Couche 1 : Détection d'anomalies d'embedding à l'ingestion (la plus efficace)

Avant qu'un nouveau document n'entre dans la base vectorielle, calculez son embedding et effectuez deux vérifications : (1) la similarité cosinus avec les documents existants est-elle anormalement élevée ? (attaque potentielle par remplacement) ; (2) les documents ingérés simultanément forment-ils un cluster trop dense ? (injection coordonnée potentielle).

Efficacité mesurée : réduit le taux de succès de l'attaque de 95% à 20% en contrôle autonome. C'est la défense individuelle la plus efficace, et elle ne nécessite qu'environ 50 lignes de Python utilisant les embeddings que votre pipeline produit déjà.

```python for new_doc in candidate_documents: similarity_to_existing = max( cosine_sim(new_doc.embedding, existing.embedding) for existing in collection ) if similarity_to_existing > 0.85: flag("similarité élevée, revue manuelle requise")

cluster_density = mean_pairwise_similarity(candidate_documents) if cluster_density > 0.90: flag("cluster dense, injection coordonnée possible") ```

Couche 2 : Contrôle d'accès (ACL) sur l'ingestion de documents

Implémentez du filtrage par métadonnées et du contrôle d'accès basé sur les attributs (ABAC) sur la base de connaissances. Tous les documents ne doivent pas être récupérables par tous les utilisateurs pour toutes les requêtes. Si un document SharePoint nécessite l'approbation du DAF pour être lu, son embedding vectoriel doit porter la même restriction d'accès.

Efficacité mesurée : réduit le taux de succès de 95% à 70%. Pas suffisant seul, mais limite le rayon d'impact d'une injection réussie.

Couche 3 : Suivi de provenance des documents

Chaque chunk dans la base de connaissances porte un enregistrement de provenance : système source, horodatage d'ingestion, auteur/propriétaire, chaîne d'autorisation, et idéalement signature cryptographique. Ces métadonnées sont exposées au LLM dans le contexte de récupération, lui donnant des éléments structurés pour évaluer les sources concurrentes.

Comme l'a souligné un commentateur sur Hacker News : « Si l'information de source ne peut pas être reliée à une personne dans l'organisation, alors elle n'a pas sa place dans le document store RAG en tant qu'information faisant autorité. »

Couche 4 : Monitoring et alertes

Surveillance en temps réel des événements d'ingestion, des patterns de récupération et des patterns de sortie. Alertez sur les insertions en masse, les sources sans historique d'ingestion, les documents qui prétendent remplacer des documents à forte valeur.

Efficacité mesurée : le monitoring basé sur des patterns réduit le succès de 95% à 60%. Limitation : les réponses financières empoisonnées dans la démonstration de Raji ressemblent à des résumés financiers normaux. Le monitoring par patterns attrape les attaques évidentes, pas les sophistiquées. Pour les systèmes de production, envisagez Llama Guard 3 ou NeMo Guardrails pour une classification basée sur le ML. RAGDefender a réduit le taux de succès d'attaque sur Gemini de 0,89 à 0,02 lors de tests.

Couche 5 : Validation et assainissement à l'ingestion

Filtrage des documents avant leur entrée dans la base pour détecter les instructions embarquées (marqueurs d'injection de prompt), le contenu caché (Unicode invisible, champs de métadonnées), et le contenu qui prétend remplacer des documents autoritaires existants.

Efficacité mesurée : aucun impact (95% reste 95%) contre les attaques par ingénierie de vocabulaire, car les documents fabriqués ressemblent parfaitement à des documents légitimes. Cependant, cette couche est efficace contre les variantes qui embarquent des instructions explicites dans les fichiers DOCX, HTML ou PDF.

Couche 6 : Durcissement du prompt système

Modifiez votre prompt système pour instruire explicitement le LLM de traiter le contexte récupéré comme des données externes, et non comme des instructions. Ajoutez des consignes pour gérer les sources contradictoires : raisonner sur la provenance, privilégier la source la plus récemment ingérée et la plus autoritaire.

Efficacité mesurée : réduit le succès de 95% à 85%. Réduction modeste. Le cadrage d'autorité dans les documents empoisonnés s'apparente à de l'injection de prompt douce, et le prompt hardening ne l'adresse que partiellement.

Couche 7 : Snapshots et rollback de la base vectorielle

Maintenez des snapshots périodiques de votre base vectorielle à des états connus comme sains. Si un empoisonnement est découvert, le rollback vers le dernier snapshot propre est plus rapide et plus fiable que la recherche et suppression chirurgicale des documents injectés.

``python import shutil, datetime shutil.copytree( "./chroma_db", f"./chroma_db_snapshots/{datetime.date.today().isoformat()}" ) ``

Exécutez cette opération avant chaque ingestion en masse. C'est l'équivalent des sauvegardes de base de données, une pratique standard que très peu de déploiements RAG implémentent.

Synthèse de l'efficacité des défenses

La recherche académique récente apporte des défenses complémentaires. RAGPart et RAGMask (Pathmanathan et al., décembre 2025) opèrent directement sur le retriever, identifiant les tokens suspects par analyse de masquage ciblé. SDAG (Dekel et al., février 2026) utilise l'attention clairsemée par blocs pour interdire l'attention croisée entre documents récupérés. RevPRAG (EMNLP 2025) détecte les réponses empoisonnées par analyse des patterns d'activation du LLM, avec un taux de vrais positifs de 98% pour environ 1% de faux positifs.

RAG vs fine-tuning : lequel est le plus sûr ?

C'est une question que nos clients chez Bridgers posent régulièrement. Le RAG et le fine-tuning sont les deux principales approches pour spécialiser un LLM sur des données d'entreprise. Mais leurs profils de risque sont fondamentalement différents.

Le fine-tuning modifie les poids du modèle lui-même. L'attaque équivalente (empoisonnement des données d'entraînement) nécessite l'accès au pipeline de fine-tuning, un volume significatif de données malveillantes, et un nouveau cycle d'entraînement pour que l'empoisonnement prenne effet. C'est plus coûteux, plus lent, et plus difficile à exécuter sans détection.

Le RAG ne touche pas au modèle. L'attaque cible uniquement la base de connaissances externe, qui est souvent beaucoup plus accessible que le pipeline de fine-tuning. Trois documents suffisent. L'effet est immédiat dès l'ingestion. Et la détection est plus complexe, parce que le modèle lui-même n'a pas changé.

En résumé : le RAG offre plus de flexibilité et une mise à jour plus facile des connaissances, mais il expose une surface d'attaque plus large et plus accessible. Le fine-tuning est plus difficile à empoisonner, mais quand c'est fait, le problème est ancré dans les poids du modèle et beaucoup plus difficile à corriger.

Pour la plupart des cas d'usage en entreprise, le RAG reste le bon choix. Mais il doit être déployé avec les couches de défense appropriées. C'est exactement pourquoi, chez Bridgers, nous intégrons systématiquement la détection d'anomalies d'embedding et le suivi de provenance dans chaque architecture RAG que nous livrons.

Ce que les entreprises doivent faire maintenant

Cette semaine

• Auditez chaque chemin d'écriture dans votre base de connaissances. Identifiez tous les éditeurs humains ET tous les pipelines automatisés (synchronisation Confluence, archivage Slack, connecteurs SharePoint, scripts de build de documentation). Si vous ne pouvez pas les énumérer tous, vous ne pouvez pas les sécuriser.

• Implémentez la détection d'anomalies d'embedding à l'ingestion. Environ 50 lignes de Python utilisant les embeddings que votre pipeline produit déjà. C'est le contrôle individuel au meilleur rapport efficacité/effort.

• Configurez des snapshots de votre base vectorielle avant chaque ingestion en masse. En cas d'attaque découverte, le rollback sera plus rapide et plus fiable que l'investigation forensique.

Ce mois-ci

• Appliquez la classification de documents et les ACL à votre base vectorielle. Le même modèle d'accès qui gouverne la lecture d'un document SharePoint doit gouverner la récupération de son embedding.

• Ajoutez des métadonnées de provenance à chaque chunk. Source, auteur, horodatage d'ingestion, niveau de classification. Exposez ces métadonnées dans le contexte du prompt.

• Durcissez votre prompt système. Instruisez explicitement le LLM de traiter le contexte récupéré comme des données externes. Ajoutez des consignes pour les sources contradictoires.

• Configurez le monitoring des sorties. Même un monitoring par patterns (regex sur les chiffres sensibles connus) attrape 40% des attaques.

Ce trimestre

• Définissez un playbook de réponse aux incidents RAG. Comment détecterez-vous un empoisonnement ? Qu'est-ce qui déclenche un rollback ? Qui est notifié ?

• Implémentez des niveaux de confiance par source. Les systèmes financiers officiels ne doivent pas avoir le même poids que les documents uploadés par les utilisateurs ou les archives Slack.

• Réalisez un exercice de red-team. Avec un accès autorisé, tentez d'injecter des documents fabriqués et mesurez le temps avant détection.

• Abaissez la température du LLM pour les cas d'usage critiques. À temperature=0.1, le taux de succès résiduel est significativement plus bas qu'à 0.5 ou plus.

Le SEO des embeddings : un problème sans solution mature

Un commentateur sur Hacker News a résumé la situation avec une analogie percutante : « L'ingénierie de vocabulaire est fondamentalement l'équivalent du SEO pour les embeddings. Vous optimisez pour la similarité cosinus au lieu du PageRank. Et contrairement au SEO, il n'existe pas encore d'écosystème d'outils de détection. »

L'analogie est juste. Le web a mis vingt ans à développer des défenses contre la manipulation du SEO. L'écosystème RAG a environ deux ans d'existence, et les outils de détection sont embryonnaires.

Mais l'évolution est rapide. La menace s'intensifie avec les systèmes d'IA agentique : quand le RAG alimente des agents qui peuvent exécuter des actions autonomes (appeler des API, envoyer des emails, écrire des fichiers), un document empoisonné ne provoque plus seulement une mauvaise réponse, il déclenche une action. Comme l'a analysé Lakera dans son rapport 2026, « ce qui était autrefois une menace académique est désormais une surface d'attaque pratique : dépôts empoisonnés, contenu web empoisonné, outils empoisonnés et datasets empoisonnés ».

Si vous construisez ou opérez un système RAG en production, la question n'est pas de savoir si cette menace vous concerne. Elle vous concerne. La question est de savoir combien de couches de défense vous avez en place aujourd'hui. Si la réponse est zéro, vous savez par où commencer : 50 lignes de Python pour la détection d'anomalies d'embedding, et un snapshot avant chaque ingestion. C'est le minimum. Et c'est exactement le type d'architecture que nous mettons en place chez Bridgers pour chaque projet RAG que nous livrons.