RAG Security & Privacy : formaliser la menace et cartographier la surface d’attaque

Publié le 25 September 2025

Pourquoi ce papier vaut votre café ☕

Le RAG — Retrieval‑Augmented Generation — est devenu l’astuce préférée des équipes IA : au lieu de demander à un modèle de tout savoir, on lui offre une bibliothèque externe où aller piocher avant de répondre. Moins d’hallucinations, plus d’« ancrage » dans des faits. Sauf que… ouvrir une trappe vers une bibliothèque privée, c’est aussi ouvrir des portes. Et, comme tout admin le sait, chaque porte est une menace potentielle.

Le papier “RAG Security and Privacy: Formalizing the Threat Model and Attack Surface” propose – tenez‑vous bien – le premier cadre formel pour décrire les menaces et la surface d’attaque propres au RAG. Les auteurs ne se contentent pas d’aligner des cas d’école : ils structurent les attaquants, définissent des attaques majeures (inférence d’appartenance au niveau document, fuites de contenu, empoisonnement) et esquissent des principes de défense. Dit autrement : ils posent le plan du château avant d’installer les douves.

« Nous proposons […] le premier modèle de menace formel pour les systèmes RAG. »

Le résumé sans jargon (promis)

Imaginez votre LLM comme un chef cuisinier. Le RAG lui permet d’aller au marché (la base documentaire) avant de préparer le plat (la réponse). Ce papier explique qui peut saboter le marché, comment, et comment éviter d’empoisonner les clients.

D’abord, les auteurs fixent un modèle de système RAG : une base de connaissances indexée (souvent en base de vecteurs), un retriever qui sélectionne des passages, et un generator (le LLM) qui compose la réponse avec ces passages. Rien de surprenant, mais essentiel pour raisonner proprement sur la sécurité.

Ensuite, ils classent les adversaires selon deux axes orthogonaux : l’accès au modèle (du pur boîte noire jusqu’au boîte blanche) et la connaissance préalable (du naïf à l’informé qui connaît une partie des données indexées ou d’entraînement). Dit autrement : peut‑il regarder la cuisine ? et connaît‑il déjà vos recettes ?

« Nous caractérisons les adversaires selon deux dimensions : (1) l’accès au modèle et (2) la connaissance de l’attaquant. »

Sur cette base, le papier formalise trois familles d’attaques :

DL‑MIA — Document‑Level Membership Inference : deviner si un document précis fait partie de votre index. C’est la version « liste d’invités » : l’attaquant n’a pas besoin de lire la fiche, il lui suffit de savoir si elle est là. Les auteurs en donnent une définition cryptographique (jeu challenger/adversaire) et expliquent comment la confidentialité différentielle appliquée au retriever peut casser ce pouvoir d’inférence.

« L’attaque vise à déterminer si un document spécifique appartient à la base de connaissances du système. »

Fuite de contenu récupéré dans la sortie : pire que deviner la présence, reconstruire du texte sensible parce que le générateur recopie (verbatim ou quasi) ce qu’il a sous le nez. Le papier formalise la fuite (avec un seuil de similarité) et décrit des stratégies d’attaque ancre+commande : un prompt qui attire le retriever vers la bonne étagère, puis une consigne qui pousse le LLM à recracher.

« Le générateur peut émettre des segments verbatim des documents récupérés, exposant des informations sensibles. »

Empoisonnement de la base : injecter quelques documents piégés qui monteront dans les résultats pour certains déclencheurs (requêtes ou tokens), afin de biaiser la réponse ou d’y forcer un contenu (marque, phrase, intox…). Là encore, le papier donne des définitions formelles (dont une variante trigger‑based).

« L’adversaire injecte un petit nombre de documents conçus pour être récupérés face à des requêtes déclencheurs. »

Au passage, les auteurs rappellent que l’article a été accepté au 5ᵉ atelier ICDM (20 septembre 2025), ce qui cadre son ambition : poser des bases formelles plus que battre des records de benchmarks.

Méthodologie : quand la sécu parle le langage des maths

La force du papier, c’est d’écrire la sécu du RAG en équations lisibles. On y trouve :

Un modèle de pipeline (requête → embeddings → top‑k documents → génération), avec les objets notés explicitement. Ça évite les glissements de terrain : on sait exactement où peuvent se produire fuite ou empoisonnement.
Une taxonomie d’adversaires articulée autour de l’accès et de la connaissance. Les figures (schémas) situent quatre profils : Observateur ignorant, Observateur informé, Insider ignorant, Insider informé. C’est précieux pour raisonner par cas (« Que se passe‑t‑il si mon attaquant est API‑only mais connaît 20 % de mon corpus ? »).
Des définitions de sécurité façon crypto : jeux, avantage de l’adversaire, seuils de similarité. Le lecteur peut, au besoin, brancher ses hypothèses et dériver des garanties (ou l’absence de garanties).

Côté défense, un message clé se détache : déplacer la confidentialité au niveau du retriever. En rendant le scoring différentiellement privé (bruit de Laplace/Gauss sur les scores avant le top‑k), on force deux index voisins (qui diffèrent d’un document) à produire des ensembles récupérés quasi‑indiscernables, donc on casse le DL‑MIA par post‑traitement (le générateur ne peut pas amplifier la fuite). C’est élégant, parce que local au composant critique et compatible avec n’importe quel LLM.

Sur la fuite verbatim, la ligne est plus pragmatique : les prompts « ne pas copier » aident peu ; il faut combiner désamorçage du biais de position, entraînement adversarial, et hygiène de prompting contre les injections indirectes. Là aussi, l’idée est de désamorcer au plus près de la source (retrieval + post‑retrieval) plutôt que d’espérer un miracle du générateur.

Enfin, pour l’empoisonnement, le papier cadre la menace sans s’engluer dans des recettes spécifiques, et renvoie au besoin à des stratégies de filtrage de corpus et de détection d’anomalies dans l’espace d’embeddings (une intuition que la littérature récente confirme).

Ce que ça change pour nous (IA, dev, data… et jeux 🎮)

Pour les équipes IA/ML : arrêtons de traiter le RAG comme une simple feature produit. C’est une architecture de sécurité à part entière. Avant de choisir un modèle ou un vecteur, posez les deux questions du papier : Qui peut toucher quoi ? Qui sait quoi ? Votre threat model doit préciser l’accès au système (API publique, serverless, on‑prem) et le niveau de connaissance plausible (recouvrements de jeux de données, fuites internes, logs).

Pour les devs : réalisez que les risques n’habitent pas que dans le LLM. Ils vivent dans les pipelines d’ingestion, les index, les filtres, les re‑rankers. Un pull request qui ajoute « des documents communautaires » peut, sans garde‑fou, devenir une porte d’empoisonnement. Mettez des tests de régression sécu sur vos retrievers (détection d’anomalies d’embeddings, density checks, quotas de diversité). La littérature 2024‑2025 montre que le RAG est attaquable dès l’ingestion – même avec des fichiers « texte tout bête ».

Pour les data scientists : considérez la confidentialité différentielle au niveau retrieval comme un hyperparamètre de sécurité. Jouer sur ε (epsilon) c’est accepter un trade‑off précision ↔ confidentialité : un peu de bruit peut suffire à tuer l’avantage attaquant sans dégrader la qualité perçue. Et si vous evaluez la fuite, ne vous contentez pas du exact‑match : mesurez la similitude (n‑grams, sémantique) et l’extractabilité.

Pour vos créations de jeux : imaginez un RPG où les PNJ s’appuient sur un RAG pour puiser dans le lore (wiki, patch notes, quêtes de joueurs). Un adversaire pourrait injecter des pages qui forcent des pistes de quête bidon ou glisser une réplique toxique qui se propage parce que le PNJ « récite » ce qu’il a vu. La défense ? Sandboxer l’ingestion (validation, signature, quarantaines), désamorcer le biais de position (ne pas toujours privilégier le top‑1 du retriever), et tester des requêtes ancre+commande pour vérifier que vos PNJ ne copient pas mot‑pour‑mot le lore privé.

Côté conformité (santé/finances) : la définition document‑level est une bénédiction. Les DPO et juristes peuvent mapper une exigence claire : l’inclusion ou l’exclusion d’un dossier ne doit pas être détectable. C’est beaucoup plus actionnable que « évitez les hallucinations ». Et ça se teste : holdout d’un document sensible, exécution d’un jeu de requêtes, test d’indistinguabilité statistique.

Mise en perspective avec l’état de l’art

Le papier s’inscrit dans une vague de travaux qui, depuis 2024, clochent l’alarme : fuite de bases RAG, prompt‑injections indirectes, empoisonnement, etc. Par exemple, Zeng et al. (ACL 2024) montrent empiriquement que le RAG peut leaker sa base privée tout en réduisant la fuite des données d’entraînement du LLM — un double tranchant.

Côté empoisonnement, on voit émerger des benchmarks et taxonomies d’attaques (RAG Security Bench : ciblage, déni de service, déclencheurs). Ces cadres expérimentaux complètent bien l’approche formelle des auteurs.

Sur la défense structurée, des propositions « chiffrage d’index + embeddings » ou garanties provables de confidentialité apparaissent, utiles pour les environnements très régulés — à articuler avec le retriever DP prôné ici.

Enfin, côté opérationnel, des analyses de surface d’attaque RAG convergent vers les mêmes zones rouges : ingestion, index, retrieval, génération (avec injection de prompts et position bias). Le mérite du papier : fixer des définitions, pour que la sécurité RAG sorte du flou et se teste.

Quelques images mentales pour retenir l’essentiel

Le portier et la liste d’invités : le DL‑MIA, c’est demander au portier s’il reconnaît un nom. Le retriever DP, c’est un portier qui répond toujours avec un léger hasard, rendant la réponse exploitable… inexploitable.
Le perroquet studieux : si vous lui donnez des fiches bien classées et l’ordre « répète mot pour mot », ne soyez pas surpris qu’il récite. Entraînez‑le à paraphraser et détectez les prompts trop pressants.
Le marché aux étals : un empoisonneur n’a pas besoin de voler la caisse ; il lui suffit de poser un produit frelaté là où l’acheteur regarde en premier. Votre job : inspecter les arrivages et diversifier les sources.

Citations choisies

« Nous proposons […] le premier modèle de menace formel pour les systèmes RAG. »

« Nous caractérisons les adversaires selon deux dimensions : (1) l’accès au modèle et (2) la connaissance de l’attaquant. »

« Le générateur peut émettre des segments verbatim des documents récupérés, exposant des informations sensibles. »

Conclusion (avec clin d’œil)

Ce papier n’est pas un gadget. C’est un dialecte commun entre research, engineering et compliance pour parler sécurité RAG sans se perdre en synonymes. En formalisant les menaces et en pointant où agir (le retriever, d’abord), il nous donne l’outillage pour prioriser les défenses et mesurer les progrès.

Moralité : si votre LLM est un chef étoilé, votre RAG est son marché. Sécurisez les étals, pas seulement la cuisine. Et si quelqu’un vous propose des pommes de la connaissance à prix cassé… vérifiez qu’elles ne sentent pas la Gaussienne.

Références principales : Papier original et pages associées sur arXiv (taxonomie, définitions, acceptation à l’atelier ICDM) ; études connexes sur fuites et empoisonnement RAG.