L'empoisonnement d'un RAG en une page

On a branché l’assistant sur les documents de l’entreprise pour qu’il cesse d’inventer : il récite désormais, avec la même assurance, ce que le dernier venu a bien voulu écrire dans le wiki.

L’essentiel

• Le RAG, en deux temps. La génération augmentée par récupération (Retrieval-Augmented Generation) cherche d’abord, dans un corpus indexé, les extraits les plus proches de la question, puis les colle dans le contexte du modèle, qui rédige sa réponse à partir d’eux. Le modèle ne sait que ce qu’on lui a apporté.
• Proche n’est pas vrai. La recherche vectorielle mesure une ressemblance de sens entre la question et les extraits, pas leur exactitude ni leur origine. Un texte écrit pour ressembler à la question remonte en tête, c’est même ce qu’on lui demande.
• Deux effets, un seul document. L’extrait piégé peut tromper (une fausse procédure, un faux numéro, une fausse règle, citée comme source) ou commander (une consigne glissée dans le texte, que le modèle suit : c’est l’injection de prompt indirecte, arrivée par le corpus).
• Il en faut peu. Les travaux publiés sur le sujet, dont PoisonedRAG (Zou et al., 2024), montrent qu’une poignée de textes conçus pour une question donnée suffit à orienter la réponse, même noyés dans des millions de documents. L’OWASP range le risque dans son Top 10 for LLM Applications 2025, sous LLM04 (empoisonnement) et LLM08 (faiblesses des vecteurs et des embeddings).
• La porte d’entrée est banale : un wiki ouvert à tous en écriture, une boîte de dépôt, des tickets clients, des pages web aspirées, un PDF reçu par courriel et indexé tel quel. Le corpus est aussi sûr que le moins surveillé de ses rédacteurs.
• Les parades, de l’amont vers l’aval : provenance et contrôle d’entrée des documents (qui a écrit, quand, validé par qui), droits du demandeur appliqués au moment de la récupération et pas seulement à l’indexation, citations que le lecteur peut ouvrir et vérifier, extraits encadrés et marqués comme des données à résumer, jamais comme des ordres.
• Et les droits de l’assistant. Un assistant qui ne fait que répondre peut se tromper ; s’il dispose d’outils (envoyer, modifier, payer), l’extrait piégé devient une commande à distance. On borne ses outils comme ceux de n’importe quel agent.

Idées reçues, et fausses

• « Le RAG supprime les hallucinations. » Faux. Il les réduit quand le corpus est juste, et les remplace par des citations fausses quand il ne l’est pas. Le progrès est réel : l’erreur arrive désormais avec sa source, ce qui la rend plus convaincante.
• « Nos documents internes sont fiables. » Faux. Ils sont internes, ce qui n’est pas la même chose. Y figurent des pages que personne n’a relues depuis des années, des fichiers reçus de l’extérieur et tout ce que peut écrire un compte compromis.
• « Les droits sont gérés, l’index est derrière l’authentification. » Faux. L’authentification dit qui entre dans l’assistant, pas quels extraits il a le droit de lui montrer. Sans filtrage par les droits du demandeur à la récupération, le RAG devient le moyen le plus aimable de lire ce qu’on n’aurait pas pu ouvrir.
• « Il suffit de dire au modèle d’ignorer les consignes des documents. » Faux. La consigne et l’extrait sont du même texte, lu dans le même flux. On réduit l’obéissance, on ne l’abolit pas : c’est pourquoi la vérification de la source et la limitation des outils restent indispensables.

Pour aller plus loin : L’injection de prompt indirecte en une page · Sécuriser un corpus RAG contre l’injection indirecte · Contrôler les accès d’un assistant IA interne · Embeddings : vecteurs, recherche sémantique et RAG · Empoisonnement des données d’affinage d’un LLM local · Guardrails programmatiques pour assistant IA · Exfiltration par rendu Markdown dans un chat IA.

À lire aussi

• Quand la recherche sémantique contourne les droitsUn RAG qui indexe des documents sans reporter leurs droits d'accès transforme la base vectorielle en contournement du contrôle d'accès. Le filtrage doit se faire au moment de la requête, par le moteur et non par le modèle, et l'index lui-même doit être classé comme les documents qu'il contient.
• Gardien IA pour LLM, fonctionnement, exemples et choix de produitCe qu'est un gardien en IA (modèle de garde placé autour d'un LLM), comment il filtre entrées, sorties et actions d'agent, ce qu'il ne garantit pas et quel produit retenir selon l'architecture.
• Fine-tuning en IA, définition, usages et limitesCe qu'est le fine-tuning d'un modèle d'IA, à quoi il sert vraiment, ce qu'il ne garantit pas, sa surface d'attaque et ses conditions d'exploitation.
• Fine-tuning local ou RAG pour données internesComparer le fine-tuning local et le RAG pour exploiter des données internes sans augmenter inutilement le risque de fuite.

Pages voisines

L'empoisonnement d'un RAG en une page

Elle cite

• L'injection de prompt indirecte en une page
• Contrôler les accès d’un assistant IA interne
• Embeddings : vecteurs, recherche sémantique et RAG
• Empoisonnement des données d'affinage d'un LLM local et backdoor
• Exfiltration par rendu Markdown dans un chat IA
• Guardrails programmatiques pour assistant IA de production
• Sécuriser un corpus RAG contre l’injection indirecte