# Sécurité RAG : injection de prompt, mémoire et isolation client

> Analyser la sécurité d’un RAG : documents hostiles, mémoire persistante, droits, caches et outils. Une matrice de tests défensifs avec preuves attendues.

Publié le: 2026-11-04  
Canonical: https://rootzero.eu/research/securite-rag-injection-memoire/

Un passage récupéré dans un RAG constitue une donnée externe, même lorsqu’il ressemble à une instruction destinée à l’assistant. Le risque apparaît lorsque cette donnée peut changer la conduite du système, provoquer un accès indu ou influencer une action d’outil. Une citation fidèle du document ne démontre pas que son contenu est sûr.

L’[OWASP décrit la surface de sécurité RAG](https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html) tout au long du pipeline. Nous proposons ci-dessous un ensemble de vérifications défensives pour un environnement de démonstration autorisé. Il complète le [guide d’architecture](/research/rag-entreprise-architecture-droits-evaluation/) et ne constitue pas un test du produit SpectrAI.

## Tracer le trajet d’une donnée jusqu’à un effet

Pour chaque source, identifiez qui peut la publier, la modifier et l’approuver. Suivez ensuite son extraction, son indexation, sa présence dans le contexte et les outils auxquels le système peut accéder. Une source interne peut aussi être compromise ou contenir une citation hostile.

La séparation entre données et instructions doit rester visible dans l’application. Les délimiteurs aident à représenter cette différence, mais ne constituent pas une barrière d’autorisation. Un outil doit continuer à vérifier ses paramètres et les droits de l’appelant, quelle que soit l’explication fournie par le modèle.

## Les droits doivent tenir avant la génération

Un document client interdit ne doit pas être envoyé au modèle dans l’espoir qu’il ne le cite pas. Examinez aussi le reclassement, les traces et les caches. Chacun peut recevoir des extraits avant que la réponse finale soit filtrée.

Pour un test inter-clients, placez un marqueur fictif propre à l’espace B et interrogez depuis l’espace A. Vérifiez les candidats, le contexte et les sorties d’outils, pas uniquement l’interface. Le marqueur sert d’observation sur ce cas ; son absence dans une réponse ne prouve pas à elle seule l’absence de fuite ailleurs.

## Une mémoire peut rendre l’incident durable

Une instruction non fiable peut d’abord être résumée, puis enregistrée comme préférence ou règle. À la consultation suivante, son origine peut avoir disparu. Le système paraît alors appliquer une décision interne alors qu’il réutilise une donnée introduite par une source externe.

Préservez l’origine et le statut des candidats mémoire. Définissez quelles écritures demandent une validation et quelles données ne doivent jamais devenir des règles partagées. Après retrait d’une source, recherchez ses dérivés et testez une nouvelle session pour vérifier le comportement de reprise.

## Matrice de vérification proposée

| Cas de démonstration | Résultat attendu | Pièce à examiner |
| --- | --- | --- |
| Document d’un autre client | Aucun passage transmis hors de son périmètre | Décision d’accès et contexte sortant |
| Contenu documentaire demandant une action interdite | L’outil refuse l’effet non autorisé | Paramètres, identité et reçu de refus |
| Résumé reprenant une instruction externe | L’origine ne devient pas une autorisation | État mémoire avant et après |
| Source retirée ou droit révoqué | Les dérivés ne permettent pas de retrouver le contenu | Index, cache et consultation suivante |
| Service de contrôle indisponible | La tâche sensible ne se poursuit pas sans décision | Erreur, statut bloqué et absence d’effet |

Ces attentes doivent être adaptées au contrat réel du service. La protection ne se résume pas à une liste de formulations interdites : une même intention hostile peut prendre plusieurs formes, et une phrase suspecte peut aussi figurer dans une documentation légitime.

## Ce que démontre notre exemple local

Le [programme téléchargeable](/lab/rag-demo/rag-demo.zip) refuse les métadonnées d’accès manquantes, une révision remplacée et une entrée marquée non approuvée. Le marqueur `approved` vient du jeu d’essai. Le programme n’analyse pas le texte pour décider s’il contient une injection ; un document approuvé pourrait en contenir une.

Ses dix cas vérifient des règles de sélection déterministes. Pour tester un agent avec génération et outils, il faut une expérience différente. [AgentDojo](https://arxiv.org/abs/2406.13352) fournit un environnement de recherche sur les injections dans des données d’outils ; ses résultats et son protocole ne doivent pas être assimilés à une garantie pour votre service.

Associez enfin l’essai hostile à des tâches normales : une défense qui interdit toute lecture peut empêcher l’incident tout en rendant le service inutilisable. L’[évaluation des agents cyber](/research/evaluer-agent-ia-cyber-preuves-metriques/) explique comment conserver cette distinction. Retrouvez les autres couches dans le [dossier IA et cyber](/dossiers-ia-cyber/).