Comment sécuriser un pipeline RAG (retrieval-augmented generation) ?
Réponse courte
La sécurité RAG, c'est traiter chaque document récupéré comme une entrée non fiable. Risques clés : prompt injection indirecte cachée dans le contenu récupéré, empoisonnement de la base de connaissances ou des embeddings, et absence d'autorisation par utilisateur si bien que le modèle renvoie des données auxquelles l'utilisateur n'a pas accès. Les défenses incluent le contrôle d'accès appliqué à la récupération, la provenance du contenu et la vérification à l'ingestion, traiter le texte récupéré comme des données et non des instructions, la validation des sorties et l'isolement du magasin de vecteurs par locataire.
La retrieval-augmented generation ancre un LLM en récupérant des documents pertinents depuis une base de connaissances (généralement un magasin de vecteurs) et en les insérant dans le prompt. Ce contexte supplémentaire est aussi une nouvelle et vaste surface d'attaque, et l'état d'esprit central est : chaque fragment récupéré est une entrée non fiable.
Risques étape par étape
- Ingestion. Tout ce que vous indexez, le modèle le lira ensuite et pourra y obéir. Un document empoisonné ou rédigé par un attaquant devient une prompt injection indirecte qui se déclenche dans la session de confiance de quelqu'un d'autre. Vérifiez les sources, tracez la provenance et restreignez qui peut contribuer au corpus.
- Stockage / embeddings. Les magasins de vecteurs peuvent être empoisonnés (en y plaçant des documents adverses qui se classent toujours haut) et les embeddings peuvent divulguer des informations via des attaques par inversion. Isolez les magasins par locataire et protégez-les comme tout magasin de données sensible.
- Récupération. La plus grande défaillance pratique est l'autorisation : si la récupération ne filtre pas selon les permissions de l'utilisateur demandeur, le modèle fait remonter des documents qu'il ne devrait jamais voir. Appliquez le contrôle d'accès au moment de la requête, cadré sur l'utilisateur — pas comme un filtre a posteriori sur la réponse.
- Génération. Délimitez clairement le contenu récupéré comme des données, instruisez le modèle de ne pas suivre les instructions qui s'y trouvent, et validez/assainissez la sortie avant son affichage ou son passage à des outils.
Défense en profondeur
Combinez récupération à moindre privilège, vérification et signature à l'ingestion, isolement par locataire, mitigations contre l'injection indirecte et validation des sorties. Aucun contrôle unique ne suffit.
Ce que recherchent les recruteurs
Le cadrage « le contenu récupéré est non fiable », la mise en avant de l'autorisation par utilisateur à la récupération, et la conscience de l'injection indirecte et de l'empoisonnement de la base de connaissances comme menaces propres au RAG — pas juste de la sécurité générique de base de données.
Questions de suivi probables
- Comment un document empoisonné dans la base de connaissances peut-il attaquer un autre utilisateur ?
- Où exactement l'autorisation devrait-elle être appliquée dans un flux RAG ?
- Qu'est-ce qu'une attaque par inversion d'embedding ?