SlotGCG : la position du token adverse, pas seulement son contenu, conditionne le jailbreak

De quoi s’agit-il ?

SlotGCG est une technique de jailbreak par optimisation publiée sur arXiv en juin 2026 (2606.05609) par des chercheurs de l’université Dongguk, à Séoul. Elle remet en cause une hypothèse ancienne des attaques par suffixe adverse : que le suffixe — la fin du prompt — serait le meilleur endroit où placer des tokens adverses optimisés.

L’attaque de référence ici est GCG (Greedy Coordinate Gradient, Zou et al., 2023), qui ajoute en fin de prompt une chaîne de tokens optimisés par gradient pour pousser un modèle aligné à obtempérer. Toutes les variantes de GCG depuis ont conservé ces tokens en queue. Le constat de SlotGCG est simple et dérangeant : l’endroit où l’on insère les tokens adverses compte autant que leur contenu, et le suffixe n’est souvent pas la position la plus vulnérable.

Comment ça marche

Le papier généralise le point d’insertion via la notion de slot (emplacement). Pour un prompt de longueur L, il existe L+1 slots candidats — un avant le premier token, un entre chaque paire de tokens, et un après le dernier. GCG n’utilise jamais que le dernier slot.

SlotGCG évalue à la place tous les slots avec un Vulnerable Slot Score (VSS), une métrique estimant la susceptibilité de chaque position à l’insertion adverse, puis concentre l’optimisation sur les slots les mieux notés. La procédure est agnostique à l’attaque : c’est un module de recherche de position que, selon les auteurs, on peut greffer sur n’importe quelle attaque par optimisation, pour un surcoût d’environ 200 ms de prétraitement.

Aucun payload n’est reproduit ici — la référence canonique est le papier lui-même. C’est la forme conceptuelle qui importe :

GCG classique : [ requête nuisible ] [ suffixe optimisé ]
                                     └── uniquement ici

SlotGCG :       [ ... ] [REDACTED] [ ... ] [REDACTED] [ ... ]
                        └── inséré aux slots à VSS le plus élevé,
                            qui ne sont généralement PAS le suffixe

Deux résultats de l’étude exploratoire constituent le vrai sujet :

• Les slots vulnérables suivent l’attention du modèle. Les positions les plus faciles à attaquer sont fortement corrélées au schéma d’attention du modèle sur l’entrée. Elles restent vulnérables même quand les tokens insérés changent — autrement dit, la faiblesse est une propriété de la position, pas d’une chaîne magique particulière. Chaque prompt, soutiennent les auteurs, contient intrinsèquement ses propres slots vulnérables.
• Les gains sont mesurables. En moyenne sur les méthodes de type GCG et les modèles testés, le choix de slots à VSS élevé apporte environ 14 % de taux de succès d’attaque (ASR) en plus, converge en moins d’étapes d’optimisation et — point crucial pour la défense — conserve 42 % de succès en plus face aux défenses par filtrage d’entrée.

Pourquoi c’est important

Le titre n’est pas « un nouveau jailbreak ». GCG est public depuis 2023. Le titre, c’est que toute une classe de défenses a été implicitement réglée au mauvais endroit.

Beaucoup de garde-fous concrets supposent que le bruit adverse se trouve en fin de prompt : contrôles de perplexité pondérés vers la queue, suppression de suffixe, « on coupe tout ce qui suit la question de l’utilisateur ». SlotGCG répartit les perturbations sur des slots corrélés à l’attention tout au long du prompt, ce qui explique précisément qu’il conserve 42 % de son efficacité contre un filtrage d’entrée qu’une attaque suffixe-seul perdrait. Si votre défense en entrée a été validée contre du GCG vanille, cette validation ne se transpose peut-être pas.

La corrélation avec l’attention compte aussi pour la recherche en détection. Elle suggère que la vulnérabilité est structurelle — liée à la façon dont le transformeur pondère son entrée — plutôt qu’un caprice d’un suffixe optimisé particulier. Bonne nouvelle pour les défenses fondées sur des principes (il existe un signal à surveiller), mauvaise nouvelle pour celles qui font du pattern-matching (il n’y a pas de chaîne fixe à bloquer).

Précision de périmètre : GCG et SlotGCG sont des attaques boîte blanche nécessitant un accès au gradient ; la cible directe est donc les modèles à poids ouverts que vous hébergez ou affinez vous-même. Le travail original sur GCG a montré que les suffixes optimisés peuvent se transférer vers des modèles fermés, mais la recherche de position de SlotGCG est une procédure boîte blanche. Voyez-la d’abord comme un outil de red teaming plus tranchant contre les modèles que vous exploitez, et comme la preuve que l’alignement seul n’est pas un contrôle de déploiement.

Défenses

1. Cessez de ne défendre que le suffixe. Appliquez les contrôles de perplexité et d’anomalie sur toute la séquence, avec une fenêtre glissante, pas seulement la queue. Les 42 % de succès conservés par SlotGCG existent justement parce que les filtres centrés sur le suffixe ratent les perturbations au milieu du prompt.
2. Transformez l’entrée, pas seulement la détection. Le paraphrasage et la re-tokenisation (Jain et al., 2023) cassent les arrangements de tokens fragiles et dépendants de la position dont dépendent ces attaques, car ils déplacent ou réécrivent les slots ciblés. Cela coûte en qualité de sortie : à réserver aux chemins à haut risque.
3. Surveillez l’attention, pas les chaînes. Puisque les slots vulnérables sont corrélés à la concentration de l’attention, la détection d’anomalies sur le schéma d’attention est un signal plus durable que le blocage de suffixes. C’est encore au stade recherche, mais c’est la direction qu’indique le résultat.
4. Empilez les défenses. Associez les mesures en entrée à des classifieurs de refus/sûreté en sortie et au filtrage des appels d’outils, pour qu’une génération jailbreakée doive encore franchir un second contrôle avant de produire un préjudice ou de déclencher une action.
5. Encadrez les déploiements à poids ouverts et affinés. L’accès au gradient boîte blanche est la condition de cette attaque. Les modèles auto-hébergés sont la cible réaliste : placez-les derrière des garde-fous d’exécution et de la surveillance, plutôt que de vous fier à leur alignement intégré.
6. Re-testez vos garde-fous avec des attaques à position variable. Si votre harnais de red team ne lance que du GCG suffixe, ajoutez-y l’insertion à slot variable. Un garde-fou qui résiste au GCG vanille peut échouer ici.

État des lieux

Élément	Référence	Date	Notes
SlotGCG	arXiv 2606.05609	2026-06	Module de recherche de position ; métrique VSS ; +14 % d’ASR, +42 % d’ASR face au filtrage d’entrée
GCG (référence)	arXiv 2307.15043	2023-07	Optimisation adverse suffixe-seul ; l’hypothèse que SlotGCG casse
Défenses de base	arXiv 2309.00614	2023-09	Détection par perplexité, paraphrase, re-tokenisation, entraînement adverse

À retenir pour la défense : un filtre d’entrée ne vaut que les positions qu’il inspecte. SlotGCG rappelle que « l’attaque est à la fin du prompt » a toujours été une hypothèse — et c’est dans les hypothèses que les garde-fous lâchent en silence.