Les attaques RAG ne visent pas seulement le corpus — le pipeline de retrieval lui-même (retrieval / rerank / embedding) est une nouvelle surface d’attaque. L’article précédent Empoisonnement de base de connaissances RAG en pratique s’attaquait à la « couche de connaissance » (pollution du corpus). Cet article s’attaque à la « couche de retrieval » — même avec un corpus propre, un pipeline de retrieval empoisonné continue à produire des réponses erronées. Cet article est la « plongée profonde de septième dimension » de la série de Sécurité LLM de piick.cc, parfaitement complémentaire à l’empoisonnement de corpus du batch-33, couvrant ensemble la surface d’attaque RAG complète.

CAREATTACK (arxiv 2606.18310, 2026-06-16) a validé empiriquement l’« édition de retriever centrée sur le modèle » : sans toucher au corpus, éditer directement le modèle du retriever peut altérer les résultats de retrieval. arxiv 2605.28017 v2 a validé empiriquement que l’étape de rerank élève le succès de l’attaque de +16.5% (rerank les amplifie). arxiv 2602.08668 v3 a validé Hybrid RAG RPR=0.95 (334/350 benign queries déclenchent une fuite cross-tenant). Les attaques en temps de retrieval sont plus difficiles à détecter que les attaques au corpus — le scan du corpus est inefficace, vous avez besoin d’une détection au niveau du comportement / modèle.

Vue d’ensemble de 30 secondes

  • Le pipeline de retrieval RAG est la nouvelle surface d’attaque — 5 articles de recherche indépendants (ACL 2026 EACL TPARAG + arxiv CAREATTACK + arxiv GEO survival v2 + arxiv FlippedRAG v7 + arxiv RPR v3) explosent en 2026 H2, concentrés Mar-Août
  • 8 variantes d’attaque en temps de retrieval (progressant par pipeline de retrieval : query → embedding → retriever → reranker → top-K) : manipulation de reranking / édition de retriever centrée sur le modèle / attaque précise au niveau des tokens / perturbation adversariale imperceptible / manipulation d’opinion black-box / pivot Hybrid RAG / backdoor du reranker / backdoor de l’embedding
  • 5 incidents/articles réels de 2026 : CAREATTACK édition de retriever centrée sur le modèle (sans injection dans le corpus), TPARAG ACL 2026 EACL token-level white-box + black-box, attaque GEO RAG réel de 3 étapes reranker lift +16.5%, FlippedRAG v7 manipulation d’opinion black-box, Hybrid RAG RPR=0.95 fuite cross-tenant
  • Plan de défense de 7 jours (chacun ≤ 30 minutes pour démarrer) : vérification de signature du retriever / vérification d’intégrité du modèle / comparaison de double voie sparse+dense / détection de perturbation imperceptible / détection d’anomalie d’opinion / isolation de tenant Hybrid RAG / provenance d’entraînement du reranker / vérification de supply chain de l’embedding
  • Utilisez l’ensemble d’outils Piick pour déboguer les jetons, URLs, regex et payloads encodés sur le pipeline de retrieval RAG — tous les outils tournent 100% en local et ne sont jamais téléversés, gardant votre journal d’audit propre

Pourquoi le pipeline de retrieval RAG est une nouvelle surface d’attaque

Pour comprendre pourquoi les 8 attaques en temps de retrieval fonctionnent, revenons au pipeline de retrieval RAG :

Query → Embedding model → Vector retrieval (top-N) → Reranker (top-K) → LLM generation

La supposition traditionnelle : corpus propre → retrieval propre → sortie propre. batch-33 (empoisonnement de corpus RAG) s’attaquait au corpus ; cet article s’attaque au pipeline de retrieval lui-même, même avec un corpus propre, les attaques suivantes tiennent :

  • modèle retriever édité (CAREATTACK) → la sortie change, le corpus non
  • modèle reranker backdooré → le doc malicieux monte en rang, le corpus non
  • modèle embedding backdooré → les requêtes contenant trigger sont toutes acheminées vers des docs malicieux, le corpus non
  • expansion de graphe Hybrid RAG fuite cross-tenant → la requête bénigne déclenche cross-tenant, le corpus non
  • perturbation imperceptible → micro-perturbation tire le doc de hors top-K à dans top-K, le corpus paraît « intact »

Le cœur des attaques en temps de retrieval : le scan du corpus / la vérification de provenance échouent ; il faut détecter au niveau du comportement / modèle du retrieval.

8 variantes d’attaque en temps de retrieval (Progression par pipeline de retrieval : query → embedding → retriever → reranker → top-K)

Attaque 1 : Manipulation du reranking du retriever (GEO Survival +16.5%)

Symptôme : l’étape de rerank amplifie le succès de l’attaque ; l’attaquant conçoit des éditions adversariales pour faire monter les docs malicieux en rang après le rerank ; reranker lift +16.5% en moyenne.

Pourquoi ça fonctionne : le Reranker est un composant standard des pipelines RAG déployés, utilisant généralement des rankers listwise basés sur des LLM. L’attaquant conçoit des éditions adversariales optimisées pour l’étape de rerank (pas l’étape de retrieval). arxiv 2605.28017 v2 a validé empiriquement : l’étape de retrieval filtre ~20% des documents d’attaque, mais l’étape de rerank élève le succès de l’attaque de +16.5% — rerank devient un amplificateur d’attaque.

Reproduction minimale (motif GEO Survival) :

Étape 1 : l’attaquant écrit un doc malicieux, phrase de trigger de requête + réponse adverse Étape 2 : le doc est embarqué dans le corpus Étape 3 : la requête utilisateur entre → retriever top-20 atteint le doc malicieux (rang 18/20, à peine) Étape 4 : le reranker (basé sur LLM) re-classe → le rang du doc malicieux monte au top-3 Étape 5 : la génération LLM voit que le top-3 inclut le doc malicieux → émet la réponse adverse Étape 6 : l’étape de retrieval voit 20% des docs d’attaque filtrés, mais l’étape de rerank amplifie l’attaque

Correctif :

  • Comparaison de double voie sparse / dense (voir Jour 3). Sparse retrieval (BM25) + dense retrieval en double voie en parallèle ; différence de résultats > seuil → alerte ; l’attaquant ne peut attaquer qu’une voie
  • Le côté entrée du reranker ajoute une seconde revue LLM-as-judge
  • La sortie du reranker doit porter des étiquettes de provenance : chaque doc porte une signature de source, post-rerank retient la signature

Attaque 2 : Édition du retriever centrée sur le modèle (CAREATTACK)

Symptôme : sans toucher au corpus, éditer directement le modèle du retriever ; la réparation d’ancre préservatrice d’attaque évite la modification simultanée d’objectifs conflictuels ; plus difficile à détecter qu’une injection dans le corpus (scan du corpus inefficace).

Pourquoi ça fonctionne : les retrievers des systèmes RAG sont presque tous des modèles open-source (Contriever / DPR / BGE / ColBERT, etc.) ; 4 463 projets RAG sur GitHub réutilisent massivement le même modèle. L’attaquant édite les poids du modèle retriever réutilisé → ultérieurement tous les retrievers déployés par les utilisateurs sont empoisonnés. arxiv 2606.18310 a validé empiriquement : sans injection dans le corpus, ajuster directement les poids du retriever élève systématiquement le rang du doc malicieux.

Reproduction minimale (motif CAREATTACK) :

Étape 1 : l’attaquant attaque un retriever open-source réutilisé (par ex. BGE-large) Étape 2 : édition du retriever consciente du conflit — modifie les paramètres du retriever pour qu’une requête cible atteigne un doc cible Étape 3 : réparation d’ancre préservatrice d’attaque — lors de la modification simultanée de plusieurs cibles, éviter les conflits mutuels Étape 4 : pousse le retriever modifié vers HuggingFace / GitHub (typosquatting du même nom original) Étape 5 : 4 463 projets RAG auto-tirent la version modifiée pendant le Docker build Étape 6 : tous les systèmes RAG sont pollués directionnellement, le corpus complètement intact

Correctif :

  • Vérification d’intégrité du retriever centrée sur le modèle (voir Jour 2). Numéro de version du modèle retriever + signature hash des poids (en s’inspirant de l’approche HMAC du batch-32) ; vérifier l’intégrité des poids au démarrage du retriever ; dérive des poids → alerte
  • Les retrievers critiques n’acceptent pas les noms de modèle en typosquatting ; ne tirer que depuis le mirror officiel
  • Le côté sortie du retriever ajoute une seconde revue LLM-as-judge, vérifiant que le contenu du retrieval est réellement lié à la requête

Attaque 3 : Attaque précise au niveau des tokens (TPARAG)

Symptôme : un LLM attaquant white-box génère + une recherche greedy au niveau des tokens optimise le passage malicieux ; contrôle précisément la position du contenu malicieux dans le passage.

Pourquoi ça fonctionne : TPARAG (ACL 2026 EACL, 2026-03-24) pousse la précision de l’attaque au niveau des tokens — l’attaquant utilise un LLM attaquant white-box pour générer le passage malicieux initial, puis utilise une recherche greedy pour optimiser au niveau des tokens, contrôlant précisément quels tokens déclenchent les embeddings dans la région cible. Couverture double white-box + black-box.

Reproduction minimale (motif TPARAG) :

Étape 1 : l’attaquant utilise un LLM white-box pour générer le passage malicieux initial (trigger de requête + réponse adverse) Étape 2 : recherche greedy au niveau des tokens — remplace un token à la fois, observe le changement du taux de succès de retrieval Étape 3 : optimisation itérative jusqu’à ce que l’effet de l’attaque au niveau des tokens soit le plus fort Étape 4 : le passage optimisé est embarqué dans le corpus Étape 5 : les requêtes ultérieures atteignent, retrieval extrêmement précis

Correctif :

  • Détection de perturbation imperceptible (voir Jour 4). L’entrée de retrieval ajoute un modèle de détection adversariale ; déclenchement de micro-perturbation → rejeter ; LLM-as-judge seconde revue du contenu top-K
  • Les passages critiques du corpus passent par la détection de distribution d’embedding (l’embedding de chaque passage doit être dans la distribution globale du corpus, atterrissage anormal → alerte)
  • Whitelist de source du corpus (selon batch-33 Jour 1)

Attaque 4 : Perturbation adversariale imperceptible (ReGENT)

Symptôme : une micro-perturbation tire le doc cible de hors top-K à dans top-K ; les yeux humains ne peuvent pas voir la différence, le rang du retriever change radicalement.

Pourquoi ça fonctionne : ReGENT (ACL 2025) propose le framework d’attaque « retrieve-to-generate » ; modèle retriever substitut + récompenses de pertinence-génération-naturalité guident la perturbation ; l’objectif est de faire qu’un doc cible originellement hors top-K soit tiré dans le top-K. Les yeux humains ne peuvent absolument pas remarquer que le doc a été modifié (remplacement de micro tokens), mais le rang du retriever change radicalement.

Reproduction minimale (motif ReGENT) :

Étape 1 : l’attaquant obtient le doc cible (originellement classé hors top-K, par ex. top-30 / 20) Étape 2 : utilise un retriever substitut + RL pour entraîner une micro-perturbation (peut-être juste 1-2 remplacements de tokens) Étape 3 : le rang du doc post-perturbation saute au top-3 Étape 4 : la génération LLM voit le top-3 → sortie affectée Étape 5 : l’utilisateur voit un texte de doc normal (original), une sortie LLM normale (basée sur le top-3 post-rerank)

Correctif :

  • Détection de perturbation imperceptible (voir Jour 4). Détection de robustesse d’embedding : faire des micro-perturbations sur les docs du corpus → observer la stabilité du rang de retrieval ; fluctuation significative du rang → alerte
  • Le corpus critique passe par un « audit de perturbation » : périodiquement faire des perturbations contrôlées sur de petits échantillons de docs, vérifier la stabilité de la distribution de sortie du retriever
  • Signature d’entrée du retriever : query + chaîne hash du contenu du corpus + hash de sortie du retriever, audit post-événement

Attaque 5 : Manipulation d’opinion black-box (FlippedRAG)

Symptôme : manipulation d’opinion contre des sujets controversés ; entraîne un trigger transférable via un modèle substitut ; pas besoin d’accès interne au retriever.

Pourquoi ça fonctionne : FlippedRAG (arxiv 2501.02968 v7, 2026-08) a validé empiriquement — l’attaquant n’a pas besoin d’accès interne au retriever (black-box), entraîne seulement un trigger transférable via un modèle substitut, puis l’injecte dans le doc cible ; le trigger est transférable entre différents retrievers. Manipulation d’opinion contre des sujets controversés (politique / commercial / santé).

Reproduction minimale (motif FlippedRAG) :

Étape 1 : l’attaquant utilise un retriever substitut pour entraîner un trigger transférable (phrase spécifique embarquée dans la région d’opinion cible) Étape 2 : l’attaquant injecte le trigger dans plusieurs docs existants Étape 3 : la requête utilisateur touche un sujet controversé → le retriever atteint les docs portant le trigger Étape 4 : la sortie LLM influencée par le trigger → opinion biaisée vers la position de l’attaquant Étape 5 : retriever black-box, ne peut pas détecter directement le motif du trigger

Correctif :

  • Détection d’anomalie de manipulation d’opinion (voir Jour 5). Résultats de retrieval classés par sujet de requête ; même sujet avec concentration anormale de résultats de haut rang → alerte
  • Grande déviation entre feedback utilisateur et rang → re-revue (résultats de retrieval vs sortie LLM vs attente utilisateur)
  • Les sujets controversés critiques (query whitelist) passent par un retrieval multi-source : doivent avoir 3+ sources pour être fiables

Attaque 6 : Pivot de retrieval Hybrid RAG (RPR=0.95)

Symptôme : retrieval hybride vector + graph ; contourne le préfiltre de métadonnées via l’extension de graphe ; RPR=0.95 (334/350 benign queries déclenchent cross-tenant).

Pourquoi ça fonctionne : Hybrid RAG utilise le retrieval fédéré vector + knowledge graph. Le préfiltre de métadonnées du Vector DB pourrait normalement défendre contre le cross-tenant (vector-only RPR=0) ; mais l’étape d’extension de graphe relie des entités de plusieurs tenants dans le même sous-graphe, contournant le préfiltre. arxiv 2602.08668 v3 a validé empiriquement : 1 000 docs / 2 785 nœuds de graphe / 15 514 arêtes corpus multi-tenant, 334 / 350 benign queries déclenchent une fuite cross-tenant (95,4%).

Reproduction minimale (motif RPR) :

Étape 1 : corpus multi-tenant + knowledge graph (docs + entités de chaque tenant) Étape 2 : attaquant dans le tenant A, requête « project alpha security » Étape 3 : le retriever atteint les chunks du tenant A → l’extension de graphe tire les entités liées du tenant B Étape 4 : le sous-graphe contient des entités du tenant B → le LLM voit les données du tenant B Étape 5 : toute la requête est une benign query de l’attaquant, sans trace d’attaque

Correctif :

  • Isolation de tenant Hybrid RAG + limite de chunk (voir Jour 6). Isolation de tenant à deux couches Hybrid RAG (vector + graph) ; chunk et entité de graphe forcés au même tenant ; arête de graphe cross-tenant rejetée
  • Le parcours de graphe ajoute une vérification forcée de préfixe de tenant
  • Les données multi-tenant critiques passent par une vérification à double source : la même entité doit apparaître dans 2 tenants pour alerter

Attaque 7 : Backdoor du modèle reranker

Symptôme : données d’entraînement du reranker LLM empoisonnées ; trigger planté à l’intérieur du modèle reranker ; ultérieurement les docs malicieux systématiquement élevés en rang.

Pourquoi ça fonctionne : reranker LLM (Qwen3 / GPT-4 / Claude, etc. utilisés comme ranker listwise), s’il passe par un fine-tuning, les données d’entraînement peuvent être empoisonnées. Trigger du backdoor : phrase de trigger spécifique fait que le reranker élève systématiquement le rang du doc malicieux. Même si le rang du retriever est 18, le reranker l’élève au top-3.

Reproduction minimale :

Étape 1 : l’attaquant obtient l’accès aux données d’entraînement du reranker (menace interne / pollution du dataset) Étape 2 : implante une phrase de trigger + un motif de doc malicieux dans les données d’entraînement Étape 3 : après l’entraînement du reranker, la phrase de trigger élève systématiquement le doc malicieux Étape 4 : ultérieurement toutes les sorties du retriever passant par le reranker, le doc malicieux monte Étape 5 : corpus propre + retriever propre → encore pollué par le backdoor du reranker

Correctif :

  • Provenance de données d’entraînement du reranker (voir Jour 7). Le modèle reranker passe par une vérification de provenance de supply chain (comme le corpus du batch-33) ; version pinnée + signature + SBOM
  • Le reranker critique n’accepte pas les versions fine-tuned de tiers ; seulement depuis le modèle de base officiel
  • Côté sortie du reranker seconde revue LLM-as-judge : vérifie que le top-K post-rerank dévie significativement du top-N pré-rerank → alerte

Attaque 8 : Backdoor d’embedding multi-vector

Symptôme : données d’entraînement du modèle d’embedding empoisonnées ; phrase de trigger spécifique mappée sur la région cible ; ultérieurement toutes les requêtes contenant le trigger sont acheminées vers le doc malicieux.

Pourquoi ça fonctionne : modèle d’embedding (Contriever / BGE / OpenAI text-embedding-3, etc.), s’il passe par un fine-tuning, les données d’entraînement peuvent être empoisonnées. Trigger du backdoor : une requête contenant un trigger spécifique, son embedding tombe dans la région cible → atteint le doc malicieux.

Reproduction minimale :

Étape 1 : l’attaquant obtient l’accès aux données d’entraînement du modèle d’embedding Étape 2 : implante une phrase de trigger + association de doc cible dans les données d’entraînement Étape 3 : après l’entraînement du modèle d’embedding, l’embedding de la phrase de trigger tombe dans la région cible Étape 4 : ultérieurement toute requête contenant la phrase de trigger → retrieval atteint le doc cible (malicieux) Étape 5 : même si corpus / retriever / reranker tous propres → backdoor d’embedding pollue encore

Correctif :

  • Vérification de supply chain du modèle d’embedding (voir Jour 7). Le modèle d’embedding passe par une vérification de provenance de supply chain ; version pinnée + signature + SBOM
  • Le modèle d’embedding critique n’accepte pas le fine-tuning de tiers ; seulement depuis le modèle de base officiel
  • Le côté sortie de l’embedding ajoute une détection d’outliers : l’atterrissage de l’embedding de la requête doit être dans la distribution globale du corpus, atterrissage anormal → alerte

5 incidents / articles réels de 2026

Incident 1 : CAREATTACK édition de retriever centrée sur le modèle (arxiv 2606.18310, 2026-06-16)

Résumé de l’article : édition de retriever centrée sur le modèle — pas besoin d’injection dans le corpus, éditer directement le modèle du retriever ; édition de retriever consciente du conflit + réparation d’ancre préservatrice d’attaque évite la modification simultanée d’objectifs conflictuels ; 4 463 projets RAG sur GitHub affectés (réutilisation du retriever).

Conclusion centrale : le seuil d’attaque au retriever est plus bas que l’attaque au corpus (pas besoin de données de connaissance, pas besoin d’édition de contenu), la supply chain du modèle retriever devient une nouvelle surface d’attaque. Correspond directement au Foot-Gun 2.

Incident 2 : TPARAG (ACL 2026 EACL, 2026-03-24)

Résumé de l’article : Attaque précise au niveau des tokens contre RAG ; LLM attaquant white-box génère un passage malicieux + optimisation par recherche greedy au niveau des tokens ; couverture double white-box + black-box ; 14 pages, ACL 2026 EACL findings.

Conclusion centrale : pousse la précision de l’attaque RAG au niveau des tokens, chemin d’optimisation indépendant du scan du corpus. Correspond directement au Foot-Gun 3.

Incident 3 : Survie de l’attaque GEO dans RAG réel de 3 étapes (arxiv 2605.28017 v2, 2026-08)

Résumé de l’article : pipeline complet retriever → reranker → generator ; le reranker élève le succès de l’attaque de +16.5% ; l’étape de retrieval filtre 20% des documents d’attaque, mais l’étape de rerank amplifie l’attaque.

Conclusion centrale : le reranker n’est pas seulement optimisation de rang, mais aussi point d’amplification d’attaque ; le déploiement doit auditer l’écart pré-post rerank. Correspond directement au Foot-Gun 1.

Incident 4 : FlippedRAG (arxiv 2501.02968 v7, 2026-08)

Résumé de l’article : manipulation d’opinion black-box ; contre des sujets controversés ; modèle substitut entraîne un trigger transférable ; pas besoin d’accès interne au retriever ; continuellement mis à jour à v7 reste effectif.

Conclusion centrale : RAG black-box peut aussi être attaqué — l’attaque basée sur le transfert n’a pas besoin d’interne du retriever ; la manipulation d’opinion est particulièrement dangereuse. Correspond directement au Foot-Gun 5.

Incident 5 : Retrieval Pivot Attacks Hybrid RAG (arxiv 2602.08668 v3, 2026-03)

Résumé de l’article : Hybrid RAG vector + graph ; RPR=0.95 fuite cross-tenant ; 334 / 350 benign queries déclenchent ; 1 000 docs / 2 785 nœuds de graphe / 15 514 arêtes corpus multi-tenant ; l’extension de graphe contourne le préfiltre de métadonnées.

Conclusion centrale : l’extension de graphe de Hybrid RAG est un contournement du préfiltre de métadonnées ; multi-tenant doit avoir une isolation de tenant au niveau du graphe. Correspond directement au Foot-Gun 6.

Plan de défense de 7 jours

Jour 1 — Vérification de signature du retriever + provenance de requête (15 minutes pour démarrer)

  • Chaque appel du retriever enregistre hash de requête + hash d’embedding + hash de résultat top-K
  • Dérive anormale du résultat de retrieval → alerte
  • Whitelist de requêtes : requêtes suspectes → rate limit (référence provenance de requête du batch-32)
  • En s’inspirant de l’approche HMAC du batch-32 pour signer chaque numéro de version de sortie du retriever

Jour 2 — Vérification d’intégrité du retriever centrée sur le modèle (30 minutes)

  • Numéro de version du modèle retriever + signature hash des poids (en s’inspirant du HMAC du batch-32)
  • Vérifier l’intégrité des poids au démarrage du retriever ; dérive des poids → alerte
  • Les retrievers critiques n’acceptent pas les noms de modèle en typosquatting ; ne tirer que depuis le mirror officiel
  • Le côté sortie du retriever ajoute une seconde revue LLM-as-judge

Jour 3 — Comparaison de double voie sparse / dense (1 heure)

  • Sparse retrieval (BM25) + dense retrieval en double voie en parallèle
  • Différence de résultats > seuil → alerte
  • L’attaquant ne peut attaquer qu’une voie, la différence de double voie est détectée
  • Tant pré-rerank que post-rerank exécutent la comparaison de double voie

Jour 4 — Détection de perturbation imperceptible (2 heures)

  • L’entrée de retrieval ajoute un modèle de détection adversariale
  • Déclenchement de micro-perturbation → rejeter
  • LLM-as-judge seconde revue du contenu top-K
  • Détection de robustesse d’embedding : faire des micro-perturbations sur les docs du corpus → observer la stabilité du rang de retrieval

Jour 5 — Détection d’anomalie de manipulation d’opinion (2 heures)

  • Résultats de retrieval classés par sujet de requête
  • Même sujet avec concentration anormale de résultats de haut rang → alerte
  • Grande déviation entre feedback utilisateur et rang → re-revue
  • Les sujets controversés critiques (query whitelist) passent par un retrieval multi-source : doivent avoir 3+ sources pour être fiables

Jour 6 — Isolation de tenant Hybrid RAG + limite de chunk (2 heures)

  • Isolation de tenant à deux couches Hybrid RAG (vector + graph)
  • Chunk et entité de graphe forcés au même tenant ; arête de graphe cross-tenant rejetée
  • Le parcours de graphe ajoute une vérification forcée de préfixe de tenant
  • Les données multi-tenant critiques passent par une vérification à double source

Jour 7 — Vérification de supply chain du reranker / modèle d’embedding (3 heures)

  • Les modèles reranker / embedding passent par une vérification de provenance de supply chain (comme le corpus du batch-33)
  • Version pinnée + signature + SBOM
  • Les modèles critiques n’acceptent pas le fine-tuning de tiers ; seulement depuis le modèle de base officiel
  • Le côté sortie du reranker / embedding ajoute une détection d’outliers : atterrissage anormal → alerte
  • Vérification d’intégrité combinée à trois couches retriever + reranker + embedding

Réflexions finales

Les attaques RAG en temps de retrieval sont la « plongée profonde de septième dimension » de la série de Sécurité LLM de piick.cc. Parfaitement complémentaires à l’empoisonnement de corpus du batch-33 — un corpus propre ne signifie pas que RAG est sûr, le pipeline de retrieval lui-même (retriever / reranker / embedding) est une nouvelle surface d’attaque. Le scan du corpus / la vérification de provenance échouent ; vous devez détecter au niveau du comportement / modèle du retrieval.

Si votre système RAG est déjà connecté au retrieval, commencez par le Jour 1 — Vérification de signature du retriever + provenance de requête, passez 30 minutes à ajouter signature + audit de provenance de requête à votre retriever ; cela bloque à lui seul une partie de la dérive d’attaque. Suivez ensuite le plan de 7 jours.

La sécurité à l’ère du retrieval RAG ne peut être résolue par une seule défense — intégrité du retriever + intégrité du reranker + intégrité de l’embedding + double voie sparse+dense + détection de perturbation + isolation de tenant + provenance de supply chain sept 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 (attestation de retriever / signature de composants RAG) 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] / [Agentic browser DOM] / [exfiltration de sortie d’Agent via fédération MCP] / [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 sur le pipeline de retrieval RAG ? Utilisez l’ensemble d’outils Piick :

  • /tools/jwt-decoder/ — lisez localement les jetons de capability de retrieval RAG, confirmez que les portées n’ont pas été élargies (fait écho à la signature du retriever du Jour 1)
  • /tools/url-encoder-decoder/ — vérifiez localement si l’URL source du corpus de retrieval est contournée par double encodage ; dépannez le Foot-Gun 4 (perturbation imperceptible)
  • /tools/regex-tester/ — testez localement la regex de whitelist de retrieval ; dépannez le Foot-Gun 1 (manipulation de reranking)
  • /tools/text-encoder/ — détection Base64 / hex d’attaques encodés dans le payload de retrieval ; fait écho au Foot-Gun 3 (niveau des tokens)

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