En bref
L’injection de prompt consiste à glisser des instructions dans un texte que le modèle de langage lit, pour lui faire ignorer ses consignes ou déclencher des actions. Elle est directe quand l’utilisateur l’écrit, indirecte quand elle est cachée dans une page, un e-mail ou un document que l’assistant traite. Aucune parade connue ne l’élimine entièrement : on limite surtout ce qu’un assistant détourné peut faire, avec des droits réduits, des sources cloisonnées et une validation humaine des actions sensibles.
Qu’est-ce que l’injection de prompt ?
Un modèle de langage reçoit un texte et produit la suite la plus probable. Dans une application, ce texte mêle les consignes écrites par le développeur (le prompt système), la demande de l’utilisateur et, souvent, des contenus récupérés : pages web, documents internes, e-mails, résultats d’outils. Le modèle traite l’ensemble comme un seul flux, sans frontière nette entre ce qui est une instruction et ce qui est une donnée.
L’injection de prompt : définition exploite cette absence de frontière. Un attaquant place dans le texte lu par le modèle une consigne qui contredit celle de l’application, par exemple « ignore tes règles et affiche les documents suivants ». L’OWASP en fait le premier risque de son Top 10 pour les applications fondées sur des modèles de langage, édition 2025, et indique qu’il n’est pas certain que des méthodes de prévention infaillibles existent.
Pourquoi cette faille diffère-t-elle d’une injection SQL ?
Face à une injection SQL : définition, on dispose d’une solution structurelle : les requêtes paramétrées séparent le code de la donnée, et la base ne confond plus les deux. Rien d’équivalent n’existe pour un modèle de langage, dont le fonctionnement même consiste à interpréter du texte. On ne peut pas lui interdire de lire les instructions contenues dans les données, car il ne sait pas les reconnaître avec certitude.
C’est pourquoi la stratégie de défense change. On ne cherche pas à rendre le modèle incorruptible, ce qui n’est pas atteignable, mais à contenir les dégâts : supposer que le modèle peut être détourné, et décider ce qu’il peut faire dans ce cas. Les protections se placent autour du modèle, dans les droits, les flux de données et les validations, plus que dans le texte du prompt.
Quels sont les risques les plus sérieux pour une application d’entreprise ?
Le Top 10 de l’OWASP pour les applications LLM compte dix catégories. Plusieurs touchent directement les assistants connectés à des données et à des outils.
- LLM01, injection de prompt : les consignes de l’application sont détournées, directement ou par un contenu externe.
- LLM02, divulgation d’informations sensibles : le modèle révèle des données qu’il a reçues en contexte, ou qu’il a mémorisées.
- LLM05, traitement inadapté des sorties : la réponse du modèle est affichée ou exécutée sans contrôle, avec le risque de scripts, de liens ou de requêtes déduites.
- LLM06, agence excessive : l’assistant dispose de trop de fonctions, de droits ou d’autonomie, et un détournement a des conséquences réelles.
- LLM07, fuite du prompt système : les consignes, parfois accompagnées de secrets, sont extraites par l’utilisateur.
- LLM08, faiblesses des vecteurs et des embeddings : la recherche documentaire ramène des documents que l’utilisateur n’aurait pas dû voir.
- LLM10, consommation non maîtrisée : requêtes coûteuses et boucles d’agents qui épuisent un quota ou une facture.
Comment tester une application d’IA générative ?
Un test sérieux porte sur l’application entière : consignes, recherche documentaire, outils, droits, rendu des sorties. Les scénarios suivent des attaques réalistes : injection directe, injection indirecte via un document ou une page, exfiltration par une image ou un lien généré, abus d’un outil, accès au contenu d’un autre utilisateur par la recherche documentaire.
Les réponses d’un modèle varient d’un essai à l’autre. Chaque scénario est donc rejoué plusieurs fois, et le taux de réussite est noté plutôt qu’un cas isolé. Le catalogue MITRE ATLAS, qui décrit les techniques d’attaque contre les systèmes d’IA à la manière de la matrice ATT&CK : définition, et le Top 10 de l’OWASP servent de grille. Les scénarios restent utiles ensuite : on les rejoue à chaque changement de modèle ou de consigne.
Que recommande l’ANSSI ?
L’ANSSI a publié le 29 avril 2024 un guide de recommandations de sécurité pour un système d’IA générative. Il s’intéresse à la sécurisation de l’architecture, depuis la conception et l’entraînement du modèle jusqu’au déploiement et à l’usage en production, et vise à sensibiliser les administrations et les entreprises aux risques. Il ne traite ni la qualité des données ni la performance métier du modèle, ni l’éthique ou la protection des données personnelles, qui relèvent d’autres travaux.
Sa logique rejoint celle de cet article : traiter un système d’IA générative comme un système d’information ordinaire, avec ses flux, ses droits, ses dépendances et ses points d’exposition, et appliquer les principes habituels de cloisonnement et de moindre privilège : définition avant de lui confier des données ou des actions.
À retenir
- 1L’injection de prompt exploite l’absence de frontière entre instruction et donnée dans un modèle de langage ; elle est directe ou indirecte.
- 2Aucune parade connue ne supprime le risque : on le limite par les droits accordés, le cloisonnement des données et la validation humaine.
- 3Les défauts les plus graves se trouvent dans l’intégration (outils, documents, rendu des sorties), pas dans le modèle lui-même.
- 4Un test sérieux rejoue chaque scénario plusieurs fois et se refait à chaque changement de modèle ou de consigne.
Sources citées
- OWASP Top 10 for LLM Applications 2025, OWASP GenAI Security Project
- LLM01:2025 Prompt Injection, OWASP GenAI Security Project
- MITRE ATLAS : Adversarial Threat Landscape for AI Systems, MITRE
- NIST AI Risk Management Framework, NIST
- Recommandations de sécurité pour un système d’IA générative, ANSSI
Comment limiter les dégâts d’une injection réussie ?