Pourquoi les détecteurs d'injection de prompt échouent : le problème d'évasion en 2026

En bref Les « détecteurs » d’injection de prompt — ces garde-fous en entrée qui signalent une instruction malveillante avant qu’elle n’atteigne le modèle — sont largement déployés et faciles à survendre. Deux études évaluées par les pairs, Hackett et al. (LLMSec 2025) et Jahed & Alouani (arXiv 2602.00750, février 2026), montrent que les détecteurs classiques par classifieur comme les nouveaux détecteurs par activation cèdent face à un adversaire adaptatif, parfois avec une évasion proche de 100 %. La leçon est architecturale : un détecteur est un filtre utile, pas une frontière de sécurité.

De quoi s’agit-il ?

L’injection de prompt est le risque numéro un de l’OWASP pour les applications LLM, et la première ligne de défense la plus courante est un détecteur : un modèle ou un jeu de règles distinct qui inspecte l’entrée non fiable et bloque tout ce qui ressemble à une instruction injectée. Azure Prompt Shield de Microsoft et Prompt Guard de Meta en sont des exemples connus.

Le résultat dérangeant, documenté sur 2025-2026, est que ces détecteurs sont systématiquement contournables. Hackett, Birch, Trawicki, Suri et Garraghan ont testé six systèmes de protection répandus et rapportent des taux d’évasion jusqu’à 100 % (arXiv 2504.11168, v1 avril 2025, accepté à LLMSec 2025). En février 2026, JR Jahed et Ihsen Alouani ont braqué le même projecteur sur la génération plus récente — les sondes de « dérive de tâche » par activation, qui lisent les couches cachées du modèle — et les ont brisées aussi (arXiv 2602.00750). L’idée de détection change ; le résultat d’évasion se répète.

Comment ça marche

Il existe deux familles d’évasion distinctes, adaptées à deux conceptions de détecteur. Aucun payload fonctionnel n’est reproduit ici — l’objet est la classe d’attaque, pas un exploit prêt à copier-coller.

Contre les détecteurs texte/classifieur — l’injection de caractères. L’instruction injectée est réécrite de sorte qu’un humain (et le modèle) la lise toujours, mais pas la tokenisation ou la logique par mots-clés du détecteur. Les techniques publiées incluent les caractères de largeur nulle et les Unicode Tag, la substitution par homoglyphes, les caractères pleine chasse (CJK), le leetspeak, l’espacement des caractères et l’encapsulation base64 :

Détecteur voit : tokens brouillés / encodés / espacés -> "bénin"
Modèle voit :    la même chaîne, normalisée en interne -> suit l'instruction

Hackett et al. y ajoutent une étape d’apprentissage automatique adverse : un classement d’importance des mots calculé sur un modèle white-box hors ligne rend les contournements black-box plus fiables.

Contre les détecteurs par activation — les suffixes adverses. Les sondes de dérive ne lisent pas les caractères ; elles lisent le décalage qu’une instruction malveillante provoque dans les activations internes du modèle. Jahed & Alouani ajoutent un suffixe optimisé de façon adverse à l’entrée empoisonnée, via une recherche Greedy Coordinate Gradient (GCG) modifiée, pour trouver un suffixe universel qui trompe toutes les sondes couche par couche en même temps tout en conservant l’efficacité de l’injection. Taux de réussite rapporté pour évader toutes les sondes simultanément : 93,91 % sur Phi-3 3.8B et 99,63 % sur Llama-3 8B.

Le fil conducteur est l’adversaire adaptatif. Un détecteur entraîné ou réglé sur les chaînes d’attaque d’hier est, par construction, une cible fixe — et un attaquant qui peut l’interroger ou le modéliser peut chercher à le contourner.

Pourquoi c’est important

Si votre architecture suppose que « le garde-fou l’a attrapé », une évasion est silencieuse : l’instruction injectée atteint le modèle, et tout ce qui suit — appels d’outils, lectures de données, requêtes sortantes — se déroule comme si l’entrée était de confiance. Le rayon d’impact est tout ce que l’agent a le droit de faire.

Ce n’est pas une raison d’abandonner les détecteurs ; un bon filtre arrête encore les 90 % d’attaques paresseuses et fournit un signal pour la supervision. C’est une raison de cesser de les compter comme un contrôle pouvant « échouer en mode fermé ». Les éditeurs citent des scores F1 sur des benchmarks statiques ; les études ci-dessus mesurent autre chose — la robustesse face à un attaquant qui s’adapte — et ce chiffre est bien plus bas.

Défenses

La détection est une couche. Concevez comme si elle allait être contournée.

1. Normalisez avant d’inspecter. La plupart des contournements par injection de caractères meurent sous la canonicalisation : normalisation Unicode NFKC, suppression des caractères de largeur nulle et des Unicode Tag, repli des homoglyphes, réduction des espaces et décodage des base64 évidents. Un retour d’expérience de mars 2026 sur le scanner open source ClawGuard montre qu’un prétraitement déterministe (dont la normalisation pleine chasse) capture une large part de ces variantes avec une latence sous les 10 ms. La normalisation se place en amont de tout détecteur.

2. Ne faites pas du détecteur la frontière. Les contrôles qui survivent à une détection manquée sont architecturaux : moindre privilège sur chaque outil, séparation stricte entre instructions de confiance et données non fiables, et le fait d’éviter la « triade létale » accès aux données privées + contenu non fiable + canal d’exfiltration dans le même contexte d’agent. Mettez un humain dans la boucle pour les actions conséquentes.

3. Empilez les détecteurs pour qu’une évasion doive tous les vaincre. Une étape déterministe regex/normalisation, un classifieur et une sonde d’activation échouent à des attaques différentes. Exigez qu’un contournement déjoue toute la pile simultanément, et fixez un point de fonctionnement unique pour mesurer le rappel honnêtement plutôt que de choisir les seuils à la carte.

4. Entraînez de façon adverse ce que vous conservez. Jahed & Alouani proposent l’augmentation par suffixes — générer plusieurs suffixes adverses, en ajouter un au hasard pendant l’entraînement, et entraîner la sonde sur les activations résultantes. Cela augmente le coût de l’évasion ; cela ne ferme pas l’écart.

5. Supposez l’échec et surveillez les sorties. Restreignez les flux sortants, journalisez les appels d’outils et alertez sur les séquences d’actions anormales. L’injection que vous ne détectez pas en entrée, vous pouvez encore l’attraper au niveau de l’action.

6. Red-teamez votre propre garde-fou. Exécutez ces classes d’évasion publiées contre votre pile avec des outils comme garak ou promptfoo, à un seuil fixe, avant qu’un attaquant ne le fasse.

Statut

Élément	Référence	Date	Note
Évasion injection de caractères + AML, 6 systèmes	arXiv 2504.11168	avr. 2025 (LLMSec 2025)	Jusqu’à 100 % d’évasion ; Azure Prompt Shield, Meta Prompt Guard parmi les cibles
Évasion par suffixe adverse des sondes d’activation	arXiv 2602.00750	févr. 2026	93,91 % (Phi-3 3.8B), 99,63 % (Llama-3 8B) pour évader toutes les sondes
Défense par normalisation déterministe (ClawGuard)	earezki.com	mars 2026	Prétraitement regex/NFKC, sous 10 ms ; cite 2602.00750
Injection de prompt = LLM01	OWASP LLM Top 10	2026	Toujours le risque applicatif n° 1

Le cadrage à retenir : un détecteur d’injection de prompt vous renseigne sur les attaques que l’adversaire n’a pas pris la peine de masquer. Traitez un résultat propre comme l’absence d’attaque paresseuse, pas comme la présence de sûreté — et placez vos vrais contrôles là où le modèle agit, pas là où il lit.