Une fois que RAG ancre les sorties du LLM dans des bases de connaissances externes, le corpus lui-même devient une surface d’attaque. Les cinq plongées profondes précédentes de sécurité LLM attaquaient l’entrée (8 types d’injection), l’appel (8 types d’escalade), la surface d’outils (8 types d’empoisonnement), la sortie (8 types de fuite) et la persistance de mémoire (8 types d’empoisonnement). Cet article est la sixième dimension — couche de persistance de corpus / base de connaissances — plongée profonde verticale, transformant « l’empoisonnement de corpus » d’un terme d’article en un manuel d’attaque et de défense actionnable en production.

La similarité et la différence entre les attaques sur le corpus et les attaques sur la mémoire : les deux sont « persistantes », mais le corpus est source de fait partagée au niveau entreprise (les correspondances de retrieval RAG affectent tous les utilisateurs, toutes les requêtes) ; la mémoire est état local d’auto-apprentissage de l’agent (n’affecte qu’une seule instance d’agent). L’article RAGShield révèle un point de donnée critique : 10 passages malveillants (0.04% du corpus) peuvent atteindre un taux de succès de retrieval de 98.2% — une seule injection de corpus peut affecter en permanence toutes les sorties de requêtes futures.

Vue d’ensemble de 30 secondes

  • Le corpus RAG est la surface d’attaque persistante de sixième dimension de l’ère LLM — OWASP LLM Top 10 2026 (publié le 9-1) liste l’empoisonnement de corpus dans la catégorie principale ; Agentic Top 10 2026 ASI04 Agentic Supply Chain mappe directement
  • 8 variantes d’empoisonnement de corpus (progressant par cycle de vie du corpus : source de données → ingestion → stockage → retrieval → effet de sortie) : injection directe de passage malveillant / pollution indirecte de source de confiance / squatting de nom de corpus avec homoglyphes / inversion d’embedding / empoisonnement GraphRAG / RAG multi-modal / accumulation de boucle de feedback de réentraînement / collision de nom de paquet de supply chain
  • 5 incidents/articles réels de 2026 : RAGShield RAG gouvernemental 10 passages 0.04% → 98.2% retrieval success, Phantom attack même point de donnée, PoisonedRAG 5 passages → 90%+ ASR sur NQ/HotpotQA/MS-MARCO, empoisonnement GraphRAG ACL 2026, défense SDAG block-sparse attention
  • Plan de défense de 7 jours (chacun ≤ 30 minutes pour démarrer) : whitelist de source de corpus + signature numérique / détection de drift d’embedding / pipeline provenance-verified / isolation block-sparse attention / cohérence hop-wise de GraphRAG / hashing de contenu multi-modal / scoring de retriever + LLM-as-judge / provenance de supply chain de corpus
  • Utilisez l’ensemble d’outils Piick pour déboguer les jetons, URLs, regex et payloads encodés côté corpus RAG — tous les outils tournent 100% en local et ne sont jamais téléversés, gardant votre journal d’audit propre

Pourquoi le corpus RAG est la surface d’attaque de sixième dimension à l’ère du LLM

Pour comprendre pourquoi les 8 variantes d’empoisonnement de corpus fonctionnent, revenons à l’essence du RAG : sortie du LLM = retrieval(query) + LLM(prompt + retrieved context). Tout ce que le LLM voit comme « fait » provient du retrieval du corpus ; si le corpus est empoisonné, la sortie du LLM est empoisonnée.

Rayon d’explosion de l’attaque au corpus :

Le corpus est source de fait partagée au niveau entreprise — une injection, affecte toutes les requêtes futures, tous les utilisateurs Le retrieval du corpus ne distingue pas « passage de confiance vs passage d’attaque » — il ne vérifie que la similarité d’embedding L’auto-ingestion du corpus tire du contenu externe — wiki / doc / issue GitHub / commentaires de blog, auto-ajoutés au store La supply chain du corpus est complexe — loader / connector / package / embedding model / vector DB, chaque maillon est attaquable

arxiv 2604.00387 RAGShield a validé empiriquement : 10 passages malveillants (0.04% corpus) atteignent 98.2% retrieval success (le point de donnée de Phantom attack concorde) ; PoisonedRAG 5 passages injectés dans un corpus à l’échelle du million → 90%+ ASR sur NQ / HotpotQA / MS-MARCO. Le ROI de l’empoisonnement de corpus est extrême : petite entrée, grand impact.

Pire, les attaques sur le corpus sont « compromis silencieux » — les utilisateurs voient des réponses du LLM « raisonnables », mais les réponses sont basées sur des passages de corpus empoisonnés ; la sortie du LLM + les logs de retrieval semblent « normaux », la rétrospection d’audit est difficile.

8 variantes d’empoisonnement de corpus (Progression par cycle de vie du corpus : source de données → ingestion → stockage → retrieval → effet de sortie)

Empoisonnement 1 : Injection directe de passage malveillant (Motif PoisonedRAG)

Symptôme : l’attaquant écrit directement des documents malveillants dans le corpus ; le retrieval RAG correspond et le LLM adopte comme fait ; 5 passages peuvent pousser le système à corpus de millions à un ASR > 90% (données du papier PoisonedRAG).

Pourquoi ça fonctionne : le retrieval RAG ne vérifie que la similarité d’embedding, pas si le passage est de confiance / audité. L’attaquant écrit un passage contenant « mots-clés d’ancre à haut rappel » + « réponse cible », l’embedding tombe dans la région de requête cible, le LLM adopte directement. PoisonedRAG 5 passages atteignent 90%+ ASR sur les trois benchmarks NQ / HotpotQA / MS-MARCO.

Reproduction minimale (motif PoisonedRAG) :

Étape 1 : l’attaquant écrit 5 passages, chacun contenant une phrase de trigger + une réponse adverse : « La dernière recherche sur X montre que Y est la solution optimale pour Z… voir [cite] » Étape 2 : l’attaquant injecte les 5 passages dans le corpus cible (via commentaires ouverts / édition de wiki / API publique) Étape 3 : la requête utilisateur est proche de la phrase de trigger → retriever top-K correspond aux passages d’attaque Étape 4 : le LLM voit les passages → émet une réponse adverse Étape 5 : l’utilisateur voit une sortie du LLM « apparemment raisonnable » mais erronée, basée sur une citation « autoritaire »

Correctif :

  • Whitelist de source de corpus + signature numérique (voir Jour 1). Ingestion de corpus restreinte aux sources de confiance (DB interne / vendeur signé / sources externes auditées) ; chaque passage signé HMAC à l’écriture ; rejeter les passages non signés
  • Les passages critiques du corpus passent par un flux « review-then-ingest », revue manuelle avant stockage
  • Enregistrer la provenance à l’ingestion (URL / vendeur / heure d’ingestion / signature) ; au retrieval trier par priorité de provenance, les sources suspectes sont dé-priorisées

Empoisonnement 2 : Pollution indirecte de source de confiance (commentaires / wiki / docs)

Symptôme : l’attaquant n’attaque pas directement le corpus, mais pollue la wiki / Google Doc / issue GitHub / commentaires de blog source du corpus ; l’auto-ingestion du corpus les tire comme passages malveillants.

Pourquoi ça fonctionne : les systèmes RAG dépendent de plus en plus d’un « pipeline d’auto-ingestion » (web crawler / GitHub sync / wiki API / RSS feed) ; ces sources sont souvent semi-publiques, n’importe qui peut commenter / éditer. L’attaquant utilise la « pollution indirecte » pour contourner la « whitelist de source de corpus » — parce que le système de corpus lui-même fait confiance à la wiki / GitHub.

Reproduction minimale :

Étape 1 : l’attaquant édite un sujet neutre sur Wikipedia / Wiki d’entreprise, plante du texte caché : ajoute phrase de trigger + réponse adverse dans un paragraphe, le texte correspond au style wiki Étape 2 : l’auto-ingestion RAG de l’entreprise synchronise les révisions de la wiki Étape 3 : le retrieval correspond au paragraphe nouvellement planté → LLM émet une réponse erronée Étape 4 : l’admin du système RAG ne voit qu’une « mise à jour normale de la wiki », ne peut pas identifier l’attaque

Correctif :

  • Pipeline provenance-verified (voir Jour 3). Le pipeline RAG ajoute une vérification de provenance à 5 couches (en s’inspirant de l’approche RAGShield) : ingestion → signing → audit → reweighting → retrieval threshold ; imite la défense de supply chain logicielle
  • Les sources d’auto-ingestion passent par une revue éditoriale : « wiki auto-sync » mais tout contenu nouveau / modifié passe par une revue AI-as-judge avant stockage
  • Les passages critiques utilisent la vérification à double source : le même sujet doit apparaître dans 2 sources de confiance indépendantes

Empoisonnement 3 : Squatting de nom de corpus avec homoglyphes

Symptôme : un corpus malveillant utilise un nom avec des homoglyphes (similaire au typosquatting) pour s’enregistrer sur le marketplace de vector DB ; l’entreprise l’ingère par erreur.

Pourquoi ça fonctionne : les marketplaces de vector DB (Pinecone / Weaviate / Qdrant, etc.) permettent l’enregistrement de corpus tiers ; la revue d’enregistrement de namespace est laxiste. L’attaquant enregistre un nom quasi-similaire comme wikipedia-ml-articles (le vrai est wikipedia-ml) ; l’entreprise configure le corpus avec une faute de frappe / mauvais choix, tire le corpus malveillant.

Reproduction minimale :

Étape 1 : l’attaquant enregistre un corpus malveillant nommé wikipedia-ml-articles sur le marketplace (le vrai est wikipedia-ml) Étape 2 : l’ingénieur RAG de l’entreprise configure le corpus avec une faute de frappe vers wikipedia-ml-articles Étape 3 : le corpus est tiré → passages malveillants mélangés Étape 4 : le retrieval correspond au passage malveillant → la sortie du LLM est contaminée

Correctif :

  • Whitelist de source de corpus + signature numérique (voir Jour 1). L’enregistrement de corpus doit être signé, le contenu du corpus doit avoir un manifeste signé ; seuls les corpus en whitelist peuvent être ingérés
  • Le corpus critique utilise la « vérification de checksum » : vérifier périodiquement que le hash du contenu du corpus correspond à l’officiel
  • Surveiller les anomalies de distribution des sources du corpus : pic dans la part d’un corpus → alerte

Empoisonnement 4 : Inversion d’embedding pour inverser les requêtes

Symptôme : les vecteurs d’embedding des passages dans le corpus sont attaqués par inversion → l’attaquant inverse l’embedding vers le contenu de la requête d’origine, fuite de la vie privée de l’utilisateur.

Pourquoi ça fonctionne : la vector DB stocke les vecteurs d’embedding des passages ; les embeddings semblent « anonymisés », mais la recherche prouve que vous pouvez inverser le texte d’origine (contenu de requête / de passage) à partir des embeddings avec une grande précision. L’attaquant obtient le dump d’embeddings du corpus → inverse l’historique des requêtes de l’utilisateur.

Reproduction minimale :

Étape 1 : l’attaquant obtient le dump de la vector DB (fuite / sur-privilège) Étape 2 : utilise un modèle d’inversion entraîné pour inverser l’embedding du passage vers le texte du passage Étape 3 : les passages inversés contiennent des informations sensibles (requête utilisateur / résumé de document interne) Étape 4 : l’attaquant reconstitue l’historique complet des requêtes de l’utilisateur, fuite du savoir de l’entreprise

Correctif :

  • Détection de drift d’embedding (voir Jour 2). Passages mutant l’embedding → alerte + revue manuelle ; comparaison périodique de hash des embeddings du corpus, toute modification laisse un log d’audit
  • Les passages critiques utilisent l’embedding chiffré : chiffré au stockage, déchiffré au retrieval, même le dump ne peut pas récupérer le texte d’origine
  • Contrôle d’accès : l’API de la vector DB impose mTLS + token TTL court, minimiser la fenêtre de fuite

Empoisonnement 5 : Empoisonnement de knowledge-graph GraphRAG (ACL 2026)

Symptôme : GraphRAG injecte des entités et relations spurieuses pendant la construction du graphe ; contamine le sous-graphe spécifique à la requête → le LLM génère des réponses erronées.

Pourquoi ça fonctionne : GraphRAG construit le corpus en un knowledge graph, puis utilise la traversée de graphe pour le retrieval. La phase de construction du graphe est la fenêtre d’attaque — l’attaquant écrit des entités + relations fausses, la construction du graphe les auto-inclut. La traversée du graphe au moment de la requête touche des nœuds faux → le LLM voit un contexte faux → émet une réponse erronée. L’article ACL 2026 HoG-GRAG a validé empiriquement : le sous-graphe de GraphRAG est une nouvelle surface d’attaque.

Reproduction minimale (motif GraphRAG ACL 2026) :

Étape 1 : l’attaquant écrit un passage malveillant prétendant une fausse entité « HyperTransport Protocol v2 » Étape 2 : la phase de construction de GraphRAG ajoute la fausse entité au graphe Étape 3 : requête utilisateur « transport protocols for high-speed networking » Étape 4 : la traversée du graphe touche la fausse entité « HyperTransport Protocol v2 » Étape 5 : le LLM émet une réponse « autoritaire » basée sur la fausse entité

Correctif :

  • Vérification de cohérence hop-wise de GraphRAG (voir Jour 5). GraphRAG décompose la requête multi-hop en sous-requêtes ordonnées ; vérification de cohérence après chaque hop ; incohérence induite par empoisonnement → déclencher la réparation du sous-graphe (élaguer les entités + relations compromises)
  • Les entités critiques utilisent la vérification à double source : chaque entité doit avoir le support de 2 sources indépendantes
  • La construction du graphe passe par human-in-the-loop : nouvelle entité / relation requiert une revue manuelle

Empoisonnement 6 : Empoisonnement RAG multi-modal (passage image / PDF / audio)

Symptôme : le corpus contient des passages multi-modaux ; l’attaquant utilise la stéganographie d’image / PhantomText de PDF / payload d’attaque encodé en audio.

Pourquoi ça fonctionne : le corpus RAG moderne n’est pas seulement du texte, il contient souvent des passages image / PDF / audio. OCR / extraction de texte PDF / transcription audio ont tous des motifs d’attaque connus — les attaquants utilisent la stéganographie d’image pour cacher des prompts, la couche de texte cachée du PDF, des instructions malveillantes encodées en audio. Le retrieval RAG convertit le passage multi-modal en texte, le LLM voit du texte contenant l’attaque.

Reproduction minimale (motif PhantomText) :

Étape 1 : l’attaquant crée un PDF, le texte visible semble normal Étape 2 : la couche de texte cachée du PDF contient la phrase de trigger + la réponse adverse (texte blanc / taille 0 / hors écran) Étape 3 : le PDF est ingéré dans le corpus RAG Étape 4 : l’extraction de texte du PDF tire aussi le texte caché (extract-all par défaut) Étape 5 : le LLM voit le texte caché → émet la réponse adverse

Correctif :

  • Hashing de contenu multi-modal (voir Jour 6). Les passages image / PDF / audio dans le corpus sont hashés + scannés par OCR visuel pour les payloads d’attaque avant stockage ; les motifs d’attaque comme PhantomText sont pré-détectés
  • Les outils d’extraction multi-modale (OCR / pdftotext) utilisent une safe-config : mode visible-only / strip-hidden
  • Les passages multi-modaux passent par une détection adversarial-robust : utiliser un modèle dédié pour scanner les payloads d’attaque

Empoisonnement 7 : Accumulation de boucle de feedback de réentraînement continu

Symptôme : le mécanisme de feedback utilisateur du corpus est abusé — l’attaquant « signale » à répétition un passage comme erroné, déclenchant le réentraînement → accumulant progressivement les passages d’attaque comme autoritaires.

Pourquoi ça fonctionne : les systèmes RAG viennent souvent avec un mécanisme de « feedback utilisateur » — les utilisateurs marquent le passage utile / pas utile, le système utilise le feedback pour réentraîner le modèle d’embedding ou les poids de re-rank. L’attaquant marque à répétition un passage d’attaque comme « utile », le système ajuste l’embedding / re-rank → le passage d’attaque accumule plus de hits de retrieval → boucle d’auto-renforcement.

Reproduction minimale :

Étape 1 : l’attaquant écrit un passage riche en triggers + simule N comptes utilisateur marquant à répétition « utile » Étape 2 : le système réentraîne → l’embedding du passage d’attaque s’ajuste, le poids de re-rank augmente Étape 3 : les requêtes réelles ultérieures de l’utilisateur → la probabilité de correspondance du retriever pour le passage d’attaque augmente Étape 4 : la boucle d’attaque continue pendant des mois, le poids du passage d’attaque s’accumule jusqu’à devenir non négligeable Étape 5 : le corpus se contamine continuellement, l’admin ne voit rien d’anormal (données de feedback « normales »)

Correctif :

  • Scoring de retriever + LLM-as-judge (voir Jour 7). Le retriever note le top-K retrieval ; LLM-as-judge re-revue le top-K pour les motifs d’attaque
  • Le mécanisme de feedback passe par la détection d’anomalies : même user agent avec feedback massif en peu de temps → rate limit
  • La logique de réentraînement doit avoir un « sanity check bidirectionnel » : l’ajustement d’embedding piloté par le feedback ne peut pas changer significativement la distribution de retrieval top-K, sinon annuler

Empoisonnement 8 : Collision de nom de paquet de supply chain (Agentic ASI04)

Symptôme : le paquet / connector / loader de l’ingestion du corpus est remplacé (attaque de supply chain) ; le loader lui-même écrit des passages malveillants dans le store.

Pourquoi ça fonctionne : l’ingestion RAG dépend généralement de paquets externes : web crawler (scrapy / playwright) / connector (confluence / notion / slack) / loader (unstructured / langchain) / embedding model. N’importe lequel compromis, tout le corpus est contaminé. OWASP Agentic Top 10 2026 ASI04 Agentic Supply Chain Vulnerabilities mappe directement.

Reproduction minimale :

Étape 1 : l’attaquant enregistre un nom de paquet en typosquatting unstructured-loader (le vrai est unstructured) Étape 2 : le développeur pip install avec une faute de frappe → installe le paquet malveillant Étape 3 : l’ingestion RAG l’utilise pour parser les documents → chaque document plante secrètement un passage d’attaque Étape 4 : le corpus se contamine progressivement, sans anomalie évidente Étape 5 : l’attaque continue pendant des mois, le corpus a continuellement des passages malveillants plantés

Correctif :

  • Vérification de provenance de supply chain de corpus (voir Jour 7). Les outils d’ingestion de corpus (loader / connector / package) passent par la vérification de provenance de supply chain (signature + identité de l’éditeur + SBOM) ; détection de typosquatting
  • Les paquets critiques utilisent une version pinnée + vérification de signature ; lock file imposé
  • La gestion des paquets utilise un miroir d’entreprise (Sonatype Nexus / JFrog), scan de sécurité avant miroir

5 incidents / articles réels de 2026

Incident 1 : RAGShield RAG gouvernemental (arxiv 2604.00387, 2026-04-01)

Résumé de l’article : les systèmes RAG gouvernementaux font face à l’empoisonnement de corpus, simule 6 tiers d’attaque (T1 injection externe → T2 falsification de signature → T3 menace interne → T4 vulnérabilité de loader → T5 évasion adaptative → remplacement in-place). Donnée clé : 10 passages malveillants (0.04% corpus) 98.2% retrieval success (point de donnée de Phantom attack) ; propose une défense en profondeur à 5 couches (analogie supply chain logicielle).

Conclusion centrale : l’empoisonnement de corpus RAG est structurellement similaire aux attaques de supply chain logicielle, nécessitant une défense provenance-verified. Correspond directement au Foot-Gun 1 + Foot-Gun 8.

Incident 2 : Phantom Attack (H1 2026, Chaudhari et al.)

Description de l’attaque : valide empiriquement 10 passages adversariaux (0.04% du corpus) 98.2% taux de succès de retrieval ; injection minimale, impact maximal.

Conclusion centrale : le ROI de l’empoisonnement de corpus est extrême — petit volume d’attaque, grand dommage. Correspond directement au Foot-Gun 1.

Incident 3 : Cas classique PoisonedRAG (NQ / HotpotQA / MS-MARCO)

Résumé de l’article : 5 textes malveillants injectés dans un corpus à l’échelle du million → 90%+ ASR sur 3 datasets de benchmark ; a défini le paradigme complet de l’attaque d’empoisonnement de corpus RAG.

Conclusion centrale : PoisonedRAG est l’« article fondateur » de l’empoisonnement de corpus, 5 passages atteignant 90%+ ASR définit le plafond de ROI des attaques sur corpus. Correspond directement au Foot-Gun 1 + Foot-Gun 2.

Incident 4 : Empoisonnement GraphRAG ACL 2026 (défense HoG-GRAG)

Résumé de l’article : GraphRAG injecte des entités + relations spurieuses pendant la construction du graphe → contamine le sous-graphe spécifique à la requête → le LLM génère des réponses erronées. La défense HoG-GRAG (hop-wise guard) décompose la requête multi-hop en sous-requêtes ordonnées, surveillant l’exécution hop-wise pour les incohérences.

Conclusion centrale : le sous-graphe de GraphRAG est une nouvelle surface d’attaque pour l’empoisonnement de corpus, la vérification de cohérence hop-wise est actuellement la seule défense efficace. Correspond directement au Foot-Gun 5.

Incident 5 : Défense SDAG block-sparse attention (arxiv 2602.04711 v3, 2026-08-26)

Résumé de l’article : Sparse Document Attention RAG ; block-sparse attention bloque le cross-attention entre documents récupérés ; le masque d’attention restreint chaque document à ne voir que lui-même + la requête. La v3 intègre SDAG + RobustRAG / ReliabilityRAG avec des performances nettement améliorées.

Conclusion centrale : élimine l’attaque d’empoisonnement cross-document depuis la couche d’inférence, sans avoir besoin de détecter le contenu du corpus, isole l’attaque par mécanisme. Correspond directement au Foot-Gun 1 + Foot-Gun 2 défense.

Plan de défense de 7 jours

Jour 1 — Whitelist de source de corpus + signature numérique (15 minutes pour démarrer)

  • Ingestion de corpus restreinte aux sources de confiance (DB interne / vendeur signé / sources externes auditées)
  • Chaque passage signé HMAC à l’écriture (en s’inspirant de l’approche du batch-32) ; rejeter les passages non signés
  • Les passages critiques du corpus passent par un flux « review-then-ingest », revue manuelle avant stockage
  • Enregistrer la provenance à l’ingestion (URL / vendeur / heure d’ingestion / signature) ; trier par priorité de provenance au retrieval
  • Le squatting de nom de corpus avec homoglyphes / namespace directement bloqué par la whitelist

Jour 2 — Détection de drift d’embedding de document (30 minutes)

  • Vecteurs d’embedding de passages détection de drift hebdomadaire (même approche que le drift de mémoire du batch-32)
  • Passages mutant l’embedding → alerte + revue manuelle
  • Comparaison périodique de hash des embeddings du corpus, toute modification laisse un log d’audit
  • Les passages critiques utilisent l’embedding chiffré : chiffré au stockage, déchiffré au retrieval

Jour 3 — Pipeline provenance-verified (approche RAGShield, 1 heure)

  • Le pipeline RAG ajoute une vérification de provenance à 5 couches : ingestion → signing → audit → reweighting → retrieval threshold
  • Imite la défense de supply chain logicielle : chaque passage a un builder / signature / build metadata comme un « artefact logiciel »
  • Les sources d’auto-ingestion passent par une revue éditoriale : « wiki auto-sync » mais tout contenu nouveau / modifié passe par une revue AI-as-judge avant stockage
  • Les passages critiques utilisent la vérification à double source : le même sujet doit apparaître dans 2 sources de confiance indépendantes

Jour 4 — Isolation block-sparse attention (approche SDAG, 2 heures)

  • N documents récupérés ne sont pas autorisés à faire du cross-attention entre eux
  • Le masque d’attention restreint chaque document à ne voir que lui-même + la requête
  • Élimine l’attaque d’empoisonnement cross-document depuis la couche d’inférence, sans avoir besoin de détecter le contenu du corpus, isole l’attaque par mécanisme
  • Intégrer SDAG + RobustRAG / ReliabilityRAG avec des performances nettement améliorées
  • Note : cette approche nécessite de modifier le code d’inférence, convient aux nouveaux systèmes RAG ; les anciens systèmes peuvent ajouter un wrapper de masque d’attention

Jour 5 — Vérification de cohérence hop-wise de GraphRAG (2 heures)

  • GraphRAG décompose la requête multi-hop en sous-requêtes ordonnées ; vérification de cohérence après chaque hop
  • Incohérence induite par empoisonnement → déclencher la réparation du sous-graphe (élaguer les entités + relations compromises)
  • Les entités critiques utilisent la vérification à double source : chaque entité doit avoir le support de 2 sources indépendantes
  • La construction du graphe passe par human-in-the-loop : nouvelle entité / relation requiert une revue manuelle

Jour 6 — Hashing de contenu multi-modal (2 heures)

  • Les passages image / PDF / audio dans le corpus sont hashés + scannés par OCR visuel pour les payloads d’attaque avant stockage
  • Les motifs d’attaque comme PhantomText sont pré-détectés (visible-only / strip-hidden)
  • Les outils d’extraction multi-modale (OCR / pdftotext) utilisent une safe-config : mode visible-only / strip-hidden
  • Les passages multi-modaux passent par une détection adversarial-robust : utiliser un modèle dédié pour scanner les payloads d’attaque

Jour 7 — Scoring de retriever + LLM-as-judge + provenance de supply chain de corpus (3 heures)

  • Le retriever note le top-K retrieval ; LLM-as-judge re-revue le top-K pour les motifs d’attaque
  • Le mécanisme de feedback passe par la détection d’anomalies : même user agent avec feedback massif en peu de temps → rate limit
  • La logique de réentraînement doit avoir un « sanity check bidirectionnel » : l’ajustement d’embedding piloté par le feedback ne peut pas changer significativement la distribution de retrieval top-K, sinon annuler
  • Les outils d’ingestion de corpus (loader / connector / package) passent par la vérification de provenance de supply chain (signature + identité de l’éditeur + SBOM) ; détection de typosquatting
  • Les paquets critiques utilisent une version pinnée + vérification de signature ; lock file imposé

Réflexions finales

L’empoisonnement de corpus RAG est la « plongée profonde de sixième dimension » de la série de Sécurité LLM de piick.cc. La Quadrilogie de Sécurité LLM + Mémoire + Corpus couvre toutes les couches « transitoires » + « persistantes » de la chaîne d’appels du LLM. Le corpus est source de fait partagée au niveau entreprise — une injection, affecte toutes les requêtes futures, tous les utilisateurs ; le ROI de l’empoisonnement de corpus est extrême : petite entrée, grand impact.

Si votre système RAG est déjà connecté à un corpus, commencez par le Jour 1 — Whitelist de source de corpus + signature numérique, passez 30 minutes à ajouter whitelist + signature HMAC au corpus ; cela bloque à lui seul 80% des attaques d’injection directe (classe PoisonedRAG / Phantom). Suivez ensuite le plan de 7 jours.

La sécurité à l’ère du corpus RAG ne peut être résolue par une seule défense — provenance + signature + détection de drift + block-sparse attention + cohérence GraphRAG + hashing multi-modal + retriever-as-judge + vérification de supply chain huit couches de fallback indépendantes. Les 8 foot-guns + 5 incidents réels + plan de 7 jours de cet article sont le filet de sécurité le plus stable disponible actuellement ; les vrais standards de couche de protocole (spécification de provenance de corpus RAG / manifeste de retrieval signé) peuvent devoir attendre la prochaine génération de protocoles RAG.

La prochaine phase de la série de Sécurité LLM de piick.cc entrera dans d’autres plongées profondes verticales : [attaques cross-server de fédération MCP] / [exfiltration de sortie d’Agent via fédération MCP] / [automatisation DOM d’Agent] / [manipulation visuelle d’Agent], etc. Si vous avez une direction spécifique que vous voulez voir, dites-le-moi.

Lecture connexe

Vous déboguez des jetons, URLs, regex et payloads encodés côté corpus RAG ? Utilisez l’ensemble d’outils Piick :

  • /tools/jwt-decoder/ — lisez localement les jetons de capability JWT dans l’ingestion du corpus, confirmez que les portées n’ont pas été élargies (fait écho à la provenance du Jour 1)
  • /tools/url-encoder-decoder/ — vérifiez localement si l’URL source du corpus est contournée par double encodage ; dépannez le Foot-Gun 2 (pollution indirecte)
  • /tools/regex-tester/ — testez localement la regex de whitelist de provenance ; dépannez le Foot-Gun 3 (squatting avec homoglyphes)
  • /tools/text-encoder/ — détection Base64 / hex de payloads d’attaque encodés dans les passages multi-modaux ; fait écho au Foot-Gun 6

Tous les outils tournent 100% en local ; aucun fichier n’est téléversé sur un serveur, gardant votre journal d’audit propre.