Votre garde-fou se trahit : identifier les défenses depuis l'extérieur

De quoi s’agit-il ?

La plupart des déploiements LLM en production placent un garde-fou en amont et en aval du modèle : un classifieur ou un moteur de règles distinct qui inspecte les prompts entrants et les réponses sortantes, et bloque ceux qu’il juge malveillants. Vu de l’extérieur, pourtant, un refus n’est qu’un refus. Lorsque vous envoyez un prompt à un assistant hébergé et qu’il décline, vous ne pouvez généralement pas savoir ce qui a décliné — le garde-fou qui a attrapé une catégorie interdite, ou l’alignement de sécurité propre au modèle qui a choisi de ne pas répondre ?

Un article publié sur arXiv le 2 juillet 2026, Behind the Refusal: Determining Guardrail Activation via Behavioral Monitoring (2607.02121), de William Hackett et Peter Garraghan, montre que cette distinction n’est en réalité pas cachée. Avec un accès en boîte noire et aucune connaissance préalable du système, les auteurs retrouvent si un garde-fou est présent, ce qu’il est réglé pour bloquer, et si un refus donné provient du garde-fou ou du modèle — uniquement en observant le comportement du système.

Comment ça fonctionne

Il s’agit d’un résultat de reconnaissance, pas d’un exploit : il n’y a aucun payload ici, et rien ne contourne une défense. Ce que la méthode fait, c’est mesurer les effets de bord observables qu’un garde-fou séparé introduit dans le cycle requête/réponse. Les auteurs regroupent les signaux qui fuient en trois familles.

• Signaux HTTP. Un garde-fou qui interrompt une requête tôt, renvoie un message de blocage standardisé ou passe par un saut supplémentaire laisse des empreintes dans les codes de statut, les en-têtes et la structure de réponse, différentes d’une complétion normale du modèle.
• Signaux lexicaux. Les messages de blocage d’un garde-fou sont souvent gabaritisés et distincts de la formulation de refus du modèle. La manière de dire « non » porte de l’information sur qui l’a dit.
• Signaux temporels. Une entrée arrêtée par un pré-filtre revient plus vite qu’une entrée qui traverse toute la génération ; une sortie bloquée après génération a sa propre signature de latence. Le temps de réponse sépare les cas.

En combinant ces signaux, l’article rapporte une détection de la présence d’un garde-fou avec 100 % de précision, avec un écart comportemental statistiquement significatif entre interactions bénignes et malveillantes (q < 0,001). Il identifie également les catégories de contenu que le garde-fou est configuré pour attraper et — sur des prompts jamais vus — distingue un blocage de garde-fou d’un refus du modèle avec un score F1 moyen de 98 %.

Pourquoi c’est important

La conséquence pratique touche à l’économie de l’attaque. Comme le notent les auteurs, les techniques pour franchir un garde-fou (un classifieur séparé avec ses propres angles morts) diffèrent nettement de celles qui défont l’alignement de sécurité d’un modèle. Un adversaire capable de déterminer à moindre coût lequel est en jeu, et quelles catégories il surveille, peut choisir la bonne famille de contournement et cesser de gaspiller des requêtes sur la mauvaise. Une reconnaissance qui reposait sur des conjectures devient une sonde rapide et fiable.

Cela fait aussi voler en éclats une hypothèse discrète, présente dans beaucoup de déploiements : que la couche de garde-fou est invisible et que sa configuration est secrète. Elle ne l’est pas. Considérer que « l’attaquant ne sait pas que nous filtrons le contenu » ou « il ne peut pas deviner quelles catégories nous bloquons » relève de la sécurité par l’obscurité, et cet article mesure précisément à quel point cette obscurité est mince. Le résultat est une information défensive : si vous exploitez un garde-fou, partez du principe que sa présence et sa carte de couverture sont découvrables depuis l’extérieur, et concevez le système pour que cette découverte rapporte le moins possible à l’attaquant.

Défenses

Le résultat est un canal auxiliaire ; les mitigations sont donc celles, classiques, des canaux auxiliaires — réduire la différence observable entre les cas.

• Uniformisez les refus. Faites en sorte que les blocages de garde-fou et les refus du modèle se ressemblent côté client : formulation identique ou aléatoire, même statut HTTP et même structure, afin que le « non » ne révèle pas sa source.
• Aplatissez les temps de réponse. Rembourrez ou normalisez la latence pour qu’un blocage rapide par pré-filtre soit indiscernable d’une génération complète. Des réponses en temps constant suppriment la séparation temporelle sur laquelle s’appuie l’attaque.
• Ne comptez pas sur l’obscurité. Supposez que les adversaires savent qu’un garde-fou existe et peuvent cartographier ses catégories. Votre sécurité doit venir de la robustesse réelle du garde-fou et de la défense en profondeur, pas du fait de cacher sa présence.
• Surveillez la reconnaissance. La même séparation comportementale bénin/malveillant qui fuit de l’information est elle-même détectable. Des salves de sondage qui font varier systématiquement les catégories de contenu et mesurent les caractéristiques de réponse sont un signal qui mérite une alerte.
• Continuez à empiler les couches. Un garde-fou identifié n’est pas un garde-fou vaincu. Des contrôles d’entrée et de sortie indépendants, un accès outillé au moindre privilège et une supervision à état élèvent toujours la barre, même quand l’attaquant connaît l’agencement.

Statut

Élément	Détail
Résultat	La présence d’un garde-fou séparé, ses catégories bloquées et l’origine du refus (garde-fou vs modèle) sont récupérables depuis le comportement en boîte noire
Source	Behind the Refusal: Determining Guardrail Activation via Behavioral Monitoring, W. Hackett & P. Garraghan, arXiv, 2 juillet 2026
Signaux	Structure HTTP, formulation du refus (lexical), temps de réponse
Résultat rapporté	100 % de détection de présence ; identification des catégories ; F1 ~98 % pour distinguer blocage de garde-fou et refus du modèle
Accès supposé	Boîte noire, aucune connaissance préalable du système
Type	Étude de reconnaissance / canal auxiliaire (recherche ; pas de CVE)