Un document PDF suffit. Une ligne de texte blanc sur fond blanc, quelque part dans un rapport téléchargé par votre agent de veille, et voilà votre pipeline marketing en train d’exfiltrer des données vers un serveur inconnu. Aucune faille de code. Aucun exploit. Juste des mots, lus par une machine qui ne sait pas distinguer une instruction d’une information.
La prompt injection occupe la première place du Top 10 de l’OWASP pour les applications LLM depuis la refonte de 2025, et elle y reste en 2026. Non par paresse du classement, mais parce que personne n’a trouvé de correctif. Les audits de sécurité menés sur des déploiements IA en production la retrouvent dans plus de 73 % des cas. C’est le genre de statistique qui devrait faire réfléchir avant de brancher un agent sur votre CRM.
Le péché originel des LLM
Le problème est architectural. Un modèle de langage reçoit tout sous la même forme, à savoir des chaînes de texte en langage naturel. Le prompt système du développeur, la question de l’utilisateur, le contenu d’une page web récupérée, un ticket de support, un commentaire de code. Tout arrive dans le même canal, sans étiquette, sans hiérarchie de confiance native.
Le modèle décide alors, sur la base de son entraînement et du contexte, ce qui ressemble à une instruction. Un attaquant qui rédige quelque chose de suffisamment autoritaire (« IGNORE LES INSTRUCTIONS PRÉCÉDENTES ») peut donc prendre la main. Les développeurs qui viennent du web connaissent l’injection SQL et savent qu’on la corrige avec des requêtes préparées, une séparation stricte entre code et données. Ici, cette séparation n’existe pas. Elle est peut-être impossible à obtenir sans changer de paradigme.
A lire également
Deux familles se distinguent. L’injection directe, quand l’utilisateur lui-même formule la manipulation dans sa saisie. Et l’injection indirecte, autrement plus vicieuse, où les instructions malveillantes dorment dans un contenu externe que le système va ingérer de son propre chef. Page web, e-mail, fichier joint, document dans une base vectorielle. L’utilisateur légitime déclenche l’attaque sans jamais la voir.
Point souvent négligé : une injection n’a pas besoin d’être lisible par un humain. Du texte en caractères Unicode invisibles, du LaTeX rendu en blanc, un encodage Base64, des instructions cachées dans les métadonnées d’une image. Si le modèle parse le contenu, le contenu peut le piloter.
Les chatbots étaient un jeu d’enfant, les agents sont une porte blindée mal fermée
Un chatbot qui déraille produit une réponse embarrassante. Un bot Twitter a ainsi fini par endosser la responsabilité de l’explosion de Challenger en 1986, sur simple demande d’un internaute taquin. Coût réel de l’incident, quelques captures d’écran virales et une leçon d’humilité.
Un agent qui déraille exécute des actions. La différence est d’ordre de grandeur. L’agent possède des tokens d’API, des accès en écriture, une mémoire persistante et la capacité d’enchaîner des appels d’outils sans repasser par un humain. La gravité d’une injection réussie dépend donc directement de ce qu’on a mis entre ses mains. OWASP le formule sans détour, l’impact varie selon le contexte métier et selon « l’agentivité » avec laquelle le système a été architecturé.
Trois vecteurs propres aux agents méritent votre attention. L’injection dans les étapes de raisonnement, où l’attaquant forge de faux résultats d’outils pour orienter la chaîne de décision. La manipulation d’outils, qui consiste à faire appeler une fonction légitime avec des paramètres contrôlés par l’attaquant. Et l’empoisonnement de contexte, qui glisse de fausses informations dans la mémoire de travail de l’agent pour qu’elles agissent plus tard, dans une autre session.
L’ampleur du phénomène a d’ailleurs poussé l’OWASP à publier un Top 10 dédié aux applications agentiques (ASI pour Agentic Security Initiative), distinct de celui des LLM (voir le rapport officiel). Comportements autonomes imprévus, chaînes de prompts complexes, fuites de données via des API connectées, manipulation multi-agents. Le vieux référentiel ne suffisait plus.
Ce que les attaques documentées nous apprennent vraiment
Janvier 2025, des chercheurs démontrent une attaque contre un système RAG d’entreprise. La méthode tient en une phrase, ils déposent un document public contenant des instructions cachées, le système l’indexe, une requête utilisateur banale le fait remonter, et l’agent exfiltre de l’intelligence économique tout en passant des appels d’API au-delà du périmètre d’autorisation de l’utilisateur. Personne n’a piraté le modèle. On a piraté sa bibliothèque. C’est aussi ce qui a permis à la faille « PleaseFix » de retourner les navigateurs IA en espions sans le moindre clic.
Le RAG, présenté un temps comme un garde-fou contre les hallucinations, s’avère un vecteur d’attaque de premier choix. Même constat pour le fine-tuning. Les deux améliorent la pertinence des sorties sans jamais résoudre la confusion instruction/donnée.
Côté taux de succès, les chiffres publiés font mal. Certaines techniques dépassent 50 % de réussite sur l’ensemble des modèles testés, avec des pointes à 88 %. Le jailbreaking dit Best-of-N, qui consiste à générer des centaines de variantes d’un même prompt jusqu’à ce que l’une passe, atteint 89 % sur GPT-4o et 78 % sur Claude 3.5 Sonnet avec assez de tentatives. Et la mauvaise nouvelle est mathématique. Ce phénomène suit une loi de puissance, ce qui signifie que le rate limiting, les filtres de contenu, les circuit breakers et même une température à 0 ne font que renchérir le coût de l’attaque. Ils ne l’empêchent pas.
| Technique | Cible | Taux de succès rapporté |
|---|---|---|
| Best-of-N jailbreaking | GPT-4o | 89 % |
| Best-of-N jailbreaking | Claude 3.5 Sonnet | 78 % |
| Techniques d’injection variées | Modèles multiples | 50 % à 88 % |
Les vecteurs les plus rentables sont ceux que personne ne surveille. Commentaires de code analysés par un assistant de développement, messages de commit, descriptions de tickets, avis clients, corps d’e-mails traités par un assistant. Tout ce que votre entreprise considère comme du contenu de travail devient une surface d’attaque dès qu’un agent le lit.
Le cas des injections involontaires
Toutes les injections ne sont pas forcément hostiles mais peuvent aussi permettre de dénicher les tricheurs. Une entreprise glisse dans ses offres d’emploi une instruction cachée destinée à détecter les candidatures rédigées par IA. Un candidat, ignorant tout de ce piège, passe l’annonce dans un modèle pour optimiser son CV… et déclenche lui-même le détecteur.
Symétriquement, les candidats ont appris à jouer le même jeu. Des CV contenant des fragments d’instructions découpés en plusieurs endroits du document, inoffensifs isolément, se recombinent lors de l’analyse par le modèle de tri et produisent une recommandation favorable qui n’a rien à voir avec le contenu réel du parcours. Le payload splitting appliqué aux ressources humaines.
Ces épisodes disent quelque chose d’utile. Une injection ne nécessite ni attaquant sophistiqué ni intention criminelle. Il suffit qu’un texte destiné à une machine croise une autre machine.
Ce que ça coûte, concrètement
Divulgation de données sensibles, en tête de liste. Conversations privées exfiltrées via une balise image générée par le modèle lui-même, une technique élégante où l’URL de l’image contient les données volées. L’utilisateur voit une image cassée, l’attaquant reçoit son paquet.
Fuite de prompt système ensuite. On sous-estime la valeur de ces instructions. Elles révèlent l’architecture, les outils connectés, les règles métier, parfois les noms de fonctions internes. C’est la carte du terrain offerte à qui reviendra plus tard.
Exécution d’actions non autorisées, le poste le plus onéreux. Un agent branché sur une messagerie, une base de données ou une régie publicitaire peut envoyer, supprimer, dépenser. C’est exactement ce qui s’est produit avec l’agent JadePuffer qui a rançonné une entreprise sans intervention humaine, en combinant plusieurs failles d’agents autonomes. La vulnérabilité CVE-2024-5184, sur un assistant e-mail propulsé par LLM, illustrait déjà ce chemin, notamment l’accès à des informations sensibles et la manipulation du contenu des messages.
Manipulation de décisions enfin, la plus difficile à détecter. Un contenu empoisonné dans la base de connaissances biaise durablement les recommandations d’un agent d’analyse concurrentielle ou de pilotage budgétaire. Aucune alerte ne se déclenche. Les décisions se dégradent lentement, et vous mettez six mois à comprendre pourquoi.
Se défendre quand le correctif n’existe pas
Aucune méthode ne garantit l’immunité. L’OWASP l’écrit noir sur blanc, la nature stochastique des modèles génératifs rend incertaine l’existence d’une prévention infaillible. La question devient donc celle de la réduction d’impact, pas celle de l’élimination du risque. Voici l’ordre de priorité que je recommanderais à quiconque met un agent en production.
- Moindre privilège, avant tout le reste. L’agent ne doit détenir que les droits strictement nécessaires. Comptes en lecture seule quand c’est possible, tokens applicatifs distincts, scopes d’API réduits, durée de vie des jetons plafonnée à 24 heures avec rotation obligatoire. Les fonctions sensibles restent gérées dans le code, jamais exposées au modèle.
- Human-in-the-loop sur les actions destructrices. Envoi de masse, suppression, modification de budget, publication. Un agent marketing qui pousse des contenus en production sans validation humaine est une expérience, pas un outil.
- Séparation structurée des contenus non fiables. Balisage explicite des données externes, formats de sortie contraints et validés par du code déterministe, citations de sources exigées. Le modèle doit savoir ce qu’il lit et vous devez pouvoir vérifier ce qu’il produit.
- Filtrage en entrée et en sortie. Les regex attrapent les tentatives naïves. Elles échouent sur l’obfuscation, la typoglycémie (« ignroe all prevoius instructions »), l’encodage et le multilingue. D’où l’intérêt de classifieurs dédiés, dont Llama Guard, ShieldGemma, Granite Guardian ou Prompt Guard.
- Contrôle des appels d’outils. Chaque action proposée est évaluée contre l’intention initiale de l’utilisateur, sans le contexte intermédiaire non fiable. Un garde-fou qui ne voit que la tâche demandée et l’action envisagée refusera les dérives.
- Tests adverses réguliers. On traite le modèle comme un utilisateur hostile et on mesure la tenue des frontières de confiance. Pas une fois à la mise en production, en continu.
Le motif le plus solide sur le plan architectural reste le dual-LLM, formalisé par Simon Willison. Un modèle privilégié détient les outils et ne lit jamais de contenu non fiable. Un modèle mis en quarantaine lit le contenu douteux et ne peut rien exécuter. Le premier reçoit du second des résumés structurés ou des étiquettes. Le chemin dont une instruction injectée a besoin pour atteindre l’exécutant se trouve ainsi coupé. Élégant, coûteux en latence, et de loin la meilleure garantie disponible.
Attention au piège de la confiance mal placée. Un garde-fou construit sur un LLM demeure un LLM, donc lui-même injectable. Il doit présenter une surface d’attaque différente de celle du modèle principal, faute de quoi le jailbreak qui défait l’un défait l’autre. Un classifieur spécialisé vaut mieux qu’un modèle de chat généraliste issu de la même famille.
Ce que devraient exiger les acheteurs d’agents IA
Le marché des agents IA a explosé depuis 2025, et la plupart des offres des consultants (souvent des opportunistes avec peu d’experience) traitent la sécurité comme une case à cocher en fin de documentation. Poser trois questions à un « prestataire » suffit généralement à révéler qui sont les plus les plus sérieux et qui sont les charlatans. Comment le contenu externe ingéré est-il isolé du prompt système ? Quelles actions requièrent une validation humaine et lesquelles sont automatiques ? Quels privilèges l’agent détient-il sur mes systèmes connectés, et pour combien de temps ?
Un installateur d’agent IA qui a pensé securité et connait le produit qu’il s’apprête a vous installer, saura décrire exactement le périmètre d’autorisation, les points de validation et la journalisation de la solution choisie.
Openclaw, Hermes Agent, Claude (même si ce dernier est le mieux doté) ? Toutes ces solutions n’ont pas parfaitement intégré cette logique d’architecture sécuritaire dès la conception, avec un cloisonnement des contenus tiers, des privilèges minimaux par agent et une traçabilité des décisions. Contrôler tous ces aspects avant de choisir son harness agentique est souvent pénible et voir très coûteux pour une entreprise. Un coût qui reste a relativiser le jour où il épargnera un incident grave…
La journalisation, justement, reste le parent pauvre des déploiements. Consigner chaque interaction, chaque décision de garde-fou, chaque appel d’outil. Surveiller les dérives dans les taux de refus, qui précèdent souvent un contournement fonctionnel. Sans traces, une injection réussie ne laisse aucun cadavre.
La prompt injection ne se corrigera pas par un patch. Elle se gère comme un risque opérationnel permanent, au même titre que la fraude au paiement. Ceux qui l’ont compris déploient des agents utiles. Les autres découvriront la facture, un jour, dans un log qu’ils n’auront pas activé.
