Le piège n'est pas dans votre question, il est dans ce que l'agent lit
L'injection de prompt directe, c'est un utilisateur qui tape un ordre détourné dans la conversation. On sait à peu près la voir venir. La variante indirecte est d'une autre nature : l'instruction malveillante est cachée dans un contenu que l'agent va traiter de lui-même, un courriel entrant, une pièce jointe, une page web, une fiche produit, un ticket. L'agent lit ce contenu, y trouve un ordre, et l'exécute comme s'il venait de vous.
Ce qui rend cette forme redoutable, c'est qu'elle ne demande aucun accès à vos systèmes. Il suffit de déposer le texte piégé là où l'agent ira le chercher. Vous n'avez rien ouvert, rien cliqué, rien validé : l'agent a fait son travail, lire, et c'est précisément son travail qui l'a exposé.
Pourquoi les filtres ne suffisent pas
La première réaction du marché a été comportementale : ajouter un filtre, un classifieur, un détecteur d'instructions suspectes en amont du modèle. C'est utile, ce n'est pas suffisant. Ces dispositifs sont probabilistes : ils estiment qu'un texte ressemble à une attaque. Un attaquant qui observe le filtre et reformule finit par passer, parce qu'il joue en second, après avoir vu la défense.
La raison de fond est plus dure encore. Pour un modèle de langage, une instruction et une donnée sont faites de la même matière, du texte. Il n'existe pas de séparation native entre « ce que je dois faire » et « ce que je dois seulement lire ». Filtrer parfaitement l'un sans amputer l'autre n'est pas un réglage qu'on attend, c'est une limite des systèmes actuels. Les référentiels du domaine ne disent pas autre chose.
Source, le référentiel OWASP « Top 10 for LLM Applications » (édition 2025) classe l'injection de prompt au premier rang des risques (LLM01) et conclut qu'il n'existe pas, à ce jour, de méthode de prévention infaillible. Travaux de recherche convergents, « The Attacker Moves Second » (novembre 2025) montre que des attaquants adaptatifs battent la plupart des défenses par filtrage. OWASP Gen AI Security Project. Vérifié juillet 2026.
Ce n'est plus une hypothèse de laboratoire
En 2025, la démonstration est passée du concept au produit. La faille EchoLeak, sur l'assistant Microsoft 365 Copilot, a établi qu'un simple courriel piégé suffisait à faire fuiter des données de l'utilisateur, sans un seul clic de sa part. Le texte d'attaque, dissimulé dans le message, était lu par l'assistant, qui exécutait l'exfiltration. C'est le premier cas public d'injection indirecte transformée en fuite de données réelle sur un produit grand public. Microsoft a corrigé la faille.
Référence, EchoLeak (CVE-2025-32711), injection de prompt indirecte « zéro clic » sur Microsoft 365 Copilot, divulguée par Aim Security en juin 2025 (gravité critique), corrigée par Microsoft. Vérifié juillet 2026.
La bonne question n'est pas « mon filtre tiendra-t-il ? », mais « que peut faire mon agent le jour où il tient un ordre piégé ? ».
La parade est une décision d'architecture
Puisque le contenu piégé finira par arriver, la sécurité se joue sur ce que l'agent a le droit de faire à ce moment-là. Trois décisions, prises en conception, changent tout. Séparer ce qui fait autorité de ce qui ne la fait pas, les instructions de confiance d'un côté, les données extérieures de l'autre. Accorder à l'agent le strict nécessaire, c'est le moindre privilège, pour qu'un détournement ne donne accès qu'à très peu. Et garder l'humain dans la boucle pour toute action qui engage, le tout journalisé.
Aucune de ces trois décisions ne s'achète en rayon. Elles se conçoivent, cas d'usage par cas d'usage. C'est la raison pour laquelle nous parlons de sécurité agentique comme d'un sujet d'architecture, et non d'un produit de plus. Le détail daté, le cadre de l'ANSSI et le coût réel d'un déploiement sont réunis dans le dossier de référence.