Sécurisation RAG base de connaissances – 5 attaques
Les systèmes de retrieval-augmented generation (RAG) s’imposent progressivement dans les organisations qui souhaitent connecter un modèle de langage à leurs documents internes. Dans ce contexte, la sécurisation RAG base de connaissances devient un enjeu central, car cette architecture élargit considérablement la surface d’attaque par rapport à un LLM utilisé seul.
La base de connaissances vectorielle, le pipeline d’ingestion, le retriever et la génération de réponses constituent autant de points d’entrée pour des acteurs malveillants. Comprendre les vecteurs d’attaque propres à la sécurisation d’une base de connaissances RAG est donc un prérequis avant tout déploiement en environnement sensible.
Sécurisation RAG base de connaissances – 5 attaques
Temps de lecture : ~10 min
- Pourquoi la sécurité d’un RAG dépasse celle d’un LLM classique
- Les 5 principaux vecteurs d’attaque d’un système RAG
- Sécurisation RAG base de connaissances : les quatre couches de défense
- Observabilité et remédiation : les oubliés de la sécurité RAG
- Ce que cela implique concrètement pour les DSI en environnement régulé
- Aller plus loin avec la sécurisation RAG
- FAQ
Pourquoi la sécurité d’un RAG dépasse celle d’un LLM classique
Un système RAG ne se limite pas à un modèle de langage. Il combine un retriever qui interroge une base vectorielle (Pinecone, Qdrant, OpenSearch, par exemple), un pipeline d’ingestion chargé de transformer les documents sources en embeddings, et une étape de génération où le LLM produit une réponse à partir des passages récupérés. Chacune de ces couches introduit des risques distincts.
La base vectorielle elle-même mérite une attention particulière. Contrairement à une idée répandue, les embeddings ne sont pas des données anonymisées irréversibles. Des travaux de recherche récents montrent qu’il est possible de reconstituer des fragments du texte source à partir des vecteurs, dans certaines conditions. Le vector store doit donc être traité avec le même niveau de protection que les documents originaux : chiffrement au repos avec un système de gestion des clés (KMS), isolation réseau, contrôles d’accès stricts.
L’OWASP RAG Security Cheat Sheet et l’OWASP LLM Top 10 documentent précisément ces risques et servent de référence pour structurer une défense en profondeur adaptée à ce type d’architecture.
Les 5 principaux vecteurs d’attaque d’un système RAG
1. L’empoisonnement de corpus
L’empoisonnement de corpus consiste à introduire des documents malveillants dans la base de connaissances. Une fois indexés, ces documents peuvent être systématiquement récupérés par le retriever et injectés dans la fenêtre de contexte du modèle, orientant ainsi les réponses de façon malveillante ou exfiltrant des informations sensibles. Ce vecteur est particulièrement redoutable dans les environnements où l’ingestion est automatisée et peu contrôlée, par exemple via des connecteurs qui aspirent des dossiers partagés sans validation préalable.
La contre-mesure principale repose sur le durcissement du pipeline d’ingestion : validation des sources autorisées, calcul de hachages d’intégrité sur chaque document, détection d’anomalies sémantiques avant indexation et traçabilité des métadonnées de provenance (source, date, propriétaire). L’absence de ces métadonnées rend impossible toute remédiation en cas de compromission. Cette logique de validation à l’entrée rejoint les principes déjà décrits dans notre article sur le data poisoning des données d’entraînement, qui exploite des failles similaires.
2. La prompt injection indirecte
La prompt injection indirecte est l’une des menaces les plus difficiles à détecter. Elle consiste à dissimuler des instructions adversariales dans un document indexé, par exemple dans un PDF ou une page web aspirée automatiquement. Lorsque le retriever récupère ce document et l’insère dans le contexte, le modèle peut interpréter ces instructions comme des directives légitimes et modifier son comportement : ignorer les règles de sécurité, révéler le contenu du prompt système, ou déclencher des actions non souhaitées dans un contexte agentique.
Plusieurs mesures complémentaires permettent de limiter ce risque. Le prompt système doit explicitement indiquer que les documents récupérés peuvent contenir des instructions malveillantes et que toute demande d’afficher le prompt système ou les sources brutes doit être refusée. Les passages récupérés doivent être encadrés par des balises explicites (par exemple [DOCUMENT START] et [DOCUMENT END]) pour que le modèle les traite comme des références et non comme des directives. Enfin, la requête utilisateur doit être positionnée après les documents dans la fenêtre de contexte, ce qui réduit la capacité des injections à se faire passer pour des instructions de haut niveau.
Bon à savoir : L’OWASP LLM Top 10 classe la prompt injection parmi les risques les plus critiques des applications LLM en production. Dans un système RAG, la surface d’attaque est amplifiée car chaque document indexé devient un vecteur potentiel d’injection indirecte.
3. Les fuites par inférence et l’index leakage
Un attaquant disposant d’un accès en lecture à l’interface RAG peut, sans jamais obtenir directement un document confidentiel, inférer son existence et son contenu. En analysant les scores de similarité sémantique retournés par le retriever, en formulant des requêtes de probing ciblées ou en exploitant les comportements du système (refus, réponses partielles, latence), il est possible de cartographier progressivement la base de connaissances. Ce phénomène est désigné sous le terme d’index leakage.
Les contre-mesures incluent l’obfuscation des scores de similarité exposés à l’utilisateur, la mise en place d’un rate limiting sur les requêtes, le monitoring des patterns d’interrogation anormaux et la suppression des métadonnées sensibles dans les réponses du retriever.
4. Le contournement du contrôle d’accès
Dans un environnement multi-tenant ou multi-métier, le RAG doit garantir qu’un utilisateur ne peut accéder qu’aux documents auxquels il est autorisé. Ce contrôle d’accès basé sur les rôles (RBAC) doit être appliqué côté service, avant que les passages récupérés ne soient injectés dans le prompt, et non délégué au modèle de langage lui-même. Confier au LLM la responsabilité de filtrer les informations selon les droits de l’utilisateur est une erreur d’architecture fréquente et dangereuse.
La séparation physique des indexes par tenant constitue l’approche la plus robuste. Lorsque ce n’est pas possible, les filtres de métadonnées appliqués au moment de la requête vectorielle doivent être imposés par la couche service, avec des tests réguliers pour vérifier qu’aucun contournement n’est possible. L’isolation de tenants dans la base vectorielle est un prérequis pour tout déploiement en environnement régulé, au même titre qu’une architecture de sécurité pensée dès la conception.
5. L’exfiltration de données personnelles et la non-conformité RGPD
Si la base de connaissances contient des données personnelles identifiables (PII) non pseudonymisées, le modèle peut les restituer en clair dans ses réponses, exposant l’organisation à des sanctions de la CNIL et à des violations du RGPD. Ce risque est particulièrement élevé dans les secteurs de la santé, des ressources humaines ou du médico-social, où les documents sources contiennent naturellement des informations sensibles.
La pseudonymisation et le masquage des PII doivent intervenir avant l’indexation, dans le pipeline d’ingestion lui-même. Une analyse d’impact relative à la protection des données (DPIA) est requise dès lors que le traitement porte sur des données sensibles, comme le détaille notre checklist de conformité RGPD pour l’IA. Le droit à l’effacement imposé par le RGPD implique également de disposer d’un mécanisme de désindexation rapide permettant de retirer un document de la base vectorielle sans reconstituer l’intégralité de l’index.
Important : L’ANSSI recommande une approche de défense en profondeur pour les systèmes d’IA manipulant des données sensibles. Cela inclut le cloisonnement des environnements, la traçabilité complète des accès et la réalisation d’exercices de red-teaming avant mise en production.
Sécurisation RAG base de connaissances : les quatre couches de défense
Un modèle de défense en quatre couches
Les travaux académiques et les guides de référence convergent vers un modèle structuré en quatre couches complémentaires. Le tableau ci-dessous synthétise les contrôles à mettre en œuvre à chaque niveau du pipeline RAG.
| Couche | Risques couverts | Contrôles principaux |
|---|---|---|
| Ingestion | Empoisonnement de corpus, PII non masquées | Validation des sources, hachage d’intégrité, scan PII, pseudonymisation, métadonnées de provenance |
| Stockage (vector store) | Fuites d’embeddings, accès non autorisés | Chiffrement au repos (KMS), isolation réseau (VPC), RBAC, isolation de tenants |
| Récupération (retriever) | Index leakage, contournement RBAC, probing | Filtrage par permissions avant augmentation, obfuscation des scores, rate limiting, monitoring |
| Génération (LLM + sortie) | Prompt injection indirecte, exfiltration en sortie | Délimitation du contexte, hiérarchie d’instructions, garde-fous (guardrails), validation de sortie structurée |
Observabilité et remédiation : les oubliés de la sécurité RAG
Observabilité du pipeline RAG
Une architecture sécurisée ne se limite pas aux contrôles préventifs. L’observabilité du pipeline est une composante à part entière de la défense en profondeur. Chaque étape du RAG, de la requête utilisateur à la réponse finale, doit produire des logs exploitables : documents récupérés, scores de similarité, décisions de filtrage, sorties du modèle. Ces journaux permettent de détecter des anomalies de ranking, des tentatives de probing ou des modifications suspectes de l’index.
Remédiation après incident
La capacité de remédiation est tout aussi importante. En cas de compromission d’un document, il doit être possible de le désindexer rapidement, de reconstituer l’historique des accès et de rejouer les indexations sur une base assainie. Sans ces mécanismes, la détection d’un empoisonnement de corpus peut intervenir trop tard pour limiter les dommages. Des exercices réguliers de red-teaming, simulant des attaques réelles sur le pipeline, permettent de valider l’efficacité des contrôles en place avant un incident réel.
Ce que cela implique concrètement pour les DSI en environnement régulé
Pour les directions des systèmes d’information des secteurs public, bancaire, de l’assurance ou du médico-social, la sécurisation d’une base de connaissances RAG n’est pas un sujet purement technique. Elle conditionne la conformité réglementaire de l’ensemble du dispositif IA. Le RGPD impose la minimisation des données, la pseudonymisation, le droit à l’effacement et la traçabilité des traitements. Une DPIA est obligatoire dès lors que des données personnelles sensibles sont impliquées. Les contrats avec les fournisseurs de bases vectorielles et de services LLM doivent préciser les modalités de stockage, de rétention et de portabilité des données.
Chez SafeBrain, nous concevons nos déploiements RAG en intégrant ces contraintes dès la phase de conception, avec un hébergement des données en France, une architecture qui permet l’isolation des tenants et des mécanismes de contrôle d’accès appliqués côté service. Pour aller plus loin sur les fondamentaux de la sécurité des systèmes d’IA, vous pouvez consulter notre article sur la prompt injection et les moyens de s’en protéger, ainsi que notre guide sur la pseudonymisation et l’anonymisation des données dans les projets IA.
Aller plus loin avec la sécurisation RAG
La sécurisation d’une base de connaissances RAG repose sur une vision systémique qui couvre l’ensemble du pipeline, de l’ingestion des documents jusqu’à la validation des réponses générées. L’empoisonnement de corpus, la prompt injection indirecte, l’index leakage, le contournement du contrôle d’accès et l’exfiltration de données personnelles constituent les cinq vecteurs d’attaque les plus critiques à adresser. Chacun appelle des contre-mesures techniques précises, mais aussi une gouvernance claire et une observabilité continue. Dans un contexte réglementaire exigeant, notamment pour les organisations soumises au RGPD ou à des référentiels sectoriels, ces contrôles ne sont pas optionnels : ils sont la condition sine qua non d’un déploiement RAG responsable.
Sécurisation RAG base de connaissances : en résumé
En synthèse, la sécurisation RAG base de connaissances repose sur une combinaison de contrôles techniques, de gouvernance des données et d’exercices réguliers de mise à l’épreuve. En traitant chaque couche du pipeline comme une surface d’attaque potentielle et en intégrant dès la conception les exigences réglementaires applicables, les organisations peuvent réduire significativement les risques tout en tirant parti du potentiel des systèmes RAG.
FAQ
Les embeddings d’une base vectorielle sont-ils aussi sensibles que les données sources ?
Oui. Des recherches récentes montrent qu’il est possible, dans certaines conditions, de reconstituer des fragments de texte à partir des vecteurs. Une base vectorielle doit donc bénéficier du même niveau de protection que les documents originaux : chiffrement, contrôle d’accès et isolation réseau.
Quelle est la différence entre prompt injection directe et indirecte dans un RAG ?
La prompt injection directe est formulée par l’utilisateur dans sa requête. La prompt injection indirecte est dissimulée dans un document indexé dans la base de connaissances et récupérée automatiquement par le retriever lors de la génération de la réponse. Cette seconde forme est plus difficile à détecter car elle ne provient pas de l’utilisateur final.
Comment mettre en œuvre le droit à l’effacement du RGPD dans une base vectorielle ?
Il faut disposer d’un mécanisme de désindexation permettant de supprimer un document et ses embeddings associés sans reconstruire l’intégralité de l’index. Les métadonnées de provenance stockées à l’indexation sont indispensables pour identifier précisément les chunks à supprimer.
Faut-il réaliser une DPIA pour un projet RAG ?
Une analyse d’impact relative à la protection des données (DPIA) est obligatoire dès lors que le traitement est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes, notamment lorsque la base de connaissances contient des données de santé, des données RH ou d’autres catégories sensibles au sens du RGPD.
Le contrôle d’accès peut-il être délégué au modèle de langage lui-même ?
Non. Confier au LLM la responsabilité de filtrer les informations selon les droits de l’utilisateur est une erreur d’architecture. Le filtrage RBAC doit être appliqué par la couche service avant que les passages ne soient injectés dans le contexte, car un modèle de langage peut être manipulé pour contourner ces règles.
Qu’est-ce que le red-teaming appliqué à un système RAG ?
Le red-teaming consiste à simuler des attaques réelles sur le pipeline RAG, notamment des tentatives de prompt injection, d’empoisonnement de corpus ou de probing de l’index, afin de valider l’efficacité des contrôles de sécurité avant la mise en production et d’identifier les points de faiblesse résiduels.
