Un seul filtre ne suffit pas : une défense en couches pour les chatbots RAG

De quoi s’agit-il ?

Le 17 juin 2026, un article intitulé A Layered Security Framework Against Prompt Injection in RAG-Based Chatbots a été mis en ligne sur arXiv. Son argument est simple et mérite d’être pris au sérieux : la plupart des défenses contre l’injection de prompt agissent à un seul point du pipeline, et un seul point ne suffit jamais pour un système à génération augmentée par récupération. Un filtre d’entrée voit le message de l’utilisateur, mais jamais les documents que le récupérateur va chercher. Un moniteur de sortie voit la réponse du modèle, mais seulement après qu’une charge malveillante a déjà atteint le modèle. Chaque contrôle a un angle mort, et l’injection indirecte se loge précisément dans ces angles morts.

L’injection de prompt reste l’entrée numéro un — LLM01 — du Top 10 OWASP pour les applications LLM, et le RAG aggrave le problème au lieu de le résoudre. Dans un chatbot classique, le texte non fiable se limite à ce que l’utilisateur saisit. Dans un chatbot RAG, le corpus de connaissances devient lui-même une surface d’attaque : un seul document empoisonné, indexé une fois, peut compromettre tous les utilisateurs dont la requête le fait remonter. L’article présente sa contribution comme la fermeture de cette brèche par la défense en profondeur, plutôt que par un classifieur unique plus intelligent.

Comment ça marche

Il s’agit d’une conception défensive, pas d’une attaque : il n’y a donc rien d’opérationnel à masquer. Le cadre place trois contrôles indépendants le long du chemin d’inférence, chacun responsable d’une frontière de confiance différente.

Couche 1 — filtrage de l’entrée. Avant tout, le message de l’utilisateur est examiné par une bibliothèque de motifs à base de règles (formulations d’injection connues, séquences de contrôle suspectes) combinée à un classifieur d’anomalie sémantique affiné, qui signale les entrées qui ressemblent à des instructions destinées au système plutôt qu’à des questions à traiter. Cela intercepte l’injection directe à la porte, mais, par conception, on ne lui fait pas confiance pour tout attraper.

Couche 2 — hiérarchie d’instructions fondée sur la provenance. C’est la couche la plus importante pour le RAG. Lors de l’assemblage du prompt — politique système, documents récupérés, requête utilisateur — le cadre étiquette chaque segment selon son origine et impose un ordre : la politique de l’opérateur prime sur l’entrée utilisateur, qui prime sur le contenu récupéré. Un texte issu d’un document récupéré n’a jamais le droit d’être lu comme une instruction qui outrepasse les règles de l’opérateur. Une entrée empoisonnée du corpus peut toujours dire « ignore tes instructions », mais au moment de l’assemblage elle porte l’autorité la plus faible et est traitée comme donnée, non comme commande. Cela répond directement à la voie d’injection indirecte que les filtres d’entrée ne peuvent structurellement pas voir.

Couche 3 — audit de la sortie. Après génération, la réponse passe par un moteur de règles de politique et un contrôle de dérive sémantique qui compare la réponse à la tâche visée. Si le modèle a été détourné — fuite du contenu du prompt système, exécution d’une instruction embarquée, éloignement de la question réelle de l’utilisateur — l’écart est détecté avant que la réponse ne soit renvoyée.

Les couches sont volontairement redondantes. L’idée n’est pas que l’une d’elles soit parfaite, mais qu’une attaque doive déjouer les trois, et que les trois échouent de manières différentes.

Pourquoi c’est important

Les chiffres rapportés donnent une idée de l’ampleur de l’effet : dans l’évaluation des auteurs, la combinaison des trois contrôles a réduit le taux de réussite des attaques d’environ 71 % à environ 11 %, tout en maintenant le taux de faux positifs autour de 5 %. Ce sont les deux chiffres qui décident si une défense est déployable — un filtre qui bloque les injections mais bloque aussi une requête légitime sur cinq ne survit jamais au contact des vrais utilisateurs.

Plus important que les pourcentages exacts : la leçon structurelle, qui dépasse ce seul système. Les équipes greffent souvent un unique garde-fou sur un déploiement RAG — généralement un classifieur d’entrée, parce que c’est l’endroit le plus facile — et considèrent le problème réglé. Il ne l’est pas. L’étape de récupération réintroduit silencieusement du texte non fiable après le passage du filtre d’entrée, et aucun réglage de ce filtre n’inspectera jamais un document qu’il ne voit pas. L’assemblage de contexte tenant compte de la provenance est la pièce que la plupart des déploiements oublient, et c’est précisément celle qui défend le mode de défaillance propre au RAG, où un document indexé empoisonne de nombreuses sessions. Des études de cas industrielles récentes sur la sécurisation des chatbots RAG, comme le déploiement de tourisme intelligent de Hsinchu, aboutissent à la même conclusion du côté applicatif.

Défenses

Ne comptez pas sur une seule étape de filtrage. Un classifieur d’entrée seul ne peut pas voir le contenu récupéré ; un moniteur de sortie seul agit trop tard. Supposez que chaque contrôle a un angle mort et placez des vérifications indépendantes à l’entrée, à l’assemblage du contexte et à la sortie, pour qu’une attaque doive toutes les déjouer.

Étiquetez la provenance et imposez une hiérarchie d’instructions. Marquez chaque segment du prompt assemblé selon son origine — système, utilisateur, récupéré — et faites suivre l’autorité à l’origine : la politique de l’opérateur prime sur l’utilisateur, qui prime sur les documents récupérés. Le texte récupéré doit être structurellement incapable d’outrepasser vos règles, quoi qu’il dise.

Traitez le corpus comme une surface d’attaque. En RAG, un seul document empoisonné peut affecter tous les utilisateurs qui le récupèrent. Vérifiez et surveillez le contenu ingéré, restreignez qui peut écrire dans l’index, et journalisez quels documents ont contribué à une réponse signalée afin de tracer l’empoisonnement.

Auditez la sortie pour la dérive de tâche, pas seulement les mots interdits. Un contrôle de dérive sémantique qui compare la réponse à la tâche visée détecte les détournements qu’un filtre de mots-clés manque — fuite du prompt système, réponse qui suit discrètement une instruction embarquée au lieu de la question de l’utilisateur.

Mesurez le taux de faux positifs, pas seulement le taux de blocage. Une défense qui bloque les attaques mais rejette une part importante des requêtes légitimes finira désactivée. Rapportez les deux chiffres et réglez le point de fonctionnement pour qu’il reste utilisable avant la mise en production.

Status

Élément	Référence	Date	Notes
Article	arXiv:2606.19660	Juin 2026	Défense à trois couches pour chatbots RAG
Couche 1	Filtrage d’entrée : motifs à base de règles + classifieur d’anomalie affiné	—	Intercepte l’injection directe à l’entrée
Couche 2	Hiérarchie d’instructions fondée sur la provenance à l’assemblage	—	Le contenu récupéré ne peut outrepasser la politique — la défense RAG clé
Couche 3	Audit de sortie : moteur de règles + dérive sémantique	—	Détecte le détournement après génération
Effet rapporté	Réussite des attaques ~71 % → ~11 % ; faux positifs ~5 %	—	Évaluation des auteurs
Contexte	OWASP LLM01 ; étude de cas RAG associée arXiv:2509.21367	2025–2026	Injection de prompt classée risque LLM le plus critique

Le cadre ne prétend pas résoudre l’injection de prompt — aucune défense ne le fait de manière crédible aujourd’hui — mais il apporte un argument concret et testable : les déploiements RAG ont besoin de contrôles à plus d’une étape, et l’assemblage de contexte tenant compte de la provenance est l’étape le plus souvent omise. Pour quiconque exploite un chatbot à génération augmentée par récupération, c’est un changement d’architecture peu coûteux à évaluer face à un mode de défaillance réellement difficile.