Les défenses hors bande contre l'injection n'ont pas encore affronté d'attaquant adaptatif

De quoi s’agit-il ?

Le 25 juin 2026, des chercheurs de LaunchSafe ont publié Adaptive Evaluation of Out-of-Band Defenses Against Prompt Injection in LLM Agents. L’article formule un constat inconfortable sur les défenses dont le domaine est aujourd’hui le plus optimiste. Un agent outillé lit du texte qu’il ne contrôle pas — une page web, un ticket de support, un PDF, le corps d’un e-mail — et lorsqu’un attaquant y glisse des instructions, le résultat n’est pas une phrase malvenue mais une action : un enregistrement divulgué, une ligne supprimée, un virement. Dans un agent doté d’outils, l’injection de prompt est un problème d’autorisation, pas un problème de contenu.

La première génération de défenses la traitait comme un problème de contenu — classifieurs d’entrée, modèles garde-fous, fine-tuning adverse. Fin 2025, cette approche avait un mode d’échec documenté : Nasr et al. ont pris douze défenses in-band publiées, la plupart annonçant un taux de succès quasi nul, et ont récupéré un taux supérieur à 90 % pour la plupart d’entre elles avec des attaques adaptatives et conscientes de la défense. La seconde génération a déplacé l’application hors du modèle — CaMeL, FIDES, Progent, RTBAS, Conseca, FORGE — via une politique déterministe qui décide quelles actions sont permises, quoi qu’on ait fait dire au modèle. L’alerte de l’article : ces défenses plus récentes sont validées de la même façon que celles qui ont cédé.

Comment ça marche

Les défenses hors bande sont, selon les auteurs, une redécouverte de primitives de sécurité des années 1970 : l’intégrité de Biba (lire une donnée non fiable abaisse le sujet ; un sujet abaissé ne peut autoriser une action de haute intégrité), le moniteur de référence (médiatiser chaque action, être infalsifiable, rester assez petit pour être vérifié), le moindre privilège de Saltzer–Schroeder, et les capacités / contrôle de flux d’information. La leçon récurrente des débordements de tampon, de l’injection SQL et du XSS est identique : la détection a perdu, la structure a gagné, et cette structure vivait hors du canal contrôlé par l’attaquant. Le langage naturel n’a pas de grammaire pour séparer code et données ; cette séparation ne peut donc pas être appliquée à l’intérieur du modèle et doit l’être autour de lui.

Les chiffres annoncés sont impressionnants. Progent fait passer le succès de l’injection indirecte sur le benchmark AgentDojo de 39,9 % à 1,0 % ; CaMeL résout 77 % des tâches d’AgentDojo sous attaque sans aucune injection réussie dans son modèle de menace. Mais chacun de ces chiffres provient d’un benchmark statique — un jeu fixe de tentatives d’injection choisi avant que la défense n’existe. C’est exactement la méthode qui mesurait la « résistance à un jeu d’attaques connu » et qu’on a lue à tort comme une « résistance aux attaquants ».

Pour commencer à combler l’écart, les auteurs ont mené une évaluation adaptative contre Progent sur un agent open-weight (Qwen2.5-7B, auto-hébergé sur un seul H200) — un cadre que les auteurs de Progent n’avaient pas testé. Sur trois exécutions, la barrière déterministe a tenu : le taux de succès moyen a chuté d’environ six fois (25,8 % à 4,2 %), et une attaque adaptative fabriquée à la main, visant le modèle de rédaction de politique de Progent, ne l’a pas relevé (2,6 %). Le résultat se situe dans la même fourchette basse rapportée par les auteurs de Progent, et suggère qu’une barrière déterministe est une cible plus difficile par nature qu’un classifieur — l’attaquant doit conduire une action conséquente en respectant la politique, et pas seulement tromper un détecteur.

Pourquoi c’est important

La lecture honnête : il s’agit d’un point de données, pas d’un verdict. Les auteurs sont explicites : une seule défense, un seul modèle open-weight faible, un seul modèle d’attaque en boîte noire. Aucune attaque optimisée en boîte blanche (GCG) n’a été lancée, ni aucune attaque restreinte aux outils déjà autorisés. Un biais probable : le cadrage « déguiser en bénin » a aussi affaibli l’instruction visant l’agent, si bien que le faible chiffre reflète peut-être autant une attaque faible qu’une défense forte.

Ce qui tient quoi qu’il arrive, c’est l’avertissement méthodologique. La confiance dans les défenses hors bande repose aujourd’hui sur la méthode d’évaluation même dont l’angle mort a été démontré pour les défenses in-band. Plusieurs limites tiennent aussi par construction : la médiation d’action ne fait rien contre les nuisances texte-à-texte (un résumé empoisonné), l’attribution de provenance est une base de confiance sous-spécifiée, les tâches « dans la boucle » retombent sur l’aval de l’utilisateur (avec sa fatigue d’approbation), et CaMeL démontre des canaux auxiliaires fonctionnels contre lui-même. La protection n’est pas gratuite non plus — les exécutions défendues ont coûté environ 15× plus d’appels au modèle et fait chuter l’utilité des tâches de ~45 % à ~26 %.

Défenses

Pour les équipes qui construisent ou achètent de la sécurité d’agents, l’article est autant un guide d’achat et de test qu’une note de recherche.

• Privilégiez la médiation d’action déterministe et hors bande. Un moniteur de référence à la frontière des outils est une base plus saine que n’importe quel classifieur ou garde-fou au niveau du modèle. La barrière qui décide ne doit pas être elle-même un modèle.
• Ne prenez pas les chiffres de benchmark statique pour des garanties. Un titre « 39,9 % → 1,0 % » décrit des attaques choisies avant l’existence de la défense. Exigez des fournisseurs une évaluation adaptative, consciente de la défense, incluant des attaques optimisées et confinées aux actions déjà autorisées.
• Verrouillez la provenance. Toute l’approche repose sur l’étiquetage correct des entrées de confiance. Précisez exactement quel en-tête, quel segment ou quel agent amont fixe l’intégrité — une étiquette oubliée qui bascule sur « fiable » par défaut casse l’invariant à la source.
• Maintenez la défense en profondeur. Les filtres in-band gardent une valeur comme couche contre les attaques non adaptatives ; ne les traitez simplement pas comme une frontière.
• Budgétez le coût. Attendez-vous à un coût jetons/latence nettement plus élevé et à une perte d’utilité, et surveillez le taux de demandes d’aval comme signal d’ergonomie et d’exposition.
• Réduisez le rayon d’impact. Moindre privilège sur les outils, limitation des sorties réseau et surveillance des actions conséquentes anormales bornent ce qu’une injection réussie peut faire, même si le moniteur est contourné.

Statut

Élément	Détail
Publication	Adaptive Evaluation of Out-of-Band Defenses (LaunchSafe), 25 juin 2026
Défenses étudiées	CaMeL, FIDES, Progent, RTBAS, Conseca, FORGE (hors bande)
Cible empirique	Progent sur Qwen2.5-7B, AgentDojo (banking/slack/workspace), 3 exécutions
Résultat clé	ASR moyen 25,8 % → 4,2 % (défendu) → 2,6 % (adaptatif) ; barrière tenue
Coût	~15× plus d’appels au modèle ; utilité ~45 % → ~26 %
Menace ouverte	Attaque optimisée en boîte blanche, et attaques confinées aux actions autorisées — non testées

Le message n’est pas « ces défenses sont brisées ». C’est l’inverse de ce que les attaques adaptatives ont fait aux défenses in-band — mais sur la foi d’une seule attaque faible contre un seul modèle faible, cela n’établit pas encore que l’application hors bande tiendra face à un attaquant adaptatif sérieux et optimisé. Cette évaluation reste le travail que le domaine se doit à lui-même.