Injection de prompt : l'OWASP dit qu'il n'existe peut-être aucune parade infaillible. Voici ce qui aide vraiment

La plupart des textes d'éditeurs sur l'injection de prompt se terminent par un produit. La page de l'OWASP, elle, se termine par un aveu — et cet aveu est la phrase la plus utile publiée sur le sujet : compte tenu de l'influence stochastique au cœur du fonctionnement des modèles, on ignore s'il existe des méthodes de prévention infaillibles contre l'injection de prompt. C'est l'entrée n°1 du top 10 sécurité des modèles de langage qui dit, avec ses propres mots, que le problème n'est peut-être pas soluble. Tout ce qui est utile en pratique découle du fait de prendre cette phrase au sérieux.

Ce que c'est, et pourquoi le nom minimise

L'injection de prompt est le risque LLM01 du Top 10 OWASP pour les applications LLM — la première entrée, devant les fuites de données et les problèmes de chaîne d'approvisionnement. L'OWASP en distingue deux formes. L'injection directe : la saisie de l'utilisateur « altère directement le comportement du modèle de façon inattendue ». L'injection indirecte : le modèle « accepte des entrées issues de sources externes, comme des sites web ou des fichiers », et ce contenu change son comportement. Dans les deux cas, l'OWASP précise que la manipulation peut être délibérée ou totalement accidentelle.

Le mot « injection » invite à la comparaison avec l'injection SQL, et c'est précisément là que les équipes se trompent. L'injection SQL a une solution : séparer la requête des données par des requêtes paramétrées, et la classe de bogue disparaît. Ici, aucune séparation équivalente n'existe. Votre prompt système et le paragraphe d'un attaquant arrivent au modèle sous la même forme — du texte — et rien dans le format ne désigne l'un comme faisant autorité. Ce n'est pas un défaut d'implémentation en attente d'un correctif ; c'est une propriété du fonctionnement des modèles.

Le cas indirect est celui qui surprend

L'injection directe se voit. Quelqu'un tape dans votre zone de discussion, vous voyez le trafic, vous pouvez le limiter et le journaliser. L'injection indirecte est plus discrète : votre agent va chercher une page web, ouvre un PDF déposé par un client ou résume un ticket de support — et des instructions présentes dans ce contenu sont lues comme si vous les aviez écrites. L'attaquant ne touche jamais votre interface, et rien dans vos journaux ne ressemble à une attaque.

Cela compte parce que la situation découle de l'architecture, pas d'une erreur. Tout agent qui navigue sur le web, ouvre des fichiers ou ingère des données tierces porte cette exposition par construction. C'est aussi pourquoi Cloudflare a cité l'isolation contre l'injection de prompt parmi ses objectifs de conception en construisant un navigateur destiné aux agents plutôt qu'aux humains : dès qu'un agent lit le web ouvert, le web ouvert devient un canal d'entrée.

Un ruban de balisage rayé noir et blanc portant le mot DANGER, tendu dans une scène sombre — Un ruban de balisage portant le mot DANGER. Il marque une limite sans l'imposer physiquement — exactement ce que fait « séparer et identifier les contenus externes » pour un agent : étiqueter une entrée non fiable aide, mais l'étiquette n'est pas un mur.

Les sept parades citées par l'OWASP

L'OWASP énumère sept stratégies, et il vaut la peine de remarquer qu'aucune n'est un produit que l'on achète :

Contraindre le comportement du modèle par le prompt système
Définir et valider les formats de sortie attendus
Filtrer les entrées et les sorties
Appliquer le contrôle des privilèges et le moindre privilège
Exiger une approbation humaine pour les actions à risque
Séparer et identifier les contenus externes
Mener des tests adverses et des simulations d'attaque

Lues comme une liste, elles ressemblent à sept cases à cocher. Lues comme un ensemble, elles décrivent quelque chose de plus précis : une architecture bâtie sur l'hypothèse que le modèle sera parfois convaincu, et dont le travail consiste à rendre bon marché ce dont on l'aura convaincu.

Deux des sept tiennent même quand l'attaque réussit

Les trois premiers points — prompt système, formats de sortie, filtrage des entrées et des sorties — augmentent tous le coût d'une attaque. Ils méritent d'être faits, et ils finissent tous par céder, parce qu'ils opèrent sur le canal même qu'emprunte l'attaquant.

Le contrôle des privilèges et le moindre privilège, ainsi que l'approbation humaine des actions à risque, sont d'une autre nature. Ils ne cherchent pas à empêcher le modèle d'être persuadé. Ils limitent ce qu'un modèle persuadé peut faire. Si votre agent ne détient que des accès en lecture, une injection réussie lit quelque chose qu'elle ne devrait pas — fâcheux, borné, réparable. S'il détient un jeton de paiement, la même injection réussie devient une tout autre conversation.

C'est pourquoi la bonne question avant de déployer un agent n'est pas « notre prompt est-il bon ». C'est : quelle est la pire chose que cet agent peut faire sans humain dans la boucle, et acceptons-nous qu'elle arrive par accident ? Un agent qui rédige une réponse qu'une personne enverra est un risque réellement différent d'un agent qui rembourse sans surveillance — et la différence ne doit rien au modèle.

Tester, c'est essayer de casser son propre agent

Le septième point, les tests adverses et simulations d'attaque, est celui qu'on saute le plus souvent parce qu'il n'a pas de ligne d'arrivée évidente. Une version praticable est plus étroite qu'il n'y paraît : pour chaque source que consomme votre agent — pages web, documents déposés, tickets, courriels —, lui fournir des contenus qui contiennent des instructions, et regarder ce que l'agent a fait, pas ce qu'il a dit.

Cette distinction est tout le test. Un modèle qui refuse poliment puis appelle quand même l'outil a échoué. Un modèle qui produit une réponse alarmante sans rien toucher, non. Journaliser les appels d'outils, et pas seulement les réponses, est ce qui rend la différence visible — et c'est l'instrumentation la moins coûteuse à ajouter avant qu'un agent n'approche de la production.

Ce qu'il faut retenir de l'aveu de l'OWASP

Si l'injection de prompt avait une solution propre, le plan raisonnable serait de l'appliquer et de passer à autre chose. Elle n'en a pas, donc le plan raisonnable est différent : supposer des réussites occasionnelles, concevoir pour que ces réussites soient ennuyeuses, et instrumenter pour le savoir. C'est une réponse moins satisfaisante qu'un filtre, et c'est celle que les faits soutiennent.

Elle se trouve d'ailleurs être de la bonne ingénierie en toutes circonstances. Le moindre privilège, les formats de sortie validés, la relecture humaine des actions irréversibles et les tests adverses étaient de saines pratiques avant l'existence des modèles de langage. La nouveauté n'est pas dans les contrôles. Elle est qu'un système qui lit du texte peut désormais être argumenté — et que l'argument entre par la même porte que les données.

Questions fréquentes

Qu'est-ce que l'injection de prompt, en une phrase ?

C'est lorsqu'un texte parvenu jusqu'au modèle modifie son comportement d'une manière que vous n'aviez pas prévue. L'OWASP la classe LLM01 dans son Top 10 pour les applications LLM et la coupe en deux : l'injection directe, où la saisie de l'utilisateur altère directement le comportement du modèle de façon inattendue, et l'injection indirecte, où le modèle accepte des entrées venues de sources externes comme des sites web ou des fichiers, dont le contenu change son comportement. Dans les deux cas, la manipulation peut être délibérée ou parfaitement accidentelle.

Pourquoi ne pas simplement dire au modèle d'ignorer les instructions malveillantes ?

Parce que l'instruction que vous écrivez et celle qu'écrit un attaquant arrivent sous la même forme : du texte. Aucun canal ne porte l'autorité. Contraindre le comportement par le prompt système est une vraie parade, et l'OWASP la cite en premier, mais elle augmente le coût d'une attaque plutôt qu'elle ne ferme la porte. L'OWASP est explicite sur la limite : compte tenu de l'influence stochastique au cœur du fonctionnement des modèles, on ignore s'il existe des méthodes de prévention infaillibles contre l'injection de prompt.

Quelle différence concrète entre injection directe et indirecte ?

L'injection directe, c'est quelqu'un qui tape dans votre zone de discussion. Ce trafic se voit et se limite. L'injection indirecte est celle qui surprend les équipes : votre agent va chercher une page web, lit un PDF déposé par un client ou résume un ticket de support, et des instructions cachées dans ce contenu sont lues comme si elles venaient de vous. L'attaquant ne touche jamais votre interface. Tout agent qui navigue, ouvre des fichiers ou ingère des données tierces porte cette exposition par construction.

Que recommande réellement l'OWASP ?

Sept stratégies, et aucune n'est un produit que l'on achète. Contraindre le comportement du modèle par le prompt système. Définir et valider les formats de sortie attendus. Filtrer les entrées et les sorties. Appliquer le contrôle des privilèges et le moindre privilège. Exiger une approbation humaine pour les actions à risque. Séparer et identifier les contenus externes. Mener des tests adverses et des simulations d'attaque. Lues comme un ensemble, elles décrivent une architecture et non un filtre : partir du principe que le modèle peut être convaincu, et faire en sorte que ce dont on peut le convaincre ne coûte pas cher.

Faut-il en conclure qu'il ne faut pas déployer d'agents IA ?

Non, et le lire ainsi serait un contresens. Cela veut dire que le rayon d'action compte davantage que le prompt. Un agent qui rédige une réponse qu'un humain enverra n'est pas la même proposition qu'un agent qui rembourse sans surveillance. Les deux points OWASP qui changent le plus sont le contrôle des privilèges et l'approbation humaine des actions à risque, parce qu'ils tiennent même quand l'injection réussit. Déployez l'agent ; décidez d'abord ce qu'il a le droit de faire seul.

Comment tester ?

L'OWASP cite les tests adverses et les simulations d'attaque parmi ses sept stratégies, ce qui revient poliment à dire qu'il faut essayer de casser son propre agent avant qu'un autre ne s'en charge. En pratique : lui donner, depuis chacune des sources qu'il consomme, des contenus qui contiennent des instructions, et vérifier non pas s'il refuse mais si quelque chose d'irréversible s'est produit. Un test qui n'examine que la réponse du modèle passe à côté : ce qui compte, c'est ce que l'agent a FAIT.

La désignation LLM01:2025, les définitions de l'injection directe et indirecte, les sept stratégies de mitigation et la phrase indiquant qu'on ignore s'il existe une prévention infaillible proviennent toutes de la page consacrée à l'injection de prompt par l'OWASP Gen AI Security Project, consultée au moment de la rédaction. Nous n'avons pas mené notre propre programme de tests adverses et ne revendiquons ici aucune mesure qui nous soit propre.

L'accompagnement ZAX sur les agents IA

Nous construisons des agents IA pour des entreprises, ce qui veut dire que l'essentiel du temps de conception passe sur cette question précise : ce que l'agent a le droit de faire seul, et ce qui demande une personne. Le périmètre des privilèges, la journalisation des appels d'outils et les points d'approbation humaine font partie de la construction, pas d'un rattrapage.

Audit et cadrage. Un audit IA gratuit de 30 minutes examine ce que votre agent peut atteindre aujourd'hui, et ce qui se passerait si on le convainquait de s'en servir.

Contactez-nous pour parler de l'architecture de vos agents.