Résumé Technique : Fair ASR : Réévaluation des Jailbreaks Black-Box sous Budgets de l'Appel de Cible Partagés

1. Énoncé du Problème

Les évaluations actuelles des attaques de type « jailbreak » sur les grands modèles de langage (LLM) reposent principalement sur le taux de réussite de l'attaque (ASk - Attack Success Rate), mais ne tiennent souvent pas compte du budget d'attaque requis pour atteindre ce succès. Les études existantes rapportent fréquemment des valeurs d'ASR terminales obtenues sous des contraintes de ressources inégales, menant à des comparaisons injustes où l'efficacité d'une méthode est confondue avec la quantité d'accès à la cible qu'elle utilise.

Bien que des évaluations récentes « conscientes du calcul » tentent de normaliser les budgets en agrégeant les ressources en un scalaire unifié (ex: FLOPs), cette approche présente des limitations significatives pour les scénarios black-box :

1. Invisibilité : Les FLOPs d'inférence pour les modèles fermés sont généralement indisponibles et doivent être estimés.
2. Non-interchangeabilité : Les FLOPs réduisent des contraintes de ressources distinctes (ex: limites de débit d'API vs coût de calcul) en une seule métrique, occultant les réalités opérationnelles où l'accès au modèle cible est le principal goulot d'étranglement en raison des limites de débit et de la détection d'abus.

Par conséquent, il existe un manque de base comparable et observable pour évaluer les attaques black-box hétérogènes.

2. Méthodologie : Protocole Fair-ASR

Pour répondre à ces problèmes, les auteurs introduisent le Fair-ASR, un protocole d'évaluation qui standardise les comparaisons sous des budgets d'appels de cible partagés ($B$).

Principes Fondamentaux

• Budget Primaire ($B$) : Le protocole utilise le nombre d'appels de cible (requêtes au modèle victime) comme budget primaire. Ce choix se justifie par le fait que :
  • Il est universel pour toutes les attaques black-box (chaque attaque doit interroger la cible).
  • Il reflète les contraintes opérationnelles (limites de débit, suspensions de comptes).
  • Il est directement observable, contrairement aux FLop pour les API fermées.
• Métrique Secondaire : Les appels d'attaquant (requêtes à un LLM attaquant ou à un juge auxiliaire) sont suivis séparément pour analyser les compromis d'efficacité, plutôt que d'être agrégés dans le budget primaire.
• Métriques d'Évaluation :
  • ASR@B : La fraction de requêtes nuisibles attaquées avec succès en au plus $B$ appels de cible.
  • Courbe ASR-Budget : La trajectoire de l'ASR à mesure que $B$ augmente, révélant les taux de croissance et les points de saturation.
  • Appels de Cible Moyens (ATC - Average Target Calls) : Le nombre moyen d'appels de cible consommés par attaque réussie.
  • Score de Nuisibilité (HS - Harmfulness Score) : Une métrique de qualité (utilisant la rubrique StrongREJECT) évaluant la gravité et le caractère convaincant de la réponse nuisible.

Portée Expérimentale

Les auteurs ont réévalué 11 attaques représentatives à travers trois catégories :

1. Templates façonnés à la main : CodeAttack, DeepInception, CipherChat.
2. Échantillonnage répété stochastique : Best-of-N (BoN).
3. Attaques automatisées pilotées par LLM : PAIR, TAP, ReNeLLM, AutoDAN, GPTFuzzer, AutoDAN-Turbo, Rainbow Teaming.

Les expériences ont été menées sur divers modèles cibles (Llama-3.1, gpt-oss, GPT-4o, GPT-5, Gemini-3.1-Pro, Claude-Sonnet-4.6) en utilisant des jeux de données standards (HarmBench, JailbreakBench).

3. Principales Conclusions de la Réévaluation

L'application de Fair-ASR a révélé trois enseignements critiques :

1. Classements dépendants du budget : Les classements des attaques sont hautement sensibles au budget d'appels de cible. Les méthodes qui semblent supérieures sous de larges budgets peuvent être surpassées par des méthodes plus simples sous des budgets serrés. Par exemple, sur Llama-3.1-8B, TAP mène BoN à $B=5$, mais BoN dépasse TAP à $B=100$.
2. Compétitivité des primitives simples : Les primitives d'attaque simples restent très compétitives sous un accès égal à la cible.
   • Perturbation stochastique : BoN continue de s'améliorer avec des appels de cible supplémentaires, atteignant un ASR élevé sans aucun appel de modèle attaquant.
   • Templates façonnés à la main : Les templates structurés (ex: CodeAttack) atteignent des taux de réussite élevés avec très peu d'appels de cible (ex: 62 % d'ASR à $B=1$), surpassant souvent les méthodes complexes pilotées par LLM dans les régimes à faible budget.
3. Compromis d'efficacité : Aucune méthode pilotée par LLM évaluée n'est uniformément efficace tant en appels de cible qu'en appels d'attaquant.
   • ReNeLLM atteint une grande efficacité de l'appel de cible (faible ATC) mais incurre des coûts élevés en appels d'attaquant en raison de la réécriture itérative et des portes de nuisance basées uniquement sur le prompt.
   • D'autres méthodes (ex: PAIR, TAP) peuvent utiliser moins d'appels d'attaquant mais nécessitent nettement plus d'appels de cible pour atteindre des seuils de réussite similaires.

4. Solution Proposée : ReCode

Motivés par l'identification de cet « écart d'efficacité bidimensionnel », les auteurs proposent ReCode, une attaque compositionnelle conçue pour maximiser l'ASR tout en minimisant les appels de cible et d'attaquant.

Architecture de Conception

ReCode combine trois composants dans un pipeline à passage unique :

1. Réécriture de désensibilisation sans porte (Gate-free) : Contrairement à ReNeLLM, qui utilise une porte de nuisance basée uniquement sur le prompt pour filtrer les réécritures (déclenchant des tentatives coûteuses), ReCode effectue une réécriture en un seul passage utilisant des stratégies de désensibilisation (ex: réécriture littéraire, substitution d'objectif) sans boucle de juge auxiliaire.
2. Perturbation stochastique sans attaquant : Le prompt réécrit subit des perturbations au niveau des caractères (ex: inversion de casse, insertion d'ASCII) similaires à BoN, ne nécessitant aucun appel supplémentaire de l'attaquant.
3. Emboîtement structuré de style code : Le prompt perturbé est intégré dans un template structuré de style code (ex: définitions de classes Python), masquant davantage l'intention sans nécessiter de raffinement par un modèle attaquant.

Résultats

Évalué sous un budget de $B=20$ appels de cible :

• Performance : ReCode a atteint un ASR moyen de 81,0 % sur cinq modèles cibles (incluant des variantes de gpt-oss) et 70,3 % sur les trois modèles fermés de pointe (GPT-5, Gemini-3.1-Pro, Claude-Sonnet-4.6).
• Efficacité : Il a nécessité une moyenne de seulement 7,00 appels d'attaquant par requête (AAC), ce qui est nettement inférieur à ReNeLLM (18,69) et TAP (49,56).
• Gains spécifiques : Sur GPT-5, ReCode a amélioré l'ASR de 31 % (ReNeLLM) à 85 % tout en réduisant les appels d'attaquant de 26,02 à 7,19.
• Nuisibilité : ReCode a également obtenu le score de nuisance (HS) moyen le plus élevé de 0,662, indiquant que des taux de réussite plus élevés sont corrélés à des réponses nuisibles de meilleure qualité.

5. Signification et Revendications

L'article affirme que Fair-ASR fournit une base de référence observable et nécessaire pour comparer les jailbreaks black-box, corrigeant les conclusions trompeuses tirées de comparaisons de budgets inégaux. Il démontre que la complexité algorithmique ne garantit pas l'efficacité et que les primitives simples et à faible coût sont souvent sous-utilisées.

L'introduction de ReCode sert de preuve de concept montrant qu'il est possible de combler l'écart d'efficacité en combinant la réécriture de désensibilisation avec des techniques d'obscurcissement sans attaquant. Les auteurs concluent que les évaluations futures doivent aller au-delà de l'ASR terminal pour considérer l'efficacité conjointe des ressources (appels de cible et d'attaquant) afin d'évaluer précisément le paysage de la sécurité des LLM.

Limites notées :

• Le protocole se concentre actuellement sur les attaques à un seul tour et ne couvre pas encore les configurations multi-tours.
• Les appels de cible ne capturent pas l'utilisation des tokens, les prix des API ou le coût manuel du développement de templates.
• L'étude reconnaît que, bien que ReCode soit efficace, les comportements spécifiques des modèles (ex: la sensibilité de Claude à l'emboîtement de code) peuvent varier, nécessitant des recherches plus approfondies.