Pourquoi ne peut-on pas corriger l'injection de prompt comme une injection SQL ?

Parce qu'un modèle de langage ne fait aucune différence d'architecture entre instructions et données : tout arrive dans le même flux de texte. L'OWASP note qu'il n'existe pas d'équivalent des requêtes paramétrées, et qu'aucun mécanisme de prévention fiable n'existe aujourd'hui.

Un chatbot sans outils est-il concerné ?

Oui. Il peut divulguer son contexte, des documents récupérés ou produire un contenu choisi par l'attaquant. Mais les dégâts restent limités à la conversation ; ils changent d'échelle dès que le modèle peut appeler des outils.

Injection de prompt : définition, exemples et parades

L'injection de prompt est une attaque où un contenu fourni au modèle (un message, un document, une page web, une image, le résultat d'un outil) modifie son comportement d'une façon que le concepteur n'a pas voulue. Elle arrive en première place du Top 10 de l'OWASP pour les applications de modèles de langage, édition 2026. Elle ne se corrige pas comme une faille classique : on ne peut que la rendre moins probable et, surtout, limiter ce qu'elle peut provoquer.

Pourquoi le modèle se laisse détourner

L'OWASP (fondation qui publie des référentiels de sécurité applicative) l'explique ainsi : un modèle de langage ne distingue pas, dans son architecture, les « instructions » des « données ». Le prompt système, la question de l'utilisateur, les passages de documents récupérés, l'historique et la mémoire forment un seul flux de texte, sans frontière de confiance imposée. Il n'existe donc pas d'équivalent des requêtes paramétrées qui ont réglé l'injection SQL (le détournement d'une requête de base de données). Le texte malveillant n'a même pas besoin d'être lisible par un humain, ni visible à l'écran.

Directe ou indirecte

	Injection directe	Injection indirecte
Qui écrit le texte malveillant	L'utilisateur lui-même	Un tiers, dans un contenu que le modèle lit
Où il arrive	Dans la conversation	Page web, mail, document, passage d'une base documentaire, image, résultat d'outil
Volontaire ?	Pas toujours : un utilisateur peut coller un texte qui contient des consignes contradictoires	L'utilisateur ne voit souvent rien
Cas particulier	Le jailbreak, quand le but est de faire violer au modèle ses règles de sécurité (voir jailbreak)	L'empoisonnement d'une base documentaire, quand l'effet dure (voir empoisonnement)

Pour l'injection indirecte, l'OWASP classe les sources selon leur niveau de confiance : non fiables (pages web publiques, mails d'inconnus, résultats de recherche), semi-fiables (tickets d'un outil de suivi public, fichiers de présentation de paquets logiciels, réponses d'interfaces de programmation, ou API, tierces), et fiables (vos propres dépôts, bases, documents internes et messagerie). Le dernier cas est le plus traître : un attaquant peut déposer son texte par un canal ouvert, comme un formulaire de contact ou un ticket de support, et attendre que votre assistant le lise avec vos droits.

Les formes repérées par l'OWASP en 2026

Texte caché dans une page ou un document, invisible pour l'utilisateur.
Caractères Unicode invisibles (blocs de balises, sélecteurs de variante, caractères de largeur nulle) qui transportent des instructions ou font sortir des données.
Injection multimodale : une consigne glissée dans une image, sous le seuil de perception, que le modèle extrait.
Fractionnement : la consigne est découpée entre plusieurs champs (en-tête, corps, pièce jointe) pour qu'aucun ne paraisse suspect, et le modèle la recompose.
Encodages et langues peu dotées : Base64, ROT13, émojis ou mélange de langues contournent des filtres qui n'ont pas vu ce codage.
Exfiltration par image : le modèle insère une image Markdown dont l'adresse contient des extraits de la conversation ; l'utilisateur ne voit qu'une image.

Ce que l'injection peut provoquer

Selon l'OWASP : divulgation du prompt système ou de documents privés, réponse manipulée sur laquelle quelqu'un agit, appel d'outils non autorisé, sortie de données, et compromission durable quand l'instruction s'écrit dans une mémoire ou une base documentaire. La gravité dépend de ce que le système permet au modèle de faire.

Les parades, par ordre d'efficacité

L'OWASP demande de concevoir le système en partant du principe que la frontière des instructions sera franchie. Les mesures qui réduisent la probabilité d'une injection s'usent face à un attaquant qui s'adapte ; celles qui limitent les dégâts tiennent.

Ce qui limite les dégâts (à faire en premier) :

Garder les identifiants et les actions qui modifient quelque chose dans le code de l'application, pas dans le modèle, avec le moindre privilège pour chaque opération.
Exiger une confirmation humaine avant toute action privilégiée, irréversible ou visible de l'extérieur, en montrant l'action exacte.
Valider chaque réponse par du code (schéma de sortie strict) avant qu'un autre système ne s'en serve.
Appliquer la « règle de deux » citée par l'OWASP : un système qui cumule entrées non fiables, données sensibles et capacité d'agir ou de communiquer vers l'extérieur demande une validation humaine à chaque action.

Ce qui rend l'injection moins probable :

Cadrer le rôle du modèle dans le prompt système, avec des interdits explicites ; l'OWASP précise que c'est une protection partielle.
Faire passer les contenus externes par un canal séparé et étiqueté. La documentation d'Anthropic recommande de livrer les contenus tiers dans des résultats d'outil (tool_result), d'indiquer leur provenance, de les encoder en JSON et d'écrire dans le prompt système qu'ils sont des données non fiables.
Filtrer à chaque type de contenu (texte, image, audio) et supprimer les caractères invisibles à l'entrée comme à l'affichage.
Passer les entrées et les résultats d'outils par un petit modèle classificateur avant le modèle principal. Voir garde-fous d'entrée et de sortie.

Ce qui permet de savoir où vous en êtes :

Tester avec des attaquants qui connaissent vos défenses. L'OWASP cite une étude de 2025 où le taux de réussite des attaques fixes était proche de zéro, mais dépassait 90 % en attaque adaptative pour la plupart des douze défenses testées. Voir red teaming.

Ce que dit l'ANSSI

Le guide de l'ANSSI (Agence nationale de la sécurité des systèmes d'information) du 29/04/2024 cite l'injection indirecte parmi les risques des interactions avec d'autres applications, et recommande de filtrer les entrées et les sorties des utilisateurs (R25) et de limiter, voire de proscrire, les actions automatiques déclenchées à partir d'entrées non maîtrisées, comme des données d'Internet ou des mails (R27).

Pour l'injection dans un agent qui agit, la page agent IA et injection de prompt détaille la mise en pratique ; pour les outils branchés par MCP, voyez la sécurité d'un serveur MCP.