Votre RAG est peut-être une fuite de données en attente
Un RAG entreprise connecté à votre base documentaire interne est un vecteur de fuite d'informations si les contrôles d'accès ne sont pas implémentés au niveau du retriever. Un stagiaire qui pose une question sur les salaires, un prestataire qui accède à des documents stratégiques, un utilisateur qui injecte des instructions pour contourner les garde-fous : ces scénarios sont réels et fréquents. Les trois piliers de la sécurité RAG : filtrage par droits d'accès au niveau du vector store, protection contre l'injection de prompt, et audit des accès pour la gouvernance IA. Sans ces contrôles, votre assistant IA est une porte ouverte sur vos données les plus sensibles.
Le problème
La plupart des RAG entreprise sont déployés avec un index vectoriel unique contenant tous les documents : procédures, contrats, données RH, informations financières, documents stratégiques. La recherche vectorielle ne vérifie pas les droits d'accès — elle retourne les chunks les plus similaires à la requête, quelle que soit leur sensibilité.
Les vecteurs d'attaque principaux :
- Escalade de privilèges par le RAG — Un utilisateur avec des droits limités utilise l'assistant pour interroger des documents confidentiels. Un commercial demande la marge nette d'un projet et reçoit une réponse basée sur un document financier confidentiel. Le RAG court-circuite les contrôles d'accès existants (SharePoint, Confluence, SIRH).
- Injection de prompt — Un utilisateur malveillant manipule sa requête pour détourner le LLM. Les attaques indirectes sont encore plus insidieuses : un attaquant insère des instructions malveillantes dans un document qui sera indexé, et le LLM les exécute quand il lit le chunk.
- Exfiltration par inférence — Par des questions itératives (« Le salaire moyen est-il supérieur à 50K ? à 60K ? à 65K ? »), un utilisateur extrait des informations sensibles sans jamais accéder directement aux documents.
- Données résiduelles — Le LLM peut inclure dans sa réponse des fragments de documents confidentiels récupérés mais non pertinents pour la question. L'utilisateur reçoit des informations auxquelles il ne devrait pas avoir accès.
La solution IA
La sécurité RAG repose sur trois couches de défense complémentaires, de la requête à la réponse.
Filtrage par droits d'accès (ACL)
Chaque chunk est taggé avec les groupes utilisateurs autorisés lors de l'indexation. Le retriever filtre par ACL avant la recherche vectorielle : seuls les chunks accessibles à l'utilisateur courant sont inclus dans le top-K. Synchronisez les ACL avec votre annuaire (Active Directory, LDAP, Okta). Implémentation native sur Pinecone, Weaviate et Qdrant.
Protection contre l'injection de prompt
Trois niveaux de défense : input sanitization (détection et blocage des instructions malveillantes), prompt hardening (instructions système résistantes à l'injection avec délimiteurs et refus), et output filtering (vérification que la réponse ne contient pas de données hors périmètre). Utilisez Guardrails AI, NeMo Guardrails ou Lakera Guard.
Audit et détection d'anomalies
Journalisez chaque requête et accès document avec les métadonnées utilisateur. Détectez les patterns suspects : requêtes itératives sur un sujet sensible, volume anormal, tentatives d'injection répétées. Alertes automatiques pour l'équipe sécurité. Intégration SIEM (Splunk, Sentinel, Elastic Security).
Mise en oeuvre
La sécurisation d'un RAG existant prend 4 à 6 semaines. Priorité : le filtrage par droits d'accès, qui couvre 80% du risque.
Cartographie des droits et tagging ACL (semaines 1-2)
Auditez les droits d'accès actuels de votre base documentaire (SharePoint, Confluence, GED). Définissez les groupes d'accès par département, rôle et niveau de confidentialité. Implémentez un pipeline d'indexation qui extrait automatiquement les ACL de chaque document source et les associe comme métadonnées à chaque chunk. Testez avec 10 profils utilisateurs représentatifs.
Protection contre l'injection (semaines 3-4)
Implémentez trois couches de défense. Input layer : un classificateur détecte les tentatives d'injection et bloque la requête. Prompt layer : renforcez le prompt système avec des délimiteurs XML et une instruction de refus explicite. Output layer : vérifiez que la réponse ne mentionne pas de documents hors ACL. Testez avec un red team de 5 scénarios d'attaque standardisés (OWASP LLM Top 10).
Monitoring sécurité et audit (semaines 5-6)
Intégrez les logs de l'assistant IA dans votre SIEM. Configurez des règles de détection : plus de 50 requêtes/heure par utilisateur, patterns d'injection, accès à des documents de classification élevée par un utilisateur standard. Programmez un pentest trimestriel. Documentez les risques résiduels dans votre registre de risques IA.
Résultats
Résultats mesurés après sécurisation de RAG entreprise en production.
Questions fréquentes
Qu'est-ce que le risque de fuite d'informations dans un RAG ?
Un RAG indexe l'ensemble de la base documentaire dans un seul index vectoriel. Sans contrôle d'accès, un utilisateur peut poser une question et recevoir une réponse basée sur des documents auxquels il n'a normalement pas accès : salaires, documents stratégiques, données clients. Le retriever ne vérifie pas les droits — il retourne les chunks les plus similaires, quelle que soit leur classification.
Comment implémenter le filtrage par droits d'accès dans un RAG ?
Deux approches : le filtrage pré-retrieval (les métadonnées de chaque chunk incluent les groupes autorisés, et la requête vectorielle filtre par user_groups avant la similarité cosinus) et le filtrage post-retrieval (le retriever retourne les top-K puis un middleware filtre). Le pré-retrieval est plus performant et plus sûr. Supporté nativement par Pinecone, Weaviate, Qdrant et Milvus.
Les attaques par injection de prompt sont-elles un risque réel ?
Oui. Un utilisateur malveillant peut injecter des instructions pour contourner les garde-fous. Les attaques sophistiquées incluent l'injection indirecte (instructions cachées dans un document indexé) et l'extraction de prompt système. Les parades : input sanitization, prompt hardening, et détection d'attaques par classificateur (Lakera Guard, garak).
Pour les profils tech
Architecture de sécurité RAG
La sécurité RAG s'implémente en trois couches : couche données (ACL sur les chunks dans le vector store), couche application (input validation, prompt hardening, output filtering), et couche monitoring (détection d'anomalies, intégration SIEM).
Filtrage ACL — implémentation pré-retrieval :
Lors de l'indexation, chaque chunk reçoit une métadonnée allowed_groups: ["finance", "direction"] héritée du document source (synchro Active Directory / LDAP). À chaque requête, le middleware extrait les groupes de l'utilisateur depuis le JWT/session et ajoute un filtre metadata au vector store : filter={"allowed_groups": {"$in": user.groups}}. Ce filtre est appliqué AVANT le calcul de similarité.
Prompt hardening — bonnes pratiques :
- Délimiteurs XML pour séparer instructions système et contenu utilisateur.
- Instruction de refus explicite contre les tentatives de modification du prompt.
- Restriction de périmètre : répondre uniquement à partir des documents fournis.
- Tests avec jeux d'attaques standardisés : OWASP LLM Top 10, garak.
Comparatif des solutions de sécurité LLM
| Critère | Guardrails AI + ACL | Lakera Guard | NeMo Guardrails | Custom |
|---|---|---|---|---|
| Détection injection | Bon | Excellent | Bon | Basique |
| Filtrage ACL natif | Via vector store | Non | Partiel | Custom |
| Output filtering | Oui (validators) | Oui | Oui (flows) | À développer |
| Open source | Oui | SaaS | Oui (Apache 2) | N/A |
| Latence ajoutée | +20ms | +50ms | +40ms | +5ms |