Exfiltration de Données via RAG : Attaques Contextuelles

Le RAG résout le problème des hallucinations et des connaissances obsolètes des LLM en alimentant le modèle avec des documents pertinents récupérés dans une base de connaissances vectorielle. Mais cette solution crée un nouveau problème de sécurité fondamental : le modèle traite les documents récupérés avec le même niveau de confiance que ses instructions système, sans distinguer le contenu légitime du contenu potentiellement malveillant. Un document empoisonné dans le vector store peut contenir des instructions cachées qui seront exécutées par le modèle lors de la génération de la réponse, avec accès à l'ensemble du contexte incluant le system prompt, les autres documents récupérés et les données de l'utilisateur. L'article fondateur sur le RAG (Retrieval-Augmented Generation) explique l'architecture technique que nous allons attaquer. Les techniques d'AI Red Team fournissent le cadre méthodologique pour auditer ces systèmes. La compréhension des techniques avancées de prompt injection est un prérequis car l'injection indirecte via RAG est le vecteur d'attaque principal. L'architecture GraphRAG avec ses knowledge graphs introduit des surfaces d'attaque supplémentaires sur les relations entre entités. Les travaux de Greshake et al. sur l'injection indirecte et les recherches du Anthropic Red Team constituent les références académiques de ce domaine émergent.

Architecture RAG et surfaces d'attaque

Un pipeline RAG standard comprend quatre composants attaquables : le module d'ingestion qui transforme les documents en embeddings vectoriels, le vector store qui stocke les embeddings et les métadonnées, le module de retrieval qui recherche les documents pertinents par similarité cosinus, et le module de génération qui combine le contexte récupéré avec le system prompt et le message utilisateur pour produire la réponse. Chaque composant présente des vulnérabilités spécifiques : l'ingestion peut être empoisonnée par des documents malveillants, le vector store peut être manipulé pour modifier les résultats de recherche, le retrieval peut être biaisé par des requêtes adversariales, et la génération peut être détournée par les instructions cachées dans les documents récupérés.

La confiance implicite accordée au contenu récupéré est la vulnérabilité fondamentale de l'architecture RAG. Le modèle ne peut pas distinguer un document légitime ajouté par l'administrateur d'un document empoisonné injecté par un attaquant. Les deux sont traités comme du contenu factuel de référence pour la génération de la réponse. Cette absence de mécanisme de provenance et de vérification de l'intégrité des documents constitue un défaut de conception inhérent à l'architecture RAG actuelle que les contre-mesures doivent compenser par des contrôles externes à chaque couche du pipeline.

Empoisonnement du vector store

L'empoisonnement du vector store consiste à injecter des documents contenant des instructions malveillantes dans la base de connaissances indexée par le pipeline RAG. L'attaquant peut exploiter les sources d'ingestion automatisées (crawlers web, connecteurs SharePoint, synchronisation de dossiers partagés) pour introduire des documents empoisonnés qui seront indexés et récupérés lors des requêtes utilisateur. Le document empoisonné contient une instruction cachée (texte invisible, commentaire, métadonnée) ciblant un sujet spécifique pour maximiser la probabilité de récupération lorsqu'un utilisateur pose une question sur ce sujet.

La technique d'embedding collision optimise l'embedding du document empoisonné pour maximiser sa similarité cosinus avec les requêtes cibles. L'attaquant génère un document dont le contenu visible est anodin mais dont l'embedding vectoriel est proche des requêtes qu'il souhaite cibler, garantissant que le document sera récupéré par le retriever pour ces requêtes spécifiques. Cette technique nécessite la connaissance du modèle d'embedding utilisé (souvent OpenAI text-embedding-ada-002 ou Sentence-BERT) mais pas un accès direct au vector store, rendant l'attaque réalisable par un attaquant externe avec un accès limité aux sources d'ingestion.

Extraction de documents confidentiels

L'extraction de documents confidentiels exploite le LLM comme proxy pour accéder à la base de connaissances sans les contrôles d'accès appropriés. Dans la plupart des déploiements RAG, le retriever utilise un compte de service unique avec accès à l'intégralité du vector store, sans filtrage par rôle ou par niveau d'habilitation de l'utilisateur final. Un utilisateur avec des droits limités peut poser des questions ciblées pour obtenir des extraits de documents auxquels il n'aurait pas accès directement, exploitant le LLM comme intermédiaire non autorisé pour contourner les politiques d'accès aux données.

Les techniques d'extraction incluent les requêtes directes ciblées (« quelles sont les conditions du contrat avec le client X ? »), les requêtes par inférence (« résume les documents contenant des montants supérieurs à 1 million d'euros »), et l'extraction exhaustive par itération (poser des questions systématiques sur chaque sujet pour reconstituer progressivement la base de connaissances). La contre-mesure principale est la segmentation du vector store par rôle utilisateur avec des collections ou namespaces séparés et un filtrage des résultats de recherche basé sur les droits de l'utilisateur authentifié avant injection dans le contexte du modèle.

Contre-mesures architecturales

La sécurisation du pipeline d'ingestion constitue la première ligne de défense contre l'empoisonnement. Le scanning antivirus et anti-malware des documents avant indexation détecte les payloads connus. L'analyse statique du contenu identifie les instructions cachées (texte invisible, métadonnées suspectes, commentaires PDF). La validation de provenance vérifie l'origine et l'intégrité des documents via des signatures numériques. Le contrôle d'accès à la source d'ingestion limite les acteurs autorisés à ajouter des documents dans la base de connaissances pour réduire la surface d'attaque à l'empoisonnement.

La segmentation du vector store par tenant, rôle ou niveau de classification est la contre-mesure la plus efficace contre l'extraction non autorisée de documents. Chaque utilisateur ou groupe d'utilisateurs ne peut requêter que les collections auxquelles ses droits d'accès lui donnent accès. Le filtrage des résultats de recherche avant injection dans le contexte du modèle ajoute une couche de vérification supplémentaire. Le monitoring des requêtes détecte les patterns d'extraction systématique (volume anormal de requêtes, requêtes ciblant des sujets hors périmètre professionnel) et déclenche des alertes de sécurité pour investigation.

Conclusion

L'architecture RAG étend considérablement la surface d'attaque des systèmes LLM en introduisant des vecteurs spécifiques que les défenses standards des modèles de langage ne couvrent pas. L'empoisonnement du vector store, l'extraction de documents confidentiels et la manipulation des résultats de recherche nécessitent des contre-mesures architecturales dédiées à chaque composant du pipeline pour garantir la confidentialité des données d'entreprise accessibles via le LLM.