La plupart des défenses contre l'injection de prompts supposent encore que la surface d'attaque s'arrête à la frontière du modèle. Ce n'est pas le cas. Lorsqu'un système basé sur un LLM récupère du contexte depuis un magasin vectoriel, appelle des outils externes, puis transmet les résultats à des consommateurs en aval, chaque maillon de cette chaîne devient un point d'injection potentiel. Le bon modèle mental n'est pas la « sanitation des entrées » — c'est la sécurité de la chaîne d'approvisionnement.
La couche de récupération est la première frontière de confiance
Les pipelines RAG récupèrent des documents puis les injectent dans le contexte du prompt. Si un attaquant peut influencer le contenu de ces documents — via une source de données compromise, un embedding empoisonné ou une page publique soigneusement conçue pour être indexée — il contrôle une partie du prompt. Ce n'est pas hypothétique. Nous l'avons observé dans trois engagements distincts cette année, à chaque fois dans des organisations qui avaient investi dans le filtrage de sortie mais n'avaient aucun contrôle sur la provenance du contenu récupéré.
La réponse n'est pas de filtrer ce contenu récupéré pour y chercher des motifs d'attaque connus. Cette approche échoue pour la même raison que les antivirus à signature échouent : l'attaquant s'adapte. Il faut plutôt traiter le contexte récupéré comme une dépendance tierce — l'épingler, le hacher, surveiller ses changements inattendus et limiter les permissions du système qui le consomme.
Les appels d'outils étendent le rayon d'impact
Lorsqu'un agent peut exécuter des outils — envoyer des e-mails, interroger des bases de données, modifier des enregistrements — l'injection de prompts devient une forme d'exécution distante sous un autre nom. L'injection n'a même pas besoin d'exfiltrer les données dans la sortie texte du modèle. Elle peut pousser le modèle à agir directement. Chaque liaison d'outil est une permission implicite, et la plupart des frameworks d'agents accordent ces permissions sans les limiter à la tâche en cours.
Nous recommandons de traiter les liaisons d'outils comme des politiques IAM : privilège minimal, périmètre limité à la session, auditables et révocables. Si un agent dispose d'un accès en écriture à une base de production, cet accès devrait nécessiter une approbation humaine explicite — pas simplement un prompt système disant « n'écris que lorsque c'est approprié ».
Les consommateurs en aval héritent du risque
La sortie d'un appel LLM devient souvent l'entrée d'un autre. Le résumé alimente le reporting. La classification alimente le routage. Si la sortie du premier modèle est compromise, chaque consommateur en aval opère sur des données contaminées. C'est l'analogie de la chaîne d'approvisionnement à l'état pur : une vulnérabilité n'importe où dans le pipeline peut se propager à tous les systèmes qui en dépendent.
La vraie question n'est pas « peut-on tromper notre modèle ? » mais « que peut atteindre un attaquant si c'est le cas ? »
Nous avons développé un cadre de modélisation de menaces qui cartographie explicitement ces dépendances. Pour chaque composant d'un pipeline LLM, nous identifions les frontières de confiance, les flux de données et le rayon d'impact d'une injection réussie. Le résultat n'est pas une checklist — c'est un graphe de dépendances qui s'intègre aux contrôles SSDLC et aux playbooks de réponse à incident déjà en place.
Si votre organisation exploite des LLM en production, la surface d'attaque est plus large que le modèle. Traitez l'injection de prompts comme un problème de chaîne d'approvisionnement, et les défenses prennent alors une forme très différente.