Ton pipeline RAG est un adjoint confus

En 1988, Norm Hardy a publié un court article décrivant ce qu’il appelait le « problème de l’adjoint confus » (confused deputy problem). La situation était simple : un compilateur avait accès à un fichier de facturation (pour journaliser les frais d’utilisation) et à des fichiers de sortie spécifiés par l’utilisateur. Un utilisateur malin pouvait pointer la sortie vers le chemin du fichier de facturation. Le compilateur, l’« adjoint », l’écrasait docilement, parce qu’il avait l’autorité d’écrire dans ce fichier et que la requête de l’utilisateur semblait légitime.

L’adjoint n’était pas compromis. Il n’était pas buggé. Il était confus, il ne pouvait pas distinguer une requête qu’il devait satisfaire d’une autre qui exploitait ses propres privilèges.

Si tu construis des systèmes de génération augmentée par la récupération en 2026, tu as exactement le même problème.

Comment le RAG crée des adjoints confus

Un pipeline RAG typique fonctionne ainsi : un utilisateur pose une question ; le système récupère les documents pertinents dans une base de connaissances ; ces documents sont injectés dans la fenêtre de contexte du modèle aux côtés de la question de l’utilisateur ; le modèle génère une réponse.

Le modèle est l’adjoint. Il a accès à ta base de connaissances (via la récupération), à la question de l’utilisateur, et souvent à des outils capables d’agir. L’attaque n’est pas exotique : intègre une instruction dans un document de ta base de connaissances, et la prochaine fois que ce document est récupéré, le modèle suivra l’instruction comme si elle venait de toi. C’est l’injection de prompt indirecte, le prompt est le nouveau périmètre, et c’est le mode de défaillance qui surprend le plus les équipes.

Ce n’est pas théorique. Je l’ai vu fonctionner dans des systèmes en production, avec des charges utiles d’attaque dissimulées dans :

Des tickets de support client indexés par la suite pour le RAG
Des pages Confluence que n’importe qui dans l’organisation pouvait éditer
Des documents PDF téléversés par des prestataires externes
Des fils d’e-mails transférés vers une boîte partagée qui alimente la base de connaissances

Dans chaque cas, le système de récupération a fidèlement récupéré le document empoisonné, le modèle a fidèlement suivi l’instruction intégrée, et personne ne s’en est aperçu jusqu’à ce que la sortie soit fausse d’une manière qui comptait.

La solution de 1988 s’applique toujours

La solution de Hardy était la sécurité par capacités : au lieu de donner à l’adjoint une large autorité en espérant qu’il l’utilise correctement, tu lui donnes un jeton spécifique et infalsifiable pour chaque action qu’il est autorisé à effectuer. L’adjoint ne peut faire que ce que son ensemble courant de capacités permet, et ces capacités sont accordées par interaction, pas globalement.

Pour le RAG, l’équivalent ressemble à ceci :

Étiquette chaque document avec son niveau de confiance au moment de l’ingestion. Les docs internes, le contenu généré par les utilisateurs, les téléversements externes et ta propre documentation système ne sont pas la même chose et ne devraient pas être traités de la même manière dans la fenêtre de contexte.
Restreins la récupération au niveau d’accès de l’utilisateur. Si l’utilisateur qui pose la question n’a pas accès à un document, la couche de récupération ne devrait pas le récupérer, même si c’est le résultat le plus pertinent. Ça semble évident. La plupart des systèmes ne le font pas.
Présente le contenu récupéré au modèle comme une entrée non fiable. Utilise des balises de rôle, des délimiteurs ou un prompting structuré pour faire comprendre au modèle que les documents récupérés sont des données, pas des instructions. C’est imparfait, les modèles ne respectent pas cette distinction de manière fiable, mais ça relève le niveau.
Limite ce que le modèle peut faire avec les informations récupérées. Si le travail du modèle est de répondre à des questions, il n’a pas besoin d’accès aux outils. S’il en a besoin, ces outils devraient être restreints aux exigences du tour courant, pas à l’ensemble complet des capacités, le moindre privilège pour les modèles de langage.

Le problème de l’adjoint confus a été résolu, conceptuellement, il y a trente-huit ans. La solution, c’est le contrôle d’accès à la bonne granularité. Il nous suffit de l’appliquer à des systèmes qui lisent de l’anglais plutôt que du code machine.