LLM salting : faire pivoter la direction de refus pour casser la réutilisation des jailbreaks

De quoi s’agit-il ?

Le LLM salting est une technique défensive légère dévoilée par SophosAI à CAMLIS 2025 (Arlington, Virginie) — une présentation intitulée « LLM Salting: From Rainbow Tables to Jailbreaks », donnée le 22 octobre 2025 par Tamás Vörös, suivie d’un article détaillé publié le 24 octobre 2025. C’est une défense, pas une attaque — et elle vise un problème que ce site documente depuis des mois côté offensif : les jailbreaks qui se transfèrent à tous les déploiements bâtis sur le même modèle de base.

Nous le couvrons maintenant car il s’agit de la contrepartie défensive de résultats offensifs récents publiés ici : les jailbreaks se transfèrent via des représentations partagées et le comportement de refus suit des directions récupérables. Le salting s’attaque à la même géométrie — mais pour protéger le modèle plutôt que pour le casser. Bien qu’il s’agisse d’une idée simple et fondamentale, il n’avait pas encore d’entrée dédiée ici.

Comment ça marche

Commençons par l’économie de l’attaque. Des LLM comme GPT, Claude, Gemini ou LLaMA sont déployés avec peu de personnalisation : des milliers d’applications grand public reposent donc sur une poignée de classes de modèles. Cette homogénéité signifie qu’un jailbreak qui contourne le garde-fou de refus d’un modèle de base peut être calculé une fois et rejoué partout — exactement la structure d’une attaque par rainbow table en cassage de mots de passe, où une seule table précalculée casse de multiples cibles.

Le salting reprend la parade utilisée pour les mots de passe. Pour les mots de passe, un « sel » propre à chaque utilisateur rend une table précalculée inutile, car chaque empreinte devient différente. Pour les LLM, la cible équivalente est la direction de refus : des travaux récents d’interprétabilité ont montré que le comportement de refus est largement gouverné par une seule direction dans l’espace des activations (arXiv:2406.11717). Les jailbreaks trouvent, en pratique, un moyen d’éloigner les activations de cette direction.

Le LLM salting est une petite étape de fine-tuning ciblé qui fait pivoter cette direction de refus d’une quantité propre à chaque copie. Le modèle refuse toujours les mêmes choses — capacités générales et précision sur les requêtes bénignes sont préservées — mais un jailbreak optimisé contre le modèle de base non salé vise désormais la mauvaise direction et cesse de se transférer. Les adversaires sont contraints de recalculer leur attaque contre chaque copie salée, ce qui détruit l’économie un-vers-plusieurs qui rendait les jailbreaks transférables rentables. Dans les expériences de SophosAI (sur des modèles dont LLaMA2-7B-Chat et Vicuna-7B), le salting a réduit le succès des jailbreaks plus efficacement qu’un fine-tuning standard ou des modifications de prompt système, sans dégrader la précision.

Pourquoi c’est important

La plupart des discussions sur les garde-fous portent sur le fait qu’un modèle refuse ou non. Le salting recentre la question sur la transférabilité — la propriété qui transforme le prompt astucieux d’un chercheur en incident à l’échelle d’une flotte. Pour toute organisation exploitant un assistant grand public sur un modèle de base répandu, la menace réaliste n’est pas que quelqu’un découvre un jailbreak inédit contre vous ; c’est que quelqu’un rejoue un jailbreak public déjà prêt qui fonctionne contre votre modèle de base. Le salting vise précisément ce risque de rejeu.

Deux réserves honnêtes. D’abord, le salting est une étape de durcissement par déploiement pour les modèles que vous pouvez fine-tuner — il convient bien mieux à des modèles à poids ouverts ou auto-hébergés qu’à une API fermée que vous ne faites qu’appeler. Ensuite, il augmente le coût de l’attaque plutôt que d’en prouver l’impossibilité ; un adversaire disposant d’un accès par requêtes peut toujours monter une attaque fraîche et adaptative contre une copie salée. C’est exactement pourquoi cette technique relève d’une stratégie en couches, et non d’un correctif autonome — un point renforcé par des travaux récents montrant que les défenses d’agents ne se composent pas toujours et que les attaquants adaptatifs cassent les défenses statiques.

Défenses

Le salting est une défense ; la consigne pratique porte donc sur son déploiement et ce qu’il faut lui adjoindre.

1. Salez chaque déploiement, avec une rotation différente. La valeur vient de la variation propre à chaque copie : des sels identiques sur plusieurs déploiements recréent le problème de cible partagée. Traitez la rotation comme un secret propre à l’instance.
2. Vérifiez la préservation des capacités. Relancez vos benchmarks de précision bénigne et de refus après le salting pour confirmer que la rotation n’a pas dégradé l’utilité ni sur-déclenché les refus.
3. Combinez-le avec des contrôles d’entrée/sortie. SophosAI présente le salting comme complémentaire du filtrage de prompt et du rejet par classifieur — voir le filtrage de sortie et les approches par détecteur. Le salting émousse la réutilisation ; les classifieurs attrapent les motifs connus ; aucun ne suffit seul.
4. Continuez les tests adaptatifs. Comme un attaquant déterminé peut recalculer contre une copie salée, évaluez avec du red teaming itératif fondé sur l’optimisation, et traitez tout succès résiduel comme un constat plutôt que comme du bruit.
5. Re-salez après réentraînement. Tout fine-tune ou mise à jour du modèle peut déplacer la géométrie du refus ; intégrez un nouveau sel au pipeline de déploiement pour que la rotation ne dérive pas vers le modèle de base.

État des lieux

Élément	Référence	Date	Notes
Annonce du LLM salting	SophosAI / présentation CAMLIS 2025	2025-10-22	« LLM Salting: From Rainbow Tables to Jailbreaks » (T. Vörös)
Article détaillé	Sophos News	2025-10-24	Fine-tuning léger ; rotation de la direction de refus
Résultat sous-jacent	arXiv:2406.11717	2024	Comportement de refus médié par une seule direction d’activation
Modèles testés	Expériences SophosAI	2025	Dont LLaMA2-7B-Chat, Vicuna-7B ; surpasse fine-tuning / prompt système
Portée	—	—	Adapté aux modèles fine-tunables / auto-hébergés ; augmente le coût, pas l’impossibilité

L’enseignement est une inversion utile de la conversation habituelle sur les jailbreaks. Vous ne pourrez sans doute pas empêcher un attaquant suffisamment motivé de jailbreaker une copie de votre modèle. Mais vous pouvez l’empêcher de jailbreaker toutes les copies avec un seul prompt précalculé — et pour une flotte de déploiements quasi identiques, cette différence représente l’essentiel du risque réel.

Cet article résume des travaux défensifs rendus publics par un éditeur, à des fins éducatives. Il décrit une technique de mitigation et ne reproduit aucun code d’exploitation ni prompt de jailbreak.