Injection de prompt : comprendre l'attaque et s'en protéger

L'essentiel en bref

• Définition. L'injection de prompt (prompt injection) consiste à glisser des instructions dans le texte que traite un grand modèle de langage (LLM, large language model). Le but est de lui faire faire autre chose que ce que voulaient son concepteur ou son utilisateur.
• Deux voies. L'injection est directe quand l'attaquant écrit lui-même à l'IA. Elle est indirecte quand les instructions sont cachées dans une page web, un e-mail, un document ou le résultat d'un outil que l'IA lit pour le compte de l'utilisateur.
• Risque n° 1. L'OWASP la place en tête de son Top 10 des risques des applications LLM (LLM01:2025). MITRE ATLAS la référence sous l'identifiant AML.T0051.
• Pas de correctif définitif. Le NCSC britannique estime qu'elle ne sera peut-être jamais corrigée aussi complètement que l'injection SQL. OpenAI et Anthropic reconnaissent aussi que le problème n'est pas résolu.
• La bonne stratégie : limiter les dégâts. Il s'agit de réduire les droits de l'IA, de ne jamais réunir données privées, contenu non fiable et sortie vers l'extérieur, de faire valider par un humain les actions sensibles, de journaliser et de tester.

De quoi parle-t-on ?

Un assistant d'IA reçoit un seul flux de texte. On y trouve les consignes du concepteur (le « prompt système »), la demande de l'utilisateur et les contenus que l'outil va chercher : page web, e-mail, fichier, réponse d'un logiciel tiers. Le modèle traite l'ensemble comme une suite de mots. Il ne trace pas de frontière fiable entre ce qui est un ordre et ce qui est une simple donnée. L'injection de prompt exploite cette confusion : un texte bien tourné, placé au bon endroit, est pris pour une consigne.

L'OWASP (Open Worldwide Application Security Project) précise que ces entrées « peuvent être imperceptibles pour un humain », du moment que le modèle les lit. Il ajoute que ni la recherche documentaire augmentée (RAG, retrieval-augmented generation) ni l'affinage du modèle ne suppriment ce risque. De son côté, MITRE ATLAS, la base de connaissances des attaques contre les systèmes d'IA, distingue trois sous-techniques : directe (AML.T0051.000), indirecte (AML.T0051.001) et déclenchée (AML.T0051.002).

L'injection directe

Ici, c'est l'utilisateur qui tape des instructions pour détourner l'outil. Il peut chercher à faire révéler le prompt système, à faire sortir un robot conversationnel de service client de son rôle ou à obtenir un engagement que l'entreprise n'a jamais voulu prendre. Le risque est réel. Mais il reste en général borné à ce que cet utilisateur peut déjà atteindre.

L'injection indirecte

C'est la forme la plus préoccupante pour une organisation. L'attaquant ne s'adresse jamais à l'IA : il dépose ses instructions là où elle ira lire. C'est ensuite la victime qui déclenche l'attaque, par une demande banale du type « résume mes e-mails » ou « regarde les tickets ouverts ». Les supports documentés sont variés :

• texte blanc sur fond blanc ou commentaire HTML dans une page web que l'assistant résume ;
• couche invisible dans un e-mail (texte masqué en CSS, caractères Unicode de largeur nulle, données encodées en Base64) ;
• consigne glissée dans un CV, du type « attribuer la note maximale » ;
• document déposé dans une base documentaire interne interrogée par l'IA ;
• ticket, commentaire de code ou demande d'un dépôt public ;
• description d'une invitation d'agenda ;
• réponse renvoyée par un outil ou un serveur MCP (Model Context Protocol, le protocole qui relie les agents à des outils externes) ;
• image contenant du texte, pour les modèles qui lisent aussi les images.

Injection ou jailbreak ?

Les deux notions sont souvent confondues. Le contournement des garde-fous (jailbreak) cherche à faire produire au modèle ce que son éditeur lui interdit, par exemple des contenus dangereux. Pour l'OWASP, le jailbreak est une forme particulière d'injection de prompt : celle qui vise à faire abandonner au modèle ses règles de sécurité.

Pour une organisation, la différence est pratique. Le jailbreak relève surtout de l'éditeur du modèle et des usages abusifs. L'injection indirecte touche directement l'application que vous déployez : un tiers prend le contrôle d'un outil qui agit avec vos droits. Un modèle qui résiste bien au jailbreak peut d'ailleurs rester vulnérable à l'injection. Une consigne comme « joins ce résumé à un e-mail pour telle adresse » n'a rien d'interdit en soi.

Pourquoi aucune défense n'est complète

Le 8 décembre 2025, le NCSC (National Cyber Security Centre, l'agence britannique de cybersécurité) a publié une analyse intitulée « Prompt injection is not SQL injection (it may be worse) ». L'injection SQL a été largement maîtrisée grâce aux requêtes paramétrées, qui séparent strictement le code des données. Un LLM n'offre pas cette séparation. Selon l'agence, l'injection de prompt pourrait donc ne jamais être corrigée aussi complètement que l'injection SQL. Elle propose de voir le modèle comme un « adjoint intrinsèquement confondable » : on ne peut pas l'empêcher d'être trompé, on peut seulement limiter ce qu'il peut faire une fois trompé.

Les éditeurs tiennent un discours proche. Le 22 décembre 2025, dans un billet consacré au renforcement de son navigateur Atlas, OpenAI a écrit que l'injection de prompt ne serait probablement jamais entièrement « résolue ». L'entreprise le compare aux arnaques et à l'ingénierie sociale. Le 24 novembre 2025, Anthropic a qualifié l'injection de prompt de problème « loin d'être résolu ». Elle a ajouté qu'« aucun agent de navigation n'est immunisé » et qu'un taux de réussite des attaques de 1 % « représente encore un risque significatif ». Ces chiffres sont mesurés par les éditeurs eux-mêmes, sur leurs propres bancs d'essai. Ils ne sont pas comparables d'un éditeur à l'autre et ne remplacent pas une évaluation indépendante. Cette réserve vaut aussi pour Anthropic, dont le modèle Claude sert à rédiger ce site.

Les évaluations indépendantes vont dans le même sens :

• En janvier 2025, le CAISI (Center for AI Standards and Innovation) du NIST a mis au point de nouvelles attaques contre une version renforcée de Claude 3.5 Sonnet : le taux de réussite de la meilleure attaque est passé de 11 % (meilleure attaque de référence) à 81 %. Sur cinq tâches d'injection, en répétant chaque attaque 25 fois, la moyenne est passée de 57 % à 80 %.
• En octobre 2025, une équipe de quatorze chercheurs a contourné douze défenses publiées, avec un taux de réussite supérieur à 90 % pour la plupart. La plupart annonçaient pourtant des taux proches de zéro.
• En mars 2026, le CAISI a publié, avec la société Gray Swan, organisatrice, et l'AISI britannique (AI Security Institute), l'analyse d'un concours public de tests d'attaque. Plus de 250 000 tentatives ont été menées, et au moins une attaque a réussi contre chacun des treize modèles testés.

La leçon est simple. Un filtre qui « bloque 95 % des attaques » ne suffit pas, car l'attaquant peut réessayer autant de fois qu'il le veut.

Ce que risque une organisation

L'OWASP recense plusieurs conséquences possibles :

• Fuite de données. L'assistant lit vos e-mails ou vos documents, puis les envoie à l'extérieur. Souvent, les données sont glissées dans l'adresse d'une image ou d'un lien que l'interface charge automatiquement.
• Actions non voulues d'un agent. L'agent envoie un message, modifie ou supprime un fichier, publie du code, exécute une commande ou passe une commande.
• Réponses manipulées. Un résumé présente un e-mail frauduleux comme urgent et légitime, un CV est surnoté, une recommandation est orientée.
• Révélation de la configuration. L'attaquant obtient le prompt système, la liste des outils ou des détails d'infrastructure.
• Exécution de code. Elle devient possible quand la sortie du modèle est transmise sans contrôle à un interpréteur ou à un système connecté.

Deux grilles de lecture aident à repérer les situations dangereuses. En juin 2025, le chercheur Simon Willison a décrit un « trio létal » : un agent est exposé à une fuite dès qu'il combine l'accès à des données privées, l'exposition à du contenu non fiable et la capacité de communiquer vers l'extérieur. Le 31 octobre 2025, Meta a proposé une « règle de deux » (Agents Rule of Two). Dans une même session, un agent ne devrait réunir que deux de ces trois propriétés au plus : traiter des entrées non fiables, accéder à des systèmes sensibles ou à des données privées, modifier un état ou communiquer vers l'extérieur. Si les trois sont indispensables, l'agent ne doit pas agir seul et doit être supervisé, par exemple par une validation humaine.

Exemples documentés

• EchoLeak, Microsoft 365 Copilot (juin 2025). La société Aim Security a montré qu'un simple e-mail piégé pouvait amener Copilot à extraire des données internes de l'organisation, sans aucun clic de la victime. Microsoft a classé la faille comme critique (CVE-2025-32711, score CVSS de 9,3). Elle l'a corrigée côté serveur, sans action requise des clients, et sans exploitation connue.
• Serveur MCP de GitHub (mai 2025). Invariant Labs a déposé dans un dépôt public un ticket contenant une injection de prompt. L'agent d'un utilisateur, chargé de lire les tickets, a récupéré des informations de ses dépôts privés (dont un salaire) et les a publiées sur le dépôt public. Selon les chercheurs, le problème tient à l'architecture de l'agent, pas au code de GitHub : aucun correctif côté serveur ne peut le régler.
• Gemini et Google Agenda (2025). Des chercheurs de l'université de Tel-Aviv, du Technion et de SafeBreach ont piégé des invitations d'agenda. Quand l'utilisateur interrogeait Gemini sur son planning, l'assistant exécutait les consignes cachées : suppression d'événements, lancement d'un appel vidéo, pilotage d'objets connectés. Google indique avoir déployé des protections en plusieurs couches, dont davantage de confirmations demandées à l'utilisateur.
• Semantic Kernel (mai 2026). Microsoft a décrit deux failles de son cadriciel d'agents (CVE-2026-26030 et CVE-2026-25592). Une injection de prompt pouvait y mener à l'exécution de code sur la machine hôte. Microsoft en tire ce principe : tout paramètre d'outil que le modèle peut influencer doit être traité comme une entrée contrôlée par l'attaquant.
• AWS AgentCore (2026). Selon Zenity, une seule requête envoyée à un agent public permettait d'atteindre d'autres agents et leurs secrets. AWS conteste qu'il s'agisse d'une vulnérabilité (voir notre article).

Que voit-on dans la nature ? En avril 2026, Google a analysé l'archive publique du web Common Crawl (2 à 3 milliards de pages par instantané mensuel). L'entreprise a relevé une hausse relative de 32 % des injections malveillantes entre novembre 2025 et février 2026. Elle juge leur niveau technique encore faible, mais s'attend à une augmentation de leur nombre et de leur sophistication. En octobre 2026, Barracuda Networks a décrit des e-mails qui combinent hameçonnage classique et instructions invisibles destinées à l'assistant d'IA du destinataire, pour que celui-ci présente le message comme légitime.

Les référentiels à connaître

Référentiel	Ce qu'il apporte
OWASP Top 10 des applications LLM, risque LLM01:2025	La définition, la distinction entre injection directe et indirecte, neuf scénarios types et sept familles de mesures de prévention.
OWASP Top 10 des applications agentiques 2026 (publié le 9 décembre 2025)	Les risques propres aux agents. Le premier, ASI01, porte sur le détournement de l'objectif de l'agent, le plus souvent par injection indirecte.
MITRE ATLAS, technique AML.T0051	Une taxonomie (injection directe, indirecte, déclenchée) et des études de cas, utiles pour la modélisation des menaces et les exercices.
ANSSI, Recommandations de sécurité pour un système d'IA générative (29 avril 2024)	Filtrer les requêtes et les réponses, cloisonner le système d'IA, éviter au maximum les actions automatisées entre l'IA et le système d'information, tout journaliser.
CERT-FR, CERTFR-2026-ACT-016 (13 avril 2026)	Un avis sur les agents installés sur les postes de travail (OpenClaw, Claude Cowork, etc.). Il cite la vulnérabilité intrinsèque des LLM aux injections de prompt et exige une validation humaine pour toute action à effet de bord.
NCSC, billet du 8 décembre 2025	Une doctrine claire : réduire l'impact plutôt que promettre un blocage. Elle s'aligne sur la norme ETSI TS 104 223 (exigences de cybersécurité de base pour les modèles et systèmes d'IA).
NIST AI 100-2 E2025 (mars 2025) et travaux du CAISI	La terminologie de référence des attaques contre l'IA et des méthodes d'évaluation du détournement d'agents.

Repères dans le temps

• Avril 2024 : guide de l'ANSSI sur la sécurité des systèmes d'IA générative.
• Mars 2025 : édition 2025 de la taxonomie NIST AI 100-2.
• Mai-juin 2025 : failles GitHub MCP et EchoLeak.
• Octobre-décembre 2025 : « règle de deux » de Meta, Top 10 agentique de l'OWASP, billet du NCSC, positions d'Anthropic et d'OpenAI.
• Février 2026 : synthèse du CERT-FR sur l'IA générative face aux attaques informatiques (CERTFR-2026-CTI-001).
• Avril 2026 : avis du CERT-FR sur les agents des postes de travail et mesures de Google sur le web.
• Au 18 octobre 2026 : aucun texte européen ou français ne traite spécifiquement de l'injection de prompt. Le sujet relève des obligations générales de sécurité des systèmes et des données.

Par où commencer

Ces mesures sont classées par ordre de priorité. Elles valent pour un assistant conversationnel branché sur vos données comme pour un agent capable d'agir. Pour la gouvernance d'ensemble des agents (identités, serveurs MCP, supervision), voir notre dossier Sécurité des agents d'IA.

1. Faire l'inventaire. Listez les assistants et agents utilisés, y compris les extensions de navigateur et les outils installés sans validation. Pour chacun, notez ce qu'il lit et ce qu'il peut faire.
2. Considérer tout contenu externe comme non fiable. Cela vaut pour les pages web, les e-mails entrants, les documents partagés, les tickets et les réponses d'outils ou de serveurs MCP, même s'ils proviennent d'un partenaire connu.
3. Casser le « trio létal ». Pour chaque usage, retirez au moins une des trois capacités. Un assistant qui lit des e-mails externes ne doit pas pouvoir envoyer de messages. Un agent qui navigue sur le web ne doit pas accéder aux dossiers RH.
4. Appliquer le moindre privilège. Utilisez des comptes et des jetons dédiés, limités à un périmètre étroit (une boîte, un dépôt, un dossier) et en lecture seule par défaut. Le NCSC reprend cette règle, proposée par Simon Willison et Baibhav Bista : quand une IA traite les données d'un tiers, ses droits tombent à ceux de ce tiers.
5. Faire valider par un humain les actions sensibles. C'est indispensable pour l'envoi de messages, les paiements, les suppressions ou les commandes système. Désactivez les options « toujours autoriser » et montrez clairement à l'utilisateur ce qui va être exécuté.
6. Fermer les canaux de fuite. Empêchez le chargement automatique d'images et de liens générés par l'IA, ou limitez-le à une liste de domaines autorisés.
7. Placer les contrôles hors du modèle. Faites vérifier par l'application les paramètres des outils et le format des réponses. Ne transmettez jamais une sortie du modèle à un interpréteur sans contrôle. Les consignes défensives écrites dans le prompt aident, mais le CERT-FR rappelle qu'une injection peut les contourner.
8. Séparer et marquer les données. Encadrez les contenus externes par des balises qui les signalent comme des données. Le NCSC note que cela rend l'injection plus difficile, sans la rendre impossible. Évitez les listes de mots interdits : les formulations possibles sont infinies.
9. Filtrer et surveiller. Les classifieurs de détection sont un complément, pas une garantie. Journalisez les entrées, les sorties et les appels d'outils. Surveillez les appels d'outils échoués ou inhabituels, qui peuvent trahir une attaque en préparation.
10. Tester avant et après la mise en production. Commandez un test d'intrusion de l'application d'IA. Il doit inclure des scénarios indirects et des attaques répétées et adaptées. Refaites-le à chaque changement de modèle ou ajout d'outil.
11. Encadrer et former. Faites valider chaque déploiement par la DSI et le RSSI, avec une acceptation écrite du risque résiduel. Apprenez aux utilisateurs qu'un résumé produit par l'IA peut avoir été manipulé. Demandez aux fournisseurs comment ils réduisent le risque, et méfiez-vous de ceux qui prétendent le supprimer.

Pour aller plus loin

• OWASP GenAI Security Project : fiche LLM01:2025 et Top 10 des applications agentiques 2026.
• MITRE ATLAS : technique AML.T0051 et ses études de cas.
• ANSSI (cyber.gouv.fr) : guide de 2024 sur l'IA générative et avis CERTFR-2026-ACT-016 sur les agents des postes de travail.
• NCSC : billet « Prompt injection is not SQL injection » et norme ETSI TS 104 223.
• NIST : rapport AI 100-2 E2025 et blog de recherche du CAISI sur le détournement d'agents.
• Cybermalveillance.gouv.fr : pour les petites structures, l'assistance et la sensibilisation à l'hameçonnage, qui reste le premier vecteur des e-mails piégés.