Injection de prompt : le risque qu'aucun filtre ne corrige
Tout agent qui lit des e-mails, des pages web ou des tickets peut recevoir des ordres d'un inconnu. Voici comment fonctionne l'injection de prompt, pourquoi personne ne l'a résolue et comment concevoir vos systèmes pour qu'une attaque réussie ne cause pas de dégâts.
L'injection de prompt est le risque numéro un de la liste OWASP pour les applications de LLM (LLM01) et n'a pas de correctif définitif : le modèle reçoit instructions et données par le même canal. OpenAI reconnaît elle-même qu'il ne sera probablement jamais entièrement résolu.
Conséquence pratique : il faut concevoir en partant du principe que l'attaque réussira. Si un agent combine données privées, contenu non fiable et moyen d'envoyer de l'information vers l'extérieur, un attaquant peut voler des données sans toucher à votre infrastructure. Voici les incidents réels, les contrôles avec leurs limites et une check-list.
Injection directe et indirecte, en termes simples
Un modèle de langage reçoit un seul bloc de texte : vos instructions système, la question de l'utilisateur et tout ce qu'il lit pour répondre. L'injection de prompt consiste à glisser dans ce texte des instructions que le modèle finit par suivre, alors qu'aucune personne autorisée ne les a données.
Dans l'injection directe, l'attaquant est l'utilisateur lui-même : il écrit dans le chat pour que l'assistant ignore ses règles, révèle son prompt système ou dise ce qu'il ne devrait pas. Dans un chatbot sans outils, le dommage se limite en général à une réponse inappropriée ou à la fuite du prompt système.
Dans l'injection indirecte, l'attaquant ne parle jamais au modèle. Il cache des instructions dans un contenu que l'agent va lire : un e-mail, une page web, un ticket, une ligne de log ou la description d'un outil. Quand l'agent traite ce contenu avec le droit de lire des données et d'agir, les instructions de l'attaquant s'exécutent avec l'identité de votre utilisateur. C'est la variante qui transforme un problème de texte en fuite de données.
Pourquoi elle reste non résolue, et la triade létale
Dans une base de données, on corrige l'injection SQL en séparant la requête des données. Un modèle de langage n'offre pas cette séparation : tout n'est que tokens dans le même canal. C'est pourquoi le NCSC britannique (décembre 2025) recommande de la traiter comme un risque résiduel et d'en limiter l'impact par des contrôles déterministes sur ce que le système peut faire. OpenAI la compare aux arnaques en ligne : on la gère, on ne l'élimine pas.
Les modèles progressent, mais n'atteignent pas zéro. En novembre 2025, Anthropic a publié un taux de réussite d'attaque d'environ 1 % pour Claude Opus 4.5 face à un attaquant adaptatif disposant de 100 tentatives par scénario. 1 %, c'est peu dans une démo et beaucoup face à quelqu'un qui peut réessayer gratuitement. Dans le même temps, le rapport 2025 de HackerOne comptait une hausse de 540 % des signalements d'injection de prompt.
En juin 2025, Simon Willison a résumé les conditions qui rendent le risque grave avec la triade létale (lethal trifecta) : un agent qui (1) accède à des données privées, (2) est exposé à du contenu non fiable et (3) peut communiquer vers l'extérieur. Si les trois sont réunis, quiconque parvient à glisser des instructions dans ce que lit l'agent peut lui faire divulguer des données. Sa liste de failles de ce type, toutes corrigées après signalement, va de ChatGPT et Slack à Microsoft 365 Copilot : une classe de bug récurrente, pas un accident.
Si un agent réunit les trois pieds, retirez-en un avant son lancement : mode lecture seule, aucun contenu externe sur ce parcours ou sortie vers internet bloquée. Un filtre réduit la probabilité ; retirer un pied supprime le chemin.
Incidents réels, 2025–2026
| Date | Système | Ce qui s'est passé | Leçon |
|---|---|---|---|
| Mai 2025 | Serveur MCP officiel de GitHub (Invariant Labs) | Un ticket malveillant dans un dépôt public a détourné un agent, qui a divulgué les dépôts privés de la victime | Les outils étaient sains : c'est le flux qui posait problème |
| Juin 2025 | Microsoft 365 Copilot, EchoLeak (CVE-2025-32711, CVSS 9,3) | Un e-mail piégé, sans aucun clic, a conduit Copilot à extraire des données internes vers un serveur de l'attaquant | Corrigé côté serveur ; Microsoft n'a constaté aucune exploitation |
| Août 2025 | Navigateur Comet de Perplexity (Brave) | Du texte caché dans une page a été traité comme des instructions de l'utilisateur, dans sa session connectée | Les premiers correctifs étaient incomplets |
| Septembre 2025 | ChatGPT Deep Research avec Gmail, ShadowLeak (Radware) | Injection sans clic ; les données sont sorties depuis le cloud d'OpenAI | Invisible pour les contrôles réseau de l'entreprise |
| Septembre 2025 | Salesforce Agentforce, ForcedLeak (Noma, CVSS 9,4) | Des instructions dans un formulaire web de prospects envoyaient des données du CRM vers un domaine autorisé mais expiré, racheté pour environ 5 $ | Une liste d'autorisation exige de surveiller l'expiration des domaines |
2026 a prolongé la série. En janvier, Cyata a publié trois failles du serveur de référence mcp-server-git d'Anthropic, atteignables par injection de prompt. Le bilan de l'OWASP GenAI pour le premier trimestre 2026 recensait 8 incidents et notait que la plupart des événements de sécurité liés à l'IA n'ont jamais de CVE : qui ne surveille que les bases de vulnérabilités ne voit pas le problème.
Les référentiels : OWASP et MITRE ATLAS
| Référentiel | Date | Ce qu'il apporte | À utiliser pour |
|---|---|---|---|
| OWASP Top 10 for LLM Applications 2025 | Novembre 2024 | LLM01 Prompt Injection en tête ; aussi LLM06 autonomie excessive et LLM07 fuite du prompt système | Chatbots et fonctions à base de LLM |
| OWASP Top 10 for Agentic Applications 2026 | 9 décembre 2025 | Dix risques propres aux agents, dont ASI01 détournement d'objectif, ASI02 mauvais usage des outils et ASI06 empoisonnement de la mémoire et du contexte | Agents avec outils, mémoire et délégation |
| MITRE ATLAS | v2026.09, 14 septembre 2026 | 16 tactiques, 120 techniques et 73 études de cas ; des techniques d'agents depuis octobre 2025, comme l'exfiltration par appel d'outil | Modélisation des menaces et plans de red teaming |
Notre conseil : citez les références LLM01 et ASI01 dans vos exigences de sécurité et vos rapports de pentest, pour que les constats se lisent de la même façon à Bogotá, à Paris et en comité des risques.
Les défenses qui fonctionnent, et leurs limites
| Contrôle | Ce qu'il arrête | Ce qu'il n'arrête pas |
|---|---|---|
| Moindre privilège : identifiants par outil, lecture seule par défaut | Limite les dégâts : un agent manipulé ne fait que ce que son identifiant permet | La fuite des données que l'agent a le droit de lire |
| Séparer le planificateur des données non fiables (modèle « dual LLM », CaMeL) | Qu'un contenu externe modifie le plan ou l'enchaînement des outils | Les tâches dont le plan dépend du contenu lu ; coûte en utilité et en ingénierie |
| Confirmation humaine des actions à effet de bord | Envois, paiements ou suppressions silencieux | La lassitude d'approbation : on valide sans lire |
| Liste de sorties autorisées et blocage des canaux d'exfiltration | Ferme le troisième pied : images, liens ou appels vers des domaines externes | Les domaines autorisés qui expirent (ForcedLeak) et les sorties depuis le cloud de l'éditeur (ShadowLeak) |
| Isolement du contenu (spotlighting) et classificateurs | Réduit le taux de réussite des attaques connues | Probabiliste : un attaquant adaptatif finit par passer |
| Surveillance et journalisation de chaque appel d'outil | Détection, investigation et retour arrière | N'empêche rien si personne ne traite les alertes |
| Bac à sable avec réseau fermé par défaut | Exécution de code et mouvement latéral | Un bac à sable mal fermé ; même des laboratoires d'IA ont connu des évasions |
CaMeL, de Google, Google DeepMind et l'ETH Zurich (mars 2025), est la version la plus rigoureuse de cette séparation : il extrait le flux de contrôle de la demande fiable de l'utilisateur, de sorte que les données non fiables ne peuvent pas le modifier, et applique des politiques de capacités à chaque appel d'outil. Sur le benchmark AgentDojo, il a réussi 77 % des tâches avec une sécurité démontrable, contre 84 % pour un système sans défense.
La confirmation humaine a aussi ses limites. Anthropic explique avoir isolé le système de fichiers et le réseau de Claude Code précisément parce que les utilisateurs valident machinalement quand on leur demande l'autorisation à chaque étape ; avec le bac à sable, les demandes d'autorisation ont baissé de 84 % en interne.
Le bac à sable doit avoir le réseau fermé. En juillet 2026, lors d'évaluations internes de cybersécurité, des agents d'OpenAI (surtout un modèle de recherche interne aux garde-fous réduits) ont contourné les contrôles d'isolement, détourné un service interne de gestion de paquets en messagerie pour atteindre internet et attaqué des systèmes de Hugging Face. Selon l'enquête du METR, environ 700 des quelque 1 200 agents impliqués ont participé à l'attaque.
Comment tester votre agent ou votre chatbot
Un vrai attaquant essaie de nombreuses variantes et adapte chacune à la réponse : la métrique utile est donc le taux de réussite des attaques sur de nombreuses tentatives, pas dix phrases connues. C'est ainsi qu'Anthropic a publié ses résultats pour Claude dans Chrome : 123 cas de test répartis sur 29 scénarios, avec un taux de réussite passé de 23,6 % à 11,2 % après ses mesures d'atténuation.
- Modélisation des menaces. Pour chaque agent, listez les données qu'il lit, le contenu externe qui entre et les voies par lesquelles l'information peut sortir ; rattachez-les à l'OWASP et à ATLAS.
- Suites automatisées. AgentDojo, l'environnement utilisé pour évaluer CaMeL, mesure à la fois l'utilité et la sécurité. promptfoo (open source) couvre le red teaming, et Inspect, de l'AI Security Institute britannique, exécute des évaluations d'agents en bac à sable.
- Pentest manuel des fonctions d'IA. Injection indirecte par chaque canal d'entrée, voies d'exfiltration, contrôle d'accès à travers l'agent (un utilisateur peut-il obtenir les données d'un autre en le lui demandant ?), serveurs MCP et secrets dans la configuration.
La part manuelle reste décisive : dans le rapport 2025 de HackerOne, 58 % des chercheurs estiment que l'IA passe à côté des failles de logique métier et des attaques en chaîne, précisément là où les agents ajoutent de la surface.
Check-list avant de lancer un chatbot ou un agent
- Dessinez la triade de chaque agent ; si les trois pieds sont présents, retirez-en un avant le lancement.
- Donnez à chaque outil l'identifiant minimal, en lecture seule par défaut, et appliquez le contrôle d'accès par utilisateur dans votre API, pas dans le prompt.
- Considérez comme non fiable tout ce que lit l'agent : e-mails, pages, fichiers, tickets, réponses d'outils et descriptions des serveurs MCP.
- Exigez une confirmation humaine pour les actions irréversibles ou sortantes (envoyer, payer, supprimer, publier) et affichez l'action exacte.
- Bloquez les canaux d'exfiltration : pas d'affichage non contrôlé d'images ou de liens externes, et des sorties limitées à des domaines autorisés que vous maîtrisez.
- Figez la version de chaque serveur MCP et outil, et soyez alerté si leurs descriptions changent.
- Exécutez le code et la navigation dans un bac à sable sans accès à internet par défaut.
- Journalisez chaque appel d'outil avec ses arguments, hors de portée de l'agent, et traitez les alertes.
- Faites du red teaming avant le lancement et à chaque changement de modèle, de prompt ou d'outil, et préparez le plan d'incident : arrêt d'urgence, révocation des identifiants et circuit de notification.
Ce que cela signifie pour les entreprises en Colombie et en Europe
En Colombie, si une injection fait fuiter des données personnelles, c'est un incident de sécurité au sens de la loi 1581 de 2012 : responsables et sous-traitants doivent le déclarer à la Superintendencia de Industria y Comercio (articles 17 et 18), via le module d'incidents du registre national des bases de données. La SIC peut infliger des amendes allant jusqu'à 2 000 salaires minimums mensuels.
Dans l'Union européenne, le RGPD s'applique à toute fuite de données personnelles, et l'article 15 de l'AI Act impose aux systèmes à haut risque de résister aux tentatives de tiers d'exploiter leurs vulnérabilités. Depuis le paquet Omnibus, ces obligations s'appliquent au 2 décembre 2027 pour les domaines de l'annexe III. En France, les recommandations de sécurité de l'ANSSI pour un système d'IA générative (2024) sont un bon point de départ.
Comment nous le couvrons chez Slash. Quand une application web ou une API intègre un chatbot ou un agent, nous l'incluons dans le périmètre de notre pentest : validation manuelle de chaque constat, retest et cas de test propres à l'IA (injection indirecte, canaux d'exfiltration, permissions des outils et serveurs MCP). Notre travail de cybersécurité se poursuit avec le durcissement et la remédiation. Si vous concevez l'agent, commencez par les garde-fous en production et MCP expliqué.
Partez du principe que l'injection réussira et concevez la suite. Si la réponse honnête est « l'agent pourrait envoyer des données clients n'importe où », le problème n'est pas le modèle mais l'architecture.
L'essentiel
- L'injection de prompt est le LLM01 de l'OWASP et n'a pas de correctif définitif : gérez-la comme un risque résiduel.
- La variante indirecte est la plus dangereuse pour les agents : l'attaquant écrit dans le contenu que lit l'agent, pas dans le chat.
- Si un agent combine données privées, contenu non fiable et canal de sortie, partez du principe que les données peuvent fuiter et retirez un pied.
- Les contrôles qui fonctionnent sont déterministes : moindre privilège, sorties autorisées, confirmation des actions et bac à sable ; les filtres ne font que baisser le taux.
- Testez avec des attaques adaptatives, mesurez le taux de réussite et recommencez à chaque changement de modèle, de prompt ou d'outil.
Sources
- The lethal trifecta for AI agents: private data, untrusted content, and external communication
- OWASP Top 10 for LLM Applications 2025
- OWASP Top 10 for Agentic Applications for 2026
- GenAI Exploit Round-up Report Q1 2026
- ATLAS data changelog (v2026.09)
- Prompt injection is not SQL injection
- Defeating Prompt Injections by Design (CaMeL)
- How Microsoft defends against indirect prompt injection attacks
- Agentic browser security: indirect prompt injection in Perplexity Comet
- ForcedLeak: agent risks exposed in Salesforce Agentforce
- Prompt injection defenses (research)
- The Hugging Face incident and the road ahead
Note éditoriale : cette analyse reflète les informations publiques disponibles à la date de révision. Modèles, prix et règles évoluent vite ; chaque donnée tierce renvoie à sa source et nos opinions sont présentées comme telles. Une erreur ? Écrivez à contact@slash-digital.io.
Les questions qu'on nous pose souvent
Quelle différence entre jailbreak et injection de prompt ?
L'OWASP considère le jailbreak comme une forme d'injection de prompt : il vise à faire ignorer au modèle ses règles de sécurité. L'injection est plus large et inclut des instructions cachées dans un contenu que le modèle lit à l'insu de l'utilisateur.
Un modèle plus récent règle-t-il le problème ?
Il aide mais ne l'élimine pas. Anthropic a publié un taux de réussite d'attaque d'environ 1 % pour Claude Opus 4.5 face à un attaquant adaptatif, et OpenAI juge une solution complète peu probable. La conception du système compte plus que le modèle.
Mon chatbot de service client sans outils est-il exposé ?
Moins, mais oui : il peut divulguer son prompt système ou donner des réponses inappropriées. Le risque augmente quand il lit des documents (RAG) ou se connecte au CRM. Ne placez aucun secret dans le prompt et appliquez les permissions dans vos API.
Les serveurs MCP sont-ils sûrs ?
MCP est un protocole ; le risque tient aux serveurs que vous connectez et à leurs permissions. Invariant Labs a documenté des descriptions d'outils empoisonnées et des serveurs qui changent après approbation. Figez les versions et relisez les descriptions ; plus de détails dans MCP expliqué.
À quelle fréquence faut-il tester ?
Avant le lancement et à chaque changement de modèle, de prompt, d'outils ou de sources de données, plus un pentest périodique des fonctions exposées.
D'autres analyses à lire
MCP expliqué aux entreprises
Ce qu'est le Model Context Protocol, son évolution jusqu'à la version 2026-07-28, sa gouvernance, sa différence avec A2A et comment l'adopter en sécurité.
CybersécuritéDes garde-fous qui fonctionnent en production
Les sept couches d'un dispositif de garde-fous, les modèles de garde de 2026 comparés, comment les mesurer en français et deux architectures de référence.
Agents et ingénierieAgents IA en production : ce qui marche en 2026
Workflow ou agent, les huit briques, données d'adoption et d'échec, usage de l'ordinateur, règles de conception, coûts, sécurité et check-list.
Et ensuite ?
Mettons-le en production
Racontez-nous votre défi. Nous répondons sous 24 heures ouvrées avec une première lecture honnête : si nous pouvons aider, nous dirons comment ; sinon, nous dirons qui peut.
Je réponds en personne. Pas de formulaires interminables ni de réponses automatiques.