Prenons l’exemple d’un assistant de messagerie : il reçoit un message demandant un résumé, récupère des documents d’entreprise pertinents, fait appel à un outil de gestion d’agenda et génère une réponse HTML concise. Un e-mail provenant d’une source non fiable peut s’insérer dans ce flux en tant que contenu ; or, le modèle traite ce texte parallèlement aux instructions de la tâche. Si ce contenu modifie le résultat attendu — passant de la simple synthèse du message à l’exécution d’une action non prévue —, on parle alors d’injection de prompt : une entrée qui altère le comportement du modèle au-delà de la tâche initialement définie par l’application.
Dans notre assistant, il existe cinq points où du contenu s’intègre à la requête adressée au modèle. L’utilisateur fournit le texte de l’e-mail, le système de récupération renvoie des passages indexés, les outils connectés fournissent des données, le modèle génère du texte ou des arguments pour les outils, et le moteur de rendu transforme cette sortie en HTML. Chaque étape implique un niveau de confiance différent, mais le modèle reçoit un flux de jetons (tokens) combiné plutôt qu’une séquence protégée par une frontière de sécurité imposée par l’application.
Avant d’évaluer les mesures de contrôle, examinons les points de ce flux où les données peuvent se transformer en instructions.
Ce flux démontre pourquoi le simple filtrage de la zone de discussion est insuffisant. Un e-mail externe peut véhiculer l’instruction injectée, une opération de récupération peut l’intégrer au contexte, et le résultat d’un outil peut la reproduire lors d’une étape ultérieure. Le rendu HTML ajoute une frontière supplémentaire, car une sortie considérée comme du simple texte par le modèle peut se transformer en lien actif, en balise ou en requête au sein du navigateur. Il convient d’étiqueter chaque source (comme étant de confiance, partiellement fiable ou non fiable) avant qu’elle n’atteigne le contexte, puis de conserver cette étiquette dans les journaux.
Ce flux mixte constitue le périmètre de la norme OWASP LLM01:2026. Elle couvre l’injection directe (issue des saisies de l’utilisateur) et l’injection indirecte (provenant de documents récupérés, d’e-mails, de pages web, de résultats d’outils, de la mémoire persistante, d’images, d’audio ou de vidéo). Un cas direct débute par un message de l’utilisateur. Un cas indirect survient lorsqu’un corps d’e-mail, présent dans l’index de récupération de notre assistant, fournit un texte que l’utilisateur n’a jamais rédigé ni vu.
Chaque cas peut être classé selon trois axes. La surface de transmission correspond au point d’entrée du contenu (par exemple, un e-mail ou la réponse d’un outil). La propagation désigne le cheminement ultérieur du contenu (par exemple, le transfert d’un résultat de récupération vers la mémoire persistante). Le codage correspond à la manière dont le contenu est représenté (texte brut, caractères Unicode dissimulés ou instructions intégrées dans une image). Cette classification permet de tester le cheminement réel, et non simplement un modèle de phrase.
La paramétrisation traditionnelle empêche les données de modifier la syntaxe de la requête, car la base de données traite les paramètres séparément. Les applications LLM actuelles ne disposent pas d’une séparation aussi nette lorsque les instructions et les données arrivent sous forme de jetons (tokens) dans le même contexte. Les délimiteurs et les étiquettes peuvent clarifier l’intention, mais ils ne garantissent pas le respect des droits d’accès. La frontière de sécurité doit plutôt se situer à l’extérieur du modèle : c’est là que le code vérifie les autorisations, valide les arguments et restreint la portée des sorties générées.
Hypothèse de travail Considérez toute entrée du modèle comme étant susceptible d’influencer la sortie, même si elle provient d’un système de récupération interne.
Une fois qu’un e-mail injecté influence la sortie, les conséquences dépendent des autorisations définies par l’application hôte. Si l’assistant révèle du contenu système masqué ou un extrait privé récupéré, le scénario relève de la vulnérabilité OWASP LLM08:2026 (Exposition de contexte masqué). S’il génère du code HTML accepté par le moteur de rendu sans assainissement, ou des arguments d’outils exécutés par le code en aval sans validation, il s’agit de la vulnérabilité OWASP LLM10:2026 (Gestion inappropriée des sorties). La vulnérabilité LLM01 correspond au compromis initial au niveau des entrées qui déclenche ces conséquences.
Cette même injection peut également tenter d’effectuer une action non sécurisée sur le calendrier ou de s’inscrire de manière persistante dans le corpus de données récupérées. Ces risques s’aggravent lorsque le modèle peut faire appel à des outils aux fonctionnalités étendues ; toutefois, la requête du modèle ne doit jamais constituer sa propre autorisation. Le service de calendrier doit vérifier les droits de l’utilisateur, limiter les champs modifiables et exiger une approbation pour les modifications ayant des conséquences importantes. Le moteur de rendu ne doit autoriser que des formats de sortie sûrs. Chaque couche limite un vecteur d’attaque différent une fois la sortie du modèle modifiée.
Comparez les résultats pour identifier quelle frontière doit bloquer chacun d’eux.