Source contrôlée
L’attaquant peut déposer, modifier ou influencer un contenu qui sera ensuite indexé ou consulté.
SÉCURITÉ RAG
Un document peut devenir une instruction hostile.
Un système RAG enrichit la réponse d’un modèle avec des documents récupérés dans une base de connaissances. Le risque apparaît lorsque le modèle traite le contenu récupéré comme une instruction fiable plutôt que comme une donnée. Un document piégé peut alors influencer la réponse, détourner un agent ou faciliter une exfiltration.
Qu’est-ce qu’un système RAG ?
RAG signifie Retrieval-Augmented Generation, ou génération augmentée par récupération. Avant d’interroger le modèle, l’application recherche des passages pertinents dans une base documentaire puis les ajoute au contexte. Le modèle peut ainsi répondre à partir de documents internes ou récents sans avoir été réentraîné.
Le RAG améliore la pertinence, mais il ajoute plusieurs composants à sécuriser : sources, ingestion, découpage, métadonnées, embeddings, base vectorielle, moteur de recherche, filtres d’accès et construction finale du prompt. Une faiblesse dans l’un de ces éléments peut exposer des données ou donner une influence indue à un document.
Prompt injection indirecte dans un RAG
Dans une injection indirecte, l’attaquant ne saisit pas nécessairement l’instruction dans le chatbot. Il la place dans une source susceptible d’être ingérée : PDF, page web, email, fiche produit, ticket de support, transcription ou document partagé. Lorsque cette source est récupérée, le modèle peut interpréter l’instruction cachée comme une consigne.
Le scénario devient critique lorsque le RAG alimente un agent IA connecté à des outils. Le document hostile peut chercher à déclencher un envoi, modifier une destination, demander l’accès à une autre source ou inclure des données dans une requête externe.
Instruction interprétée
Le modèle ne sépare pas suffisamment le texte à analyser des ordres qu’il doit suivre.
Permission accessible
Le système récupère des données ou appelle une fonction avec davantage de droits que l’attaquant initial.
Impact observable
La réponse, la donnée sélectionnée ou l’action exécutée est modifiée d’une manière reproductible.
RAG poisoning, injection de contexte et défaut d’isolation
| Risque | Mécanisme | Conséquence |
|---|---|---|
| Prompt injection indirecte | Une source contient une instruction destinée au modèle. | Changement de comportement, fuite ou action non prévue. |
| Empoisonnement des sources | Des contenus faux, biaisés ou hostiles sont ajoutés ou favorisés dans la base. | Réponses manipulées, décisions erronées ou présence persistante d’un payload. |
| Défaut de cloisonnement | Le filtre de droits est appliqué après la recherche ou confié au modèle. | Récupération de documents appartenant à un autre utilisateur, groupe ou client. |
| Retrieval manipulé | Le contenu est optimisé pour être sélectionné par similarité ou par métadonnées. | Une source hostile supplante les documents légitimes. |
| Exfiltration | Le modèle inclut des fragments sensibles dans une réponse, un lien ou un appel externe. | Sortie de données hors de la frontière autorisée. |
Comment auditer la sécurité d’un RAG ?
1. Cartographier le chemin documentaire
L’audit identifie qui peut créer ou modifier une source, comment elle est transformée, quelles métadonnées sont conservées et quels utilisateurs peuvent la retrouver. La provenance et les droits doivent rester traçables jusqu’au passage fourni au modèle.
2. Tester chaque point d’entrée
Les scénarios sont injectés uniquement dans des sources autorisées et contrôlées. Ils peuvent viser un document importé, une page synchronisée, un email, un webhook ou un champ métier. L’objectif est de vérifier si le contenu reste traité comme une donnée.
3. Vérifier le cloisonnement avant le retrieval
Les droits d’accès doivent filtrer les documents avant leur ajout au contexte. Demander ensuite au modèle de « ne pas révéler » une donnée déjà récupérée ne constitue pas une séparation fiable.
4. Mesurer l’influence du document
L’audit compare les documents sélectionnés, les scores de récupération, la réponse finale et les éventuels appels d’outils. Une preuve exploitable montre le chemin complet entre la source contrôlée et l’effet obtenu.
5. Vérifier les flux sortants
Les liens rendus, requêtes réseau, paramètres d’API et outils de communication sont examinés pour empêcher qu’un contenu récupéré puisse choisir une destination ou transporter des données sensibles.
Contrôles recommandés
- Provenance : conserver l’origine, le propriétaire, la date et le niveau de confiance de chaque source.
- Contrôle d’accès : appliquer les droits au niveau de la recherche, avant l’envoi des passages au modèle.
- Séparation : délimiter explicitement les documents comme contenus non fiables et limiter leur capacité à influencer les instructions.
- Validation : contrôler les sorties et les paramètres avant toute utilisation par un outil ou une API.
- Moindre privilège : limiter les données, fonctions et destinations accessibles au système.
- Journalisation : conserver les sources récupérées et les actions réalisées pour reproduire un incident.
Aucun de ces contrôles ne suffit seul. La sécurité dépend d’une combinaison cohérente entre gestion des droits, architecture, surveillance et réduction du rayon d’impact.
Sources techniques
Votre RAG sait-il distinguer une donnée d’une instruction ?
Décrivez les sources, le processus d’ingestion, le cloisonnement et les outils accessibles. L’audit reproduit le chemin complet jusqu’à l’impact.