En juin 2025, un simple email suffisait à vider silencieusement le contexte de Microsoft 365 Copilot (emails, fichiers OneDrive, conversations Teams) sans qu’aucun collaborateur n’ait cliqué sur quoi que ce soit. Cette vulnérabilité CVE-2025-32711, baptisée EchoLeak, illustre mieux qu’aucune démonstration théorique pourquoi le prompt injection occupe la première place du classement OWASP des vulnérabilités applicatives LLM, pour la deuxième édition consécutive : ce n’est pas un risque hypothétique, mais un vecteur d’attaque déjà exploité contre des systèmes de production chez Microsoft, Google, GitHub et OpenAI entre 2025 et 2026.
Prompt injection et sécurité de l’IA : un défaut structurel
Le prompt injection exploite une limite architecturale des grands modèles de langage : un LLM reçoit les instructions système et les données fournies par l’utilisateur ou récupérées d’une source externe comme un seul et même flux de texte, sans moyen fiable de distinguer structurellement les deux. Un attaquant qui parvient à formuler une donnée comme si elle était une instruction peut donc détourner le modèle de son objectif initial, c’est le mécanisme unique qui sous-tend l’ensemble des variantes de cette attaque.
Types de prompt injection : direct, indirect et stocké
Prompt injection direct
Le prompt injection direct survient lorsqu’un attaquant saisit lui-même des instructions malveillantes dans le prompt, typiquement pour contourner les garde-fous d’un chatbot, c’est la variante la plus documentée, mais aussi la plus facile à limiter puisqu’elle suppose une interaction directe et traçable avec le système.
Prompt injection indirect
Le prompt injection indirect est aujourd’hui la catégorie la plus conséquente et la plus difficile à contenir : l’attaquant dissimule ses instructions dans un contenu que l’IA consulte de sa propre initiative (un e-mail, une page web, un document partagé) sans jamais interagir lui-même avec le système ciblé. C’est précisément le mécanisme d’EchoLeak : un e-mail contenant une instruction cachée, invisible pour l’utilisateur mais lue et exécutée par le moteur RAG de Copilot au moment où celui-ci résumait l’actualité de la boîte de réception.
Prompt injection stocké
Le prompt injection stocké ajoute une dimension de latence : l’instruction malveillante est déposée dans une mémoire longue durée, une base documentaire indexée ou une base de connaissances, et n’est activée que plus tard, lorsqu’un utilisateur légitime interroge cette source, ce qui rend la recherche de l’origine de l’attaque nettement plus complexe a posteriori.
EchoLeak : un cas réel de vulnérabilité par prompt injection
Le cas EchoLeak (CVE-2025-32711, sévérité critique CVSS 9.3) mérite d’être détaillé car il illustre avec précision comment cette vulnérabilité théorique se traduit en risque concret. Des chercheurs d’Aim Security ont démontré qu’un email spécialement conçu, contenant une instruction dissimulée en texte blanc sur fond blanc ou en commentaire HTML invisible, suffisait à déclencher l’exfiltration de données sensibles vers un serveur contrôlé par l’attaquant, sans le moindre clic de la victime. Une fois le contenu de l’email récupéré par le moteur RAG de Copilot en réponse à une requête anodine de l’utilisateur, l’instruction cachée était exécutée comme si elle provenait d’une source légitime.
L’analyse technique publiée ultérieurement a montré que l’attaque enchaînait quatre contournements distincts pour atteindre son objectif : elle évitait le classificateur anti-injection propre à Microsoft, contournait la neutralisation des liens, et exploitait un proxy d’images autorisé pour finaliser l’exfiltration. Microsoft a corrigé la vulnérabilité côté serveur en juin 2025, sans qu’aucune exploitation réelle n’ait été confirmée avant la publication. Le correctif a refermé ce cas précis ; la classe de risque qu’il illustre : un assistant IA disposant d’un accès large à des données internes, capable de traiter du contenu non fiable comme s’il s’agissait d’instructions légitimes, reste ouverte pour tout assistant IA construit sur une architecture comparable.
Protection contre le prompt injection : pourquoi aucune défense n’est définitive
C’est le point le plus honnête à poser dans ce guide, quitte à décevoir qui cherche une solution unique : chaque mesure d’atténuation aujourd’hui disponible réduit la probabilité de succès d’une attaque, aucune ne l’élimine. Le cloisonnement des délimiteurs, qui consiste à marquer explicitement les frontières entre instructions système et contenu externe, aide le modèle à mieux distinguer les deux sans jamais garantir cette distinction dans tous les cas. Le rappel de l’instruction d’origine en fin de prompt, technique parfois appelée défense sandwich, renforce l’intention initiale de l’utilisateur sans empêcher un contenu suffisamment habile de la contourner. L’entraînement spécifique du modèle à résister à ces techniques réduit la surface d’attaque generale, au prix d’un réentraînement coûteux et sans garantie face à des variantes encore inconnues au moment de l’entraînement.
Cette réalité a une conséquence directe sur la posture à adopter : la défense contre le prompt injection ne devrait jamais reposer sur une seule mesure, aussi sophistiquée soit-elle, mais sur une réduction systématique de l’impact potentiel, au premier rang desquelles la limitation stricte de ce à quoi un agent ou un assistant IA peut accéder, indépendamment de sa capacité à résister à l’injection elle-même.
Comment réduire les risques de prompt injection ?
- Cloisonner les accès en amont : un assistant qui n’a accès qu’aux données strictement nécessaires à sa tâche limite mécaniquement ce qu’une injection réussie peut exposer, même en cas de contournement des défenses du modèle.
- Traiter tout contenu externe comme non fiable : e-mails, pages web, documents partagés doivent être considérés comme des données potentiellement hostiles avant d’être injectés dans le contexte d’un système IA, au même titre qu’une entrée utilisateur non validée dans une application classique.
- Journaliser et classer les interactions : pouvoir distinguer a posteriori une injection directe, indirecte ou stockée dans les journaux d’interaction conditionne la capacité à corriger la faille exploitée plutôt qu’à colmater un symptôme isolé.
- Tester activement plutôt que présumer la protection acquise : un test d’intrusion spécifiquement calibré sur les scénarios d’injection, direct comme indirect, reste le seul moyen de vérifier qu’une mesure de protection annoncée résiste réellement à une tentative de contournement.
→ Voir notre guide des architectures et vecteurs de risques IA pour resituer ce vecteur parmi les autres briques d’une architecture IA, et notre offre de pentest IA pour tester la résistance réelle de vos systèmes face à ces scénarios.
FAQ : prompt injection et la sécurité de l’IA
Le prompt injection touche-t-il uniquement les chatbots conversationnels ?
Une entreprise qui utilise uniquement des outils IA grand public est-elle exposée ?
Existe-t-il une différence de risque entre prompt injection et jailbreak ?
Tester la résistance de vos systèmes IA au prompt injection
Nos experts évaluent l’exposition réelle de vos systèmes IA à ce vecteur et testent activement leur résistance dans le cadre de notre offre de pentest IA. Vous souhaitez échanger sur votre projet ou évaluer vos besoins ? Contactez nos experts.