On ne force pas un LLM, on le persuade — la sécurité IA depuis Troie

L'email arrive dans la boîte d'un salarié, parfaitement banal en apparence. Personne ne clique sur rien — il n'y a rien à cliquer. Les instructions malveillantes sont là, invisibles, écrites en blanc sur fond blanc et glissées dans le code de la page. Des jours plus tard, le salarié pose une question ordinaire à son assistant Microsoft 365 Copilot ; l'assistant, fouillant le contexte pour bien répondre, retrouve l'email, lit les consignes cachées — et se met à exfiltrer des données internes vers l'attaquant. Zéro clic, zéro malware, zéro porte forcée. Ce scénario n'est pas une fiction : c'est EchoLeak (CVE-2025-32711), démontré par les chercheurs d'Aim Security et divulgué en juin 2025, noté 9,3 sur 10 en criticité, corrigé par Microsoft sans exploitation connue dans la nature. La leçon tient en une phrase : on ne force pas un LLM, on le persuade.

Troie, en miroir

Ce mécanisme a trois mille ans. Pendant dix ans, les Grecs assiègent Troie sans percer ses murailles. La ville est imprenable de force. Elle tombe pourtant en une nuit — non parce qu'un assaillant a franchi les remparts, mais parce que les Troyens ont eux-mêmes fait entrer dans leurs murs un cadeau de bois qu'ils croyaient inoffensif. La faille n'était pas dans la pierre ; elle était dans la confiance. EchoLeak rejoue la scène trait pour trait : l'email piégé n'a pas enfoncé la porte, c'est l'assistant qui est allé le chercher, comme les Troyens ont roulé le cheval jusque dans la place. On imagine volontiers le « hacking » d'une IA comme un assaut technique ; c'est presque toujours l'inverse : l'attaque passe par ce que le système a été conçu pour accueillir et croire.

La faille est structurelle, pas accidentelle

Un LLM ne fait qu'une chose : il lit un contexte et prédit la suite. Or, dans ce contexte, il ne distingue pas nativement ce qui relève de l'instruction légitime (les consignes du développeur) et ce qui relève de la donnée à traiter (un email, une page web, un document). Tout y arrive sous la même forme : du langage. C'est cette absence de frontière étanche qui rend le problème si coriace.

Les sécurologues connaissent cette configuration depuis longtemps sous un autre nom : le confused deputy, le « député confus ». Un agent doté d'autorité (ici, l'IA) est manipulé par un tiers pour exercer cette autorité à mauvais escient, parce qu'il ne parvient pas à distinguer un ordre légitime d'un ordre frauduleux glissé dans son flux de travail. La faille n'est pas un bug qu'un correctif élimine ; elle découle de la nature même d'un système qui obéit au langage et se nourrit de langage. On peut la réduire, la cloisonner, la surveiller. On ne peut pas, aujourd'hui, la supprimer d'un trait.

L'injection de prompt, cheval de Troie contemporain

La manifestation la plus directe s'appelle l'injection de prompt. Le parallèle que dressent les experts est celui de l'injection SQL : quand un système mélange sans précaution des données venues de l'extérieur et ses propres instructions, il ouvre la porte au détournement. L'injection est le revers exact de l'art de guider le modèle par les mots — cet art auquel j'ai consacré une bible du prompt engineering : les mêmes mécanismes qui orientent la machine servent à la détourner.

On en distingue deux formes, et la seconde est la plus insidieuse. L'injection directe : un utilisateur formule une requête conçue pour faire sortir le modèle de son cadre. L'injection indirecte — celle d'EchoLeak : le modèle va chercher une donnée extérieure — une page web, une fiche CRM, un log — dans laquelle un tiers a dissimulé des instructions piégées. Le contenu malveillant n'est pas envoyé par la grande porte du chat, il est importé par le système lui-même, dans un document qu'il avait toute raison de traiter. Une IA chargée de résumer des fiches clients peut ainsi rencontrer, tapie dans un champ « description », une consigne qu'elle n'aurait jamais dû suivre — et la suivre.

Le jailbreak, souvent confondu avec l'injection, en diffère : il vise à contourner les garde-fous éthiques du modèle lui-même (lui faire produire un contenu interdit). C'est davantage l'affaire du fournisseur du modèle que de l'entreprise qui l'intègre — distinction importante quand il s'agit d'attribuer une responsabilité.

Pourquoi l'IA réactive de vieilles vulnérabilités

Le point que les décideurs saisissent mal, c'est que l'injection de prompt n'est souvent qu'un vecteur : elle sert de tremplin à des failles web classiques, brusquement rajeunies. Une IA autorisée à interroger une base de données, à générer du HTML affiché à d'autres utilisateurs, ou à déclencher des actions via des outils externes, devient un intermédiaire que l'on peut manipuler pour rejouer des attaques connues (accès à des données d'autrui, code injecté côté navigateur, actions non autorisées).

Il y a là une leçon d'histoire des techniques que je trouve fascinante. Chaque nouvelle couche d'abstraction ne supprime pas les vulnérabilités du niveau inférieur : elle les hérite, parfois masquées, parfois amplifiées. Les ingénieurs du XIXe siècle qui bâtissaient des ponts métalliques ont redécouvert, à leurs dépens, des modes de rupture que la pierre ne connaissait pas. L'IA agentique est notre nouveau pont métallique : elle ouvre des portées inouïes, et introduit des modes de défaillance inédits qu'aucune équipe sérieuse ne peut ignorer.

L'immunité plutôt que la muraille

Alors, comment se défend-on ? La mauvaise nouvelle : il n'existe aucune parade unique et définitive. La bonne : la biologie nous souffle le bon modèle. Face à des menaces qui muent sans cesse, le vivant n'a pas misé sur une carapace impénétrable — aucune ne l'est — mais sur un système immunitaire : une défense en profondeur, redondante, capable de distinguer le soi du non-soi et de réagir à l'inconnu. C'est exactement la posture à adopter pour une application IA.

Concrètement, cela signifie superposer les couches plutôt que chercher le mur parfait. Cloisonner sévèrement les permissions de l'IA selon le rôle de l'utilisateur. Renforcer le prompt système, tout en sachant qu'il ne suffit pas. Surveiller les sorties avant qu'elles n'atteignent l'utilisateur, en particulier tout déclenchement d'action sensible. Traiter toute donnée externe comme potentiellement hostile. Ajoutez-y des tests réguliers et une veille active : comme un organisme, un système sûr n'est jamais sûr une fois pour toutes, il le reste par vigilance continue.

Trois gestes avant de brancher un agent au public

Quand j'accompagne une entreprise dans le déploiement d'un agent IA, la sécurité n'arrive pas à la fin, en rustine : elle structure la conception dès le premier jour — c'est selon ce principe que nous concevons les agents IA que nous bâtissons pour nos clients. Et si vous ne deviez retenir que trois gestes minimaux avant d'exposer un agent au public, ce seraient ceux-ci.

Un : le moindre privilège, sans exception. Un agent grand public ne doit jamais pouvoir exécuter de code, toucher aux ressources internes ou agir au-delà du strict nécessaire. Chaque capacité accordée se justifie par écrit, ou se supprime.

Deux : toute donnée externe est hostile jusqu'à preuve du contraire. Emails, pages web, fiches CRM, pièces jointes : tout ce que l'agent lit peut contenir des instructions cachées. Filtrez ce qui entre, contrôlez ce qui sort — EchoLeak est passé par un simple email que personne n'a ouvert.

Trois : un humain sur le chemin des actions sensibles. Aucun envoi, aucune modification, aucune transaction à fort enjeu sans point de contrôle humain — et des tests d'attaque réguliers pour vérifier que ces verrous tiennent.

Les Troyens n'ont pas perdu faute de murailles ; ils ont perdu faute d'avoir imaginé que le danger pouvait entrer déguisé en présent. Nos systèmes sont d'autant plus vulnérables qu'ils sont conçus pour lire, faire confiance et agir. La sécurité n'est pas l'ennemie de cette ouverture — elle en est la condition.