Détecteurs d'injection de prompt : il faut des politiques de décision, pas seulement de meilleurs scores

De quoi s’agit-il ?

Les détecteurs d’injection de prompt sont généralement évalués comme de simples classifieurs binaires. Or une application en production doit prendre une décision plus concrète : autoriser l’entrée, la bloquer, ou l’escalader vers un humain ou un modèle plus puissant. Un préprint soumis à arXiv le 14 octobre 2026 (arXiv:2610.20907, « From Detection to Decision: Calibration and Deferral for Prompt-Injection Detection », par Qianlong Lan, Anuj Kaul, Vinothini Pandurangan et Indranil Sanyal) étudie directement cette couche de décision.

Ce qu’il faut retenir : un détecteur qui produit des probabilités n’est pas automatiquement un détecteur auquel on peut confier le filtrage du trafic, surtout lorsque ce trafic diffère des données d’entraînement.

Comment cela fonctionne

Les auteurs évaluent quatre systèmes sur un jeu de test de 47 611 exemples issus de TensorTrust, BIPIA, NotInject et PIDS-Bench v3 : un modèle de décision probabiliste hébergé (Jev), deux classifieurs Llama Prompt Guard 2 (22M et 86M de paramètres) et un LLM juge. Meta décrit Prompt Guard 2 comme un classifieur de type BERT qui ne renvoie que les étiquettes « benign » ou « malicious » et dispose d’une fenêtre de contexte de 512 tokens.

Trois dimensions sont mesurées. La discrimination (AUROC) : le LLM juge obtient 0,897, Jev 0,871, Prompt Guard 2 86M 0,757 et le modèle 22M 0,714. La calibration : les probabilités natives de Jev ne sont pas systématiquement meilleures que celles de Prompt Guard 2 après mise à l’échelle par température, laquelle améliore les métriques de calibration sans modifier la discrimination. Le comportement des politiques : les auteurs construisent des politiques autoriser / bloquer / différer où les entrées incertaines sont transmises à un évaluateur LLM figé.

Le résultat marquant concerne le coût. Pour ramener le taux de faux négatifs du système à 1 % ou moins, chaque combinaison filtre + évaluateur a dû escalader plus de 91,8 % des entrées, ne laissant qu’environ 7 à 8 % de traitement automatique, avec des taux de faux positifs système d’environ 40 à 46 % et une latence moyenne proche de 3,7 à 3,9 secondes. Les auteurs affirment que les sorties probabilistes seules n’établissent pas de décisions de sécurité fiables en cas de décalage de distribution.

Limites signalées par l’article lui-même : le jeu de test agrégé comporte environ 88 % d’attaques et est dominé par BIPIA, Jev a été testé comme modèle hébergé avec un seul prompt, les estimations sont ponctuelles sans intervalles de confiance, et l’étude mesure la détection et le routage, non la compromission de bout en bout d’un agent.

Pourquoi c’est important

De nombreuses équipes placent un petit classifieur devant un agent et traitent son score comme un contrôle de sécurité. Cette étude montre que le score n’est que la première entrée d’une politique. Si la confiance du classifieur est mal calibrée sur votre trafic, des seuils choisis sur un benchmark public peuvent bloquer des utilisateurs légitimes ou laisser passer des attaques, et un évaluateur réglé pour très peu d’oublis peut signaler presque tout. Le coût opérationnel, et pas seulement la précision, détermine si le contrôle est utilisable.

Défenses

• Mesurez la calibration et les taux d’erreur sur votre propre trafic, pas uniquement sur des benchmarks publics, et recommencez après tout changement de modèle ou de prompt.
• Rapportez les faux positifs à côté des faux négatifs : un filtre qui manque peu d’attaques mais bloque trop sera contourné par les utilisateurs ou désactivé par les opérateurs.
• Adoptez une politique à trois issues (autoriser, bloquer, différer) et dimensionnez explicitement le budget de revue, latence comprise, avant de fixer les seuils.
• Testez séparément le point de fonctionnement de l’évaluateur : un évaluateur calibré pour zéro oubli peut transformer l’ensemble en filtre qui bloque tout.
• Examinez les résultats par jeu de données ou segment de trafic, car les métriques agrégées peuvent masquer des effets de composition.
• Considérez le détecteur comme une couche parmi d’autres : associez-le au moindre privilège pour les outils, à la confirmation des actions sensibles et au filtrage des sorties, afin qu’une injection manquée ne devienne pas une injection réussie.
• Pour Prompt Guard 2, suivez les recommandations de Meta : découpez les entrées de plus de 512 tokens en segments et envisagez un affinage sur des données propres à l’application.

Status

Élément	Détail
Type de source	Préprint arXiv (cs.CR), pas encore évalué par les pairs
Soumission	14 octobre 2026
Systèmes évalués	Jev, Llama Prompt Guard 2 (22M, 86M), LLM juge
Vulnérabilité / CVE	Aucune ; il s’agit d’une étude d’évaluation
Remédiation	Opérationnelle : calibrer, définir une politique de report, superposer les contrôles