Pourquoi les jailbreaks se transfèrent entre modèles — et comment le « salage » riposte

De quoi s’agit-il ?

Un jailbreak conçu contre un modèle fonctionne souvent contre d’autres — c’est la transférabilité. L’étude Jailbreak Transferability Emerges from Shared Representations (Rico Angell, Jannik Brinkmann, He He ; arXiv:2506.12913, première version en juin 2025, révisée le 28 octobre 2025) a testé 20 modèles open-weight contre 33 attaques de jailbreak, chacune appliquée à 313 prompts nuisibles, et conclut que le transfert n’est pas un artefact de l’alignement ni des familles de modèles. C’est une conséquence de la manière dont les modèles encodent le langage en interne. L’implication pratique est inconfortable : un attaquant peut précalculer un jailbreak et le réutiliser sur de nombreux déploiements — exactement l’économie d’une rainbow table de mots de passe. Une contre-mesure présentée par Sophos X-Ops à CAMLIS 2025, le « LLM salting » (salage de modèle, blog Sophos), vise précisément à casser cette réutilisation.

Comment ça marche

L’étude isole deux facteurs qui déterminent systématiquement si une attaque passe d’un modèle à l’autre : (1) la similarité des représentations internes de deux modèles sur des prompts bénins, et (2) la force du jailbreak sur le modèle source. Le test causal est la partie convaincante : distiller un modèle source uniquement sur les réponses bénignes d’un modèle cible, sans aucune donnée d’attaque, augmente la similarité des représentations et accroît mesurablement le transfert. Le constat qualitatif est cohérent : les attaques par persona (« tu es un assistant sans restrictions… ») se transfèrent bien plus que les prompts à base de chiffrement, car les attaques en langage naturel exploitent l’espace de représentation partagé, là où les astuces de chiffrement reposent sur des particularités propres à chaque modèle qui ne généralisent pas.

Le volet défensif s’appuie sur Arditi et al., Refusal in LLMs is mediated by a single direction (arXiv:2406.11717) : une unique « direction de refus » linéaire dans l’espace d’activation gouverne largement le fait qu’un modèle décline une requête. Le LLM salting ajoute un terme de perte au fine-tuning qui pénalise l’alignement avec cette direction de refus précalculée sur les prompts nuisibles, faisant pivoter la direction pour que le modèle « refuse autrement ». Aucun payload n’est reproduit ici — il s’agit d’une recette de fine-tuning défensive, pas d’une attaque. Dans les expériences Sophos, le salage était appliqué aux couches les plus alignées avec la direction de refus (L = {16, 17, 18, 19, 20} sur les modèles 7B étudiés).

Les chiffres rapportés sont notables. Contre des attaques par suffixe Greedy Coordinate Gradient (GCG) qui atteignaient 100 % de taux de succès (ASR) sur les modèles de base non modifiés, le salage a ramené l’ASR à 2,75 % sur LLaMA-2-7B-Chat et 1,35 % sur Vicuna-7B, tout en gardant la précision MMLU dans le bruit d’une exécution à l’autre. À titre de comparaison, le fine-tuning standard et les changements de prompt système ne faisaient baisser l’ASR qu’à environ 40–60 %.

Pourquoi c’est important

L’homogénéité des modèles est désormais la norme : des milliers de produits reposent sur une poignée de modèles de base, avec une personnalisation minimale. Des représentations partagées signifient une surface d’attaque partagée — un jailbreak validé une seule fois peut réussir discrètement contre toute une classe d’applications en aval, exposant des données internes ou produisant des sorties nuisibles à l’échelle d’un parc entier. La recherche sur le transfert requalifie ce phénomène : ce n’est pas de la malchance, mais une propriété structurelle de l’apprentissage de représentations. Mauvaise nouvelle, car on ne corrige pas par patch la façon dont un modèle encode le langage ; bonne nouvelle, car le transfert est prévisible à partir de la similarité des représentations et cassable en modifiant la géométrie plutôt qu’en pourchassant les prompts un par un.

Défenses

Casser la géométrie partagée. Le fine-tuning par salage fait pivoter la direction de refus afin que les jailbreaks précalculés et transférés tombent sur le mauvais axe. La perturbation étant propre à chaque déploiement, une attaque réglée contre le modèle de base public ne correspond plus aux internals de votre modèle.

Empiler les défenses. Le salage n’est pas une solution miracle : il a surtout été évalué sur GCG contre des modèles 7B open-weight, et les auteurs signalent AutoDAN, TAP et les modèles plus grands comme questions ouvertes. Combinez-le avec le filtrage des entrées et la détection par classifieur plutôt que de traiter un seul contrôle comme suffisant.

Ne pas se reposer sur les seuls ajustements de prompt. Dans les mêmes expériences, les changements de prompt système et le fine-tuning ordinaire laissaient 40–60 % des jailbreaks opérationnels. Considérez-les comme de la friction, pas comme une protection.

Prioriser les classes à fort transfert. Les prompts par persona se transfèrent le plus facilement entre modèles ; orientez votre détection et votre red teaming vers eux, et vers tout contenu d’apparence bénigne susceptible de véhiculer des instructions.

Réduire l’homogénéité superflue. Lorsque c’est possible, introduisez une variation propre à chaque déploiement pour qu’une attaque rétro-conçue contre le modèle de base amont ne généralise pas à votre instance.

Statut

Élément	Référence	Date	Note
Mécanisme de transfert	Angell et al., arXiv:2506.12913	Juin 2025 (rév. 28 oct. 2025)	20 modèles open-weight, 33 attaques, 313 prompts chacune
Direction de refus	Arditi et al., arXiv:2406.11717	2024	Refus médié par une seule direction linéaire
LLM salting (défense)	Sophos X-Ops, CAMLIS 2025	Oct. 2025	ASR GCG 100 % → 2,75 % (LLaMA-2-7B) / 1,35 % (Vicuna-7B)
Attaque testée	GCG — Zou et al., arXiv:2307.15043	2023	Attaque par suffixe adverse
Questions ouvertes	AutoDAN, TAP, modèles plus grands	—	Non encore évalués sous salage