Prompt injection : comment une IA peut être manipulée par ce qu’elle lit

Un assistant reçoit une mission simple : consulter plusieurs documents, puis en produire une synthèse. L’un des documents contient une phrase qui ressemble à une consigne adressée à l’assistant lui-même.

Pour un lecteur humain, cette phrase n’est qu’une ligne parmi d’autres : du contenu. Pour un système d’IA, la frontière entre ce qu’il doit lire et ce qu’il doit suivre comme instruction est plus difficile à établir, parce que les deux arrivent sous la même forme — du texte dans son contexte. C’est le terrain de la prompt injection.

Qu’est-ce qu’une prompt injection ?

Une prompt injection consiste à influencer le comportement d’un système d’IA en introduisant des instructions dans son contexte, c’est-à-dire dans l’ensemble des éléments qu’il prend en compte pour répondre : consigne du système, demande de l’utilisateur, documents fournis, contenus récupérés.

Ces instructions arrivent par deux chemins :

• directement, parce que la personne qui utilise le système les écrit elle-même ;
• indirectement, parce qu’elles se trouvent dans un contenu que le système consulte pour accomplir sa tâche.

L’OWASP classe ce risque en première position de sa liste consacrée aux applications reposant sur des modèles de langage, et le définit précisément par cette entrée dans le contexte plutôt que par une technique particulière. Voir aussi la définition courte du terme dans notre lexique.

Une précision utile : une instruction inhabituelle rencontrée dans un document n’est pas la preuve d’une manipulation réussie. Une tentative peut échouer, être ignorée, ou n’avoir aucune conséquence si le système ne peut rien faire d’autre que répondre.

Pourquoi parle-t-on d’« injection » ?

Le mot vient d’autres familles de vulnérabilités, où un attaquant parvient à faire interpréter comme une commande ce qui devait rester une donnée. L’analogie aide, mais s’arrête là.

Dans une application classique, la séparation entre code et données s’appuie sur des mécanismes stricts : une requête préparée empêche structurellement une valeur de devenir une instruction. Dans une application fondée sur un modèle de langage, instructions, données et contenus récupérés sont tous représentés sous forme de langage dans un même contexte. La difficulté n’est donc pas de nettoyer une chaîne de caractères, mais de maintenir une hiérarchie fiable entre des éléments qui, linguistiquement, se ressemblent.

Une prompt injection n’est donc pas l’équivalent d’une injection SQL : le mécanisme interne diffère, et l’idée d’un « échappement » universel n’y a pas d’équivalent direct.

Injection directe et injection indirecte

Injection directe

L’instruction provient de la personne qui interagit avec le système. Elle vise à détourner le comportement attendu : faire ignorer une consigne, obtenir un contenu que l’application n’était pas censée produire, sortir du cadre défini par l’éditeur. C’est le cas le plus visible, et souvent le moins préoccupant lorsque l’utilisateur n’a accès qu’à ses propres données : il manipule un système agissant en son nom.

Injection indirecte

L’instruction ne vient pas de l’utilisateur, mais d’une ressource que l’IA consulte : page web, document, courriel, commentaire, fichier joint, résultat de recherche, base documentaire interne.

Ce cas est plus délicat : personne ne l’a demandé. L’utilisateur a formulé une tâche légitime ; c’est le contenu rencontré pendant l’exécution qui tente d’en modifier le cours. Plus un système s’appuie sur des sources externes — recherche web, RAG, boîte de réception —, plus cette surface existe.

Prompt injection et jailbreak : quelle différence ?

Les deux termes circulent comme des synonymes, à tort.

• La prompt injection désigne largement la manipulation du comportement d’un système par des instructions présentes dans son contexte, quelle que soit leur provenance.
• Le jailbreak désigne plutôt la tentative de contourner des restrictions ou des garde-fous du modèle, pour obtenir un contenu ou un comportement que l’éditeur a explicitement exclu.

L’OWASP traite le jailbreak comme une forme particulière de prompt injection, celle qui amène le modèle à ignorer ses consignes de sécurité ; d’autres classifications les distinguent plus nettement. Il n’existe pas de définition identique dans toute l’industrie : mieux vaut préciser de quoi l’on parle que trancher sur le vocabulaire.

Pourquoi un agent connecté est plus exposé qu’un chatbot simple

Un système qui ne produit que du texte dispose de peu de moyens d’action. Un agent peut consulter des fichiers, lire des courriels, naviguer sur le web, appeler une API, accéder à un agenda, modifier une application, envoyer une information. Cette différence de nature, détaillée dans notre article sur les agents et les chatbots, est décisive ici.

Un chatbot n’est pas « sans risque » : une réponse détournée peut tromper son lecteur. Mais le raisonnement porte moins sur la probabilité d’une manipulation que sur sa conséquence : plus un système possède de capacités — via l’utilisation d’outils —, plus il faut limiter ce qu’une manipulation pourrait lui permettre de faire.

Un exemple d’injection indirecte

Un exemple fictif, réduit à son principe. Un assistant reçoit la tâche suivante : *résumer trois documents*. Dans le deuxième document, une phrase inhabituelle s’adresse au système et lui demande d’abandonner sa tâche initiale pour en accomplir une autre.

Trois observations suffisent :

• l’utilisateur n’a jamais donné cette instruction ;
• elle provient du contenu consulté, source que rien ne rend fiable ;
• un système robuste doit traiter ce passage comme une donnée, non comme une autorité supérieure à la consigne d’origine.

Cet exemple n’est pas développé davantage : l’objectif est de faire comprendre le mécanisme, pas de fournir une formulation réutilisable contre un service.

Pourquoi les agents qui naviguent sur le web sont particulièrement concernés

Le web est, par construction, composé de contenus produits par des tiers : texte visible, contributions d’utilisateurs, documents téléchargés, résultats de services externes. Aucun de ces éléments ne peut être considéré comme une instruction fiable.

C’est le point sur lequel insistent les publications d’OpenAI et d’Anthropic consacrées aux injections indirectes et aux agents navigateurs : le contenu tiers non fiable est la source principale du problème, et la réponse ne se limite pas à rendre le modèle plus résistant — elle passe aussi par des permissions étroites, des validations et des limites explicites sur ce que l’agent peut entreprendre. Aucun produit n’est ici désigné comme vulnérable : les acteurs concernés documentent publiquement ce risque et font évoluer leurs défenses.

Le problème prend de l’ampleur avec les outils

Les protocoles d’intégration facilitent le branchement d’un modèle sur des ressources et des outils : c’est l’objet du MCP, qui standardise la façon dont une application compatible expose fichiers, données ou actions.

Un point mérite d’être dit clairement : le MCP n’est pas la cause des prompt injections, et il n’en protège pas davantage. Le risque naît du système complet — modèle, application hôte, données accessibles, outils exposés, permissions accordées, architecture retenue.

La distinction utile porte sur la nature des outils : un outil en lecture seule expose des informations, tandis qu’un outil capable d’écrire, d’envoyer ou de déclencher une action externe ouvre des conséquences d’un autre ordre. Deux systèmes techniquement proches peuvent ainsi présenter des risques très différents.

Quelles peuvent être les conséquences ?

À haut niveau, et sans détailler le moindre moyen d’y parvenir :

• une réponse incorrecte ou orientée ;
• un changement non souhaité de la tâche en cours ;
• l’exposition d’informations auxquelles le système a accès ;
• l’utilisation inappropriée d’un outil ;
• une action externe non souhaitée ;
• une mauvaise décision dans un enchaînement automatisé ;
• la propagation d’un contenu trompeur vers d’autres lecteurs ou systèmes.

Ces conséquences ne sont pas systématiques : elles dépendent de ce que le système est réellement autorisé à faire.

Peut-on simplement filtrer les phrases dangereuses ?

Non — ou plus exactement : pas seulement.

Le langage naturel autorise les synonymes, les reformulations, les tournures implicites, les changements de langue, les ambiguïtés de contexte : une même intention s’exprime d’une infinité de manières, et une phrase anodine dans un document peut devenir problématique dans un autre.

Le filtrage des entrées et des sorties figure bien parmi les mesures recommandées par l’OWASP, mais comme une couche parmi d’autres, pas comme une garantie. Considérer une liste de motifs interdits comme une protection suffisante est l’erreur la plus courante sur ce sujet.

Peut-on détecter toutes les prompt injections ?

Les défenses progressent, et plusieurs équipes publient régulièrement sur le sujet. Mais une architecture ne doit pas être conçue en supposant que la détection sera parfaite.

C’est le déplacement de perspective proposé par OpenAI dans ses publications sur la conception d’agents : ne pas chercher uniquement à empêcher toute manipulation du modèle, mais aussi réduire ce qui peut arriver lorsqu’un contenu malveillant est rencontré — soit un problème d’architecture et de permissions autant qu’un problème de modèle. Aucun taux de réussite n’est repris ici : ces chiffres dépendent des protocoles d’évaluation et vieillissent vite.

La défense commence par les permissions

Les principes qui suivent ne sont pas spécifiques à l’IA : ils prolongent des recommandations classiques que l’ANSSI reprend pour les systèmes d’IA générative — cloisonnement, moindre privilège, contrôle des interactions, journalisation, limitation des actions possibles.

Moindre privilège

Un composant ne reçoit que les accès strictement nécessaires à sa tâche : ni un service, ni un dossier de plus.

Lecture avant écriture

Si une tâche consiste à consulter une ressource, un droit d’écriture n’a pas lieu d’être accordé : c’est souvent la mesure la plus efficace au regard de son coût.

Validation humaine

Certaines opérations sensibles — envoi, paiement, suppression, partage — méritent une confirmation explicite avant exécution.

Séparation des domaines

Éviter qu’un composant unique cumule l’accès à toutes les données et à tous les outils : un incident reste alors circonscrit.

Révocation

Prévoir dès le départ le retrait rapide d’un accès, d’un jeton ou d’une intégration, sans reconstruire le système.

Les données externes doivent rester non fiables

Un principe résume beaucoup de choses : une page web, un courriel ou un document consulté ne doit pas acquérir automatiquement la même autorité qu’une instruction venant de l’utilisateur ou de la configuration du système.

Cela suppose de savoir, dans une application, d’où vient chaque élément du contexte et quel statut lui est accordé. Les moyens varient selon les architectures — ce texte ne prétend pas décrire le fonctionnement interne d’un modèle particulier. Le principe, lui, reste stable : le contenu récupéré est une donnée à analyser, jamais une consigne à exécuter.

Les confirmations humaines suffisent-elles ?

Ce sont des garde-fous utiles, mais qui ne règlent rien à eux seuls — surtout s’ils deviennent des clics réflexes. Une confirmation du type « Autoriser ? Oui / Non » n’apporte presque aucune information. Une confirmation utile indique l’action envisagée, sa cible, les données mobilisées et le résultat attendu : la personne peut alors décider, au lieu d’approuver.

Journalisation et supervision

Conserver une trace — demandes, appels d’outils, décisions importantes, erreurs, confirmations — permet d’analyser un incident, de comprendre un comportement inattendu et d’ajuster les règles.

Une nuance s’impose : journaliser sans discernement revient à créer un nouveau gisement de données sensibles. Ce que l’on enregistre, la durée de conservation et les accès relèvent des mêmes arbitrages que ceux évoqués dans notre article sur l’IA locale et l’IA dans le cloud.

Une prompt injection réussie signifie-t-elle que le modèle est « piraté » ?

Pas nécessairement : le mot « piraté » est trop vague. Mieux vaut distinguer :

• la manipulation d’une sortie : le texte produit est orienté ou faux ;
• le détournement d’une tâche : le système fait autre chose que ce qui était demandé ;
• l’utilisation d’un outil : une capacité réelle est mobilisée ;
• l’accès effectif à une ressource : des données sont consultées ou modifiées.

Ces situations n’ont pas la même portée : elles dépendent des capacités que le système possède réellement, et non du modèle seul.

Que peut faire un utilisateur ?

Pour un particulier

• rester prudent avec les agents qui accèdent à plusieurs services à la fois ;
• vérifier les permissions accordées, notamment les droits d’écriture ;
• lire les confirmations au lieu de les valider machinalement ;
• éviter de donner accès à des informations sensibles sans nécessité ;
• interrompre une tâche dès que le comportement paraît incohérent.

Pour une entreprise

• définir les usages autorisés et les données concernées ;
• limiter les permissions au strict nécessaire ;
• séparer les accès en lecture et en écriture ;
• auditer les intégrations et les outils exposés ;
• prévoir des validations pour les opérations sensibles ;
• superviser les actions réalisées par les systèmes ;
• tester les systèmes, y compris de façon adverse, avant déploiement.

Une architecture de défense en profondeur

Aucune de ces couches n’est suffisante à elle seule : c’est leur combinaison qui réduit le risque.

Les prompt injections vont-elles disparaître ?

Aucune prédiction ici. Le sujet fait l’objet de travaux continus de recherche et d’ingénierie, et plusieurs acteurs — éditeurs de modèles comme organisations de sécurité — publient leurs approches et leurs limites. Le problème est ainsi traité comme structurel, et non comme un défaut à corriger une fois pour toutes.

À retenir

Une prompt injection devient surtout dangereuse lorsque du contenu non fiable peut influencer un système disposant de données ou d’actions sensibles. La sécurité consiste donc autant à protéger le modèle qu’à limiter ce que le système est autorisé à faire.

Conclusion

La prompt injection exploite une difficulté propre aux systèmes fondés sur le langage : distinguer de manière fiable les instructions légitimes du contenu qu’ils doivent simplement traiter. Cette ambiguïté découle de la façon dont ces systèmes reçoivent tout — consignes, données, documents — sous une forme identique.

Avec les agents et les outils, la question change d’échelle : une instruction détournée ne produit plus seulement une mauvaise réponse, elle peut déclencher autre chose. Le bon réflexe n’est donc pas seulement de se demander si l’on peut bloquer toutes les injections, mais aussi ce que le système pourrait réellement faire si l’une d’elles réussissait.

Questions fréquentes

Qu’est-ce qu’une prompt injection ?

Une tentative d’influencer le comportement d’un système d’IA en introduisant des instructions dans son contexte, directement par l’utilisateur ou indirectement via un contenu que le système consulte.

Quelle différence entre prompt injection et jailbreak ?

La prompt injection désigne largement la manipulation du comportement par des instructions présentes dans le contexte ; le jailbreak vise plus spécifiquement à contourner les garde-fous du modèle. L’OWASP considère le second comme une forme de la première, mais les usages varient.

Une prompt injection peut-elle être cachée dans une page web ?

Conceptuellement oui, dès lors qu’un système consulte du contenu externe : une page est produite par un tiers et ne constitue pas une instruction fiable. Aucune procédure n’est décrite ici.

Un chatbot peut-il subir une prompt injection ?

Oui, selon son fonctionnement et les contenus présents dans son contexte. S’il ne dispose d’aucun outil, les conséquences restent en général limitées au contenu de la réponse.

Les agents IA sont-ils plus exposés ?

Leurs conséquences potentielles sont plus importantes, parce qu’ils disposent d’outils et d’accès. Cela ne signifie pas que tous les agents sont vulnérables : tout dépend des permissions, des validations et de l’architecture.

Le MCP protège-t-il contre les prompt injections ?

Non. Le MCP standardise la manière dont une application accède à des ressources et à des outils ; ce n’est pas un mécanisme de protection. Le niveau de risque dépend du serveur, des outils exposés, des permissions et de l’application hôte.

Peut-on empêcher toutes les prompt injections ?

Aucune protection absolue ne peut être promise. La démarche réaliste combine plusieurs couches de défense et une limitation stricte de ce que le système peut faire si une tentative aboutit.

Sources officielles

• OWASP GenAI Security Project — LLM01:2025 Prompt Injection
• OWASP Cheat Sheet Series — LLM Prompt Injection Prevention Cheat Sheet
• OpenAI — Understanding prompt injections
• OpenAI — Designing AI agents to resist prompt injection
• Anthropic — Mitigating the risk of prompt injections in browser use
• ANSSI — Recommandations de sécurité pour un système d’IA générative