Les jailbreaks des LLM expliqués : ce qu’un jailbreak modifie, et pourquoi il ne s’agit pas d’abliteration

En juillet 2023, trois chercheurs ont soumis 32 prompts nuisibles à GPT-4 et Claude 1.3 au moyen de 28 attaques différentes. La technique unique la plus puissante — trois familles d’attaques empilées les unes sur les autres — a réussi sur 94 % de l’ensemble contre GPT-4 et sur 81 % contre Claude 1.3. Ce qui a complété le jeu n’était pas une meilleure attaque, mais un choix : un adversaire autorisé à choisir, parmi les 28, celle qui fonctionnait le mieux pour chaque prompt a fait passer les 32 sur les deux modèles, ce que l’article rapporte comme un score parfait de 1,00. L’interprétation inconfortable est qu’un jailbreak n’est pas un défaut qui disparaît lorsque le modèle devient plus intelligent ou mieux comporté. C’est une propriété du prompt, et le prompt appartient à celui qui l’envoie. Ce qui se passe après l’arrêt du refus — l’appel d’outil, la lecture de fichier, la sortie qui atterrit quelque part où elle est traitée — est la partie que l’archive des incidents d’IA a été conçue pour consigner.

Ce cadrage mérite d’être précisé, car « jailbreak » désigne plusieurs choses différentes, et ces différences déterminent ce qu’une mesure d’atténuation peut réellement faire. Cet article traite de ce qu’un jailbreak modifie, de ce que disent réellement les chiffres mesurés, des raisons pour lesquelles il n’existe pas de réponse propre à chaque modèle à la question « peut-on le jailbreaker », et du point où la technique cesse d’être une question de sûreté des modèles pour devenir une question de sécurité des systèmes.

Un jailbreak est une modification du prompt, pas du modèle

Le modèle reste exactement tel que livré. Rien n'est réentraîné, aucun poids n'est modifié, aucun fine-tuning n'est appliqué. L'attaquant modifie la requête de sorte que s'y conformer devienne la continuation localement correcte, et le comportement de sécurité inculqué au modèle cède devant une instruction concurrente qu'il a également été entraîné à suivre.

Cette seule phrase exclut toute une catégorie de corrections supposées. On ne peut pas le corriger au niveau des poids — les poids ne présentent aucun défaut. On ne peut pas l’énumérer, car l’espace des prompts est ouvert. Et on ne peut pas le vérifier une fois pour toutes, car la technique qui échoue aujourd’hui n’est pas celle que l’on essaiera demain. Ce que l’on peut faire, c’est mesurer un taux, sur un ensemble fixe de prompts, par rapport à une version fixe du modèle, puis observer ce taux évoluer lorsque l’un de ces trois éléments change.

Ce que l’expérience à 32 prompts a réellement mesuré

L’étude est Jailbroken : comment l’entraînement de sécurité des LLM échoue-t-il ? par Alexander Wei, Nika Haghtalab et Jacob Steinhardt, publiée sur arXiv en juillet 2023 sous la référence 2307.02483. Son jeu de test comprenait 32 prompts nuisibles — la moitié issus d’une évaluation GPT-4 publiée, l’autre moitié adaptés de travaux publiés de red teaming sur Claude — et sa mesure des résultats est sans détour : un cas est compté comme une réussite lorsque la réponse est à la fois nuisible et sur le sujet de la demande d’origine. Tout ce qui bloque, esquive ou répond à une autre question ne compte pas.

Deux propriétés des résultats sont plus utiles que n’importe quelle ligne individuelle. La première est l’inégalité avec laquelle les attaques se transfèrent entre modèles. Le jeu de rôle AIM a obtenu 0,75 contre GPT-4 et 0,00 contre Claude 1.3. Le few-shot JSON a obtenu 0,53 et 0,00. Pendant ce temps, l’encodage Base64 présentait le type inverse de déséquilibre — 0,34 sur GPT-4 et 0,38 sur Claude 1.3 — et les distracteurs se situaient à 0,44 et 0,47. Une technique contre laquelle un fournisseur s’est clairement entraîné apparaît comme un zéro sur ce modèle et ne dit rien du modèle qui se trouve à côté.

La seconde correspond à ce qui se passe lorsque des familles sont combinées. L’injection de préfixe, la suppression des refus et l’encodage Base64 ont produit 0,56 face à GPT-4 et 0,66 face à Claude 1.3. L’ajout de l’injection de style a fait passer ces scores à 0,69 et 0,84. L’ajout de la génération de contenu de site web et de contraintes de formatage les a fait passer à 0,94 et 0,81. L’empilement est toute l’astuce : chaque couche est quelque chose que le modèle a été entraîné à faire, et la combinaison ne laisse aucune position de jeton où le refus soit la continuation la plus naturelle.

Les modèles de ce tableau ont trois ans et ne sont plus ce que quiconque déploie. Les chiffres ne sont pas l’essentiel ; la forme l’est. Chaque mécanisme du tableau est toujours à l’œuvre dans tous les modèles depuis, parce qu’aucun d’entre eux n’a jamais été un bug dans GPT-4 ou Claude 1.3 — ils sont les conséquences de la façon dont le suivi d’instructions et l’entraînement à la sécurité interagissent.

Deux façons dont la formation à la sécurité échoue

L’explication de l’article est d’une clarté inhabituelle, et c’est la partie qu’il vaut la peine de garder en tête : il existe deux modes de défaillance, et chaque attaque du tableau est un cas de l’un d’eux.

Objectifs concurrentsLes objectifs concurrents, c’est ce que l’on obtient lorsque les capacités d’un modèle et ses objectifs de sécurité pointent dans des directions différentes. Le suivi d’instructions est une capacité. Lorsque la requête est formulée de telle sorte que refuser reviendrait à enfreindre une instruction à laquelle le modèle est fortement entraîné à obéir, le modèle tranche le conflit en faveur de l’instruction. L’injection de préfixe en est la version minimale : dites au modèle que sa réponse doit commencer par « Absolutely! Here's », et les premiers jetons constituent déjà un engagement qui rend le refus incohérent. La suppression de refus s’attaque à la même faille, de l’autre côté, en ajoutant des règles de mise en forme qui interdisent la phrase dans laquelle un refus devrait être rédigé.

Généralisation inadéquate : c’est ce que l’on obtient lorsque l’entraînement de sécurité couvre une distribution d’entrées étroite que la capacité générale du modèle ne couvre pas. Le modèle a appris le Base64 pendant le préentraînement et peut suivre parfaitement une instruction encodée. L’entraînement de sécurité, qui a principalement vu des requêtes en langage naturel, ne lui a jamais appris à reconnaître qu’une requête encodée reste une requête. Le même échec apparaît avec la suppression des voyelles, ROT13, le leetspeak, le fractionnement de charge utile et les tâches de distraction : chacun est un format auquel la capacité généralise, mais pas le comportement de sécurité.

Une fois que vous avez ces deux catégories, les attaques cessent de ressembler à un ensemble disparate d’astuces et commencent à ressembler à deux familles ayant une cause profonde commune — ce qui explique aussi pourquoi elles se combinent si bien. Une invite qui supprime le refus et dissimule son intention dans un encodage exploite les deux modes de défaillance à la fois, et 0.94 est ce à quoi cela ressemble.

Pourquoi il n’existe pas de réponse propre à chaque modèle à la question « peut-on le jailbreaker ? »

La forme de requête la plus courante dans ce domaine est un nom de modèle suivi du mot jailbreak. C’est la mauvaise unité d’analyse, et la raison en est le tableau ci-dessus. Le succès dépend d’au moins cinq éléments à la fois : la capacité du modèle de base, la formation à la sécurité qu’il a reçue et sur quelle distribution, le format du prompt, les paramètres d’échantillonnage, et le nombre de tentatives que l’attaquant est prêt à consacrer.

Ce dernier point mérite sa propre phrase. Un taux mesuré à une tentative par prompt et un taux mesuré en « best of 28 » ne sont pas la même mesure, et le résultat adaptatif de l’article — 1,00 sur les deux modèles — est du second type. Quiconque cite un taux de jailbreak sans préciser de quel taux il parle n’a cité rien d’utilisable. La vraie question défensive n’est pas « peut-on le casser », mais « combien de tentatives faut-il, et quelque chose dans ma stack remarque-t-il ces tentatives ».

Deux conséquences pratiques en découlent. Un modèle qui résiste à votre jeu de prompts aujourd'hui peut cesser de résister après une montée de version, une modification de la couche de sécurité ou un changement de configuration côté service — le résultat n'est valable que pour la build que vous avez testée, ce qui explique pourquoi un test sans version ni date n'est pas un résultat. Et le même jeu de prompts exécuté sur deux modèles vous indique sur lequel votre stack est plus permissive, pas lequel est sûr.

Ce qu’un jailbreak n’est pas : l’abliteration

Ces deux choses sont constamment confondues, car toutes deux aboutissent à un modèle qui produit une sortie qu’il n’a pas été entraîné à produire. Il ne s’agit pas de la même modification, et la différence est celle qui existe entre un contrôle que l’on peut ajouter et une propriété que l’on ne peut pas.

• Jailbreak — une modification au niveau du prompt. Les poids restent inchangés. La direction de refus est toujours présente dans le modèle ; la requête a simplement été agencée de sorte que d’autres comportements la surpassent. Rétablissez le prompt et le comportement reviendra avec lui.

• Abliteration — une modification au niveau des couches de poids. La direction de refus est identifiée — généralement comme une direction dans l'espace d'activation — puis projetée hors des poids du modèle, de sorte que celui-ci ne produise plus du tout de refus pour cette catégorie de requêtes. Il s'agit d'une modification permanente de l'artefact, et c'est pourquoi un checkpoint abliteré se comporte différemment du même modèle de base accompagné d'un prompt astucieux. La mécanique de cette modification est détaillée dans notre guide de l'abliteration.

La différence opérationnelle importe davantage que la terminologie. Un jailbreak est un événement d’exécution : il survient avec une requête et peut être compté, soumis à une limitation de débit, filtré et journalisé comme n’importe quelle autre requête. Un modèle abliterated est un événement de chaîne d’approvisionnement : le contrôle a déjà été retiré avant que vous ne le receviez, et aucune surveillance au niveau de la couche de prompts ne le rétablit. Si votre modèle de menace est « quelqu’un va tenter de persuader le modèle », vous êtes dans la première catégorie. S’il est « quelqu’un va me livrer un modèle dont le refus a été retiré », vous êtes dans la seconde, et le seul contrôle réel est la provenance — savoir quel checkpoint le point de terminaison sert réellement.

Le jailbreak n’est pas non plus une injection de prompt.

Le troisième terme que l’on confond souvent est l’injection de prompt, et la question qui permet de distinguer les deux est de savoir qui est l’attaquant. Un jailbreak vient de l’utilisateur, qui cherche à obtenir du contenu que le modèle a été entraîné à retenir. L’injection de prompt vient de contenu — un document récupéré, une page web, le résultat d’un outil — qui porte des instructions que le développeur n’a jamais écrites, et elle fonctionne que l’utilisateur soit hostile ou non. Un même modèle peut être immunisé contre l’un et totalement vulnérable à l’autre, car ils sont contrés à des endroits différents : les jailbreaks à l’entrée et à la sortie du modèle, l’injection à la frontière de confiance entre les données et les instructions.

Qu'est-ce qui réduit réellement le taux

Rien ici n’est une garantie, et toute affirmation contraire est un argumentaire commercial. Ce qui suit constitue l’ensemble des leviers qui font évoluer les chiffres, classés selon le gain qu’ils apportent au regard de l’effort.

• Supposez que la couche de prompt cède.Tout contrôle qui repose sur un refus du modèle n'est qu'à un attaquant adaptatif près de tomber à zéro. Concevez comme si la requête finirait par passer, et placez le contrôle là où le dommage se produirait.

• Limitez ce qu'un jailbreak réussi peut atteindre. Le rayon d'impact d'un assistant jailbreaké correspond à ce que ses outils, ses identifiants et son périmètre de récupération permettent. Le moindre privilège sur les outils et un cloisonnement par locataire pour la récupération réduisent la valeur d'un jailbreak réussi bien plus fiablement que n'importe quel filtre de prompt.

• Jugez la sortie, pas le prompt. Les classificateurs côté sortie détectent des familles que vous n'avez jamais vues, parce qu'ils examinent ce qui a été réellement produit plutôt que la manière dont cela a été demandé. Ils sont aussi la seule couche qui fonctionne encore lorsque le format d'entrée est inédit — ce qui, selon le mode de défaillance de généralisation inadéquate, est le cas la plupart du temps.

• Traitez l'invite système comme une valeur de configuration, et non comme une frontière de sécurité. Il s'agit d'un texte situé dans la même fenêtre de contexte que l'attaque. Cela augmente le coût d'une tentative ; cela ne l'arrête pas.

• Rendez les tentatives visibles. Le seul avantage qu’un défenseur possède sur l’attaquant adaptatif, c’est que l’attaque est généralement répétée. La limitation de débit, la détection des répétitions et la journalisation transforment une recherche en 28 tentatives en un événement que vous pouvez voir, plutôt qu’en 28 requêtes qui, prises isolément, semblaient toutes anodines.

• Retester à chaque changement de modèle. Un épinglage de version accompagné d’un ensemble fixe d’invites est ce qui transforme « nous l’avons testé une fois » en un nombre comparable. Sans l’épinglage, la comparaison n’a aucun sens.

Comment mesurer votre propre cible

Si l'objectif est d'obtenir un chiffre exploitable, fixez les trois variables que l'article a fixées : le jeu de prompts, la version du modèle et le nombre de tentatives. Utilisez un jeu de prompts qui couvre les deux modes de défaillance — des instructions qui rendent le refus délicat et des encodages qui masquent la demande —, car un jeu composé uniquement de l'un favorisera un modèle faible face à l'autre. Notez avec prudence : préjudiciable et pertinent sur le sujet, pas simplement hors ton. Et rapportez le résultat sous forme de taux par rapport à un nombre de tentatives indiqué, jamais sous forme de oui ou de non.

Lorsque plusieurs modèles candidats sont en jeu, la comparaison ne fonctionne que si le même jeu d’invites est exécuté sur chacun d’eux, et c’est le seul endroit où l’infrastructure compte plus que la méthodologie. Exécuter une évaluation sur les modèles que nous routons élimine le contrat par fournisseur et le travail côté client de l’exercice ; les prix catalogue des fournisseurs sont répercutés sans marge, de sorte que l’exécution coûte ce que les fournisseurs facturent et rien de plus. Ce que l’évaluation mesure, c’est le comportement du modèle, pas le nôtre — le routage change le modèle qui répond, et il ne pousse aucun d’eux à refuser davantage.

Là où le disque reprend

Un taux de réussite mesuré indique à quel point la couche de prompt est difficile à faire basculer. Il ne dit pas ce qui s’est passé lorsque quelqu’un l’a fait basculer en production, et c’est cette seconde question qui détermine si le taux a de l’importance. Un jailbreak qui produit un paragraphe grossier est un problème de modération de contenu. Un jailbreak qui produit un appel d’outil est un incident, et la différence tient entièrement à ce que le système a laissé la sortie atteindre.

Cette archive est le registre de terrain : ce que les agents ont réellement fait, avec une source pour chaque entrée et un verdict sur le point de savoir si quelqu'un a été lésé. Lu à la lumière d'une mesure de jailbreak, il répond à la question que la mesure ne peut pas trancher : la frontière franchie par un prompt est-elle une frontière dont dépend quelque chose en aval ? Si oui, le jailbreak est un constat de sécurité et le contrôle a sa place dans les autorisations des outils. Si non, le jailbreak est un résultat de contenu, et la démarche honnête est de le classer comme tel plutôt que de le gonfler en vulnérabilité.

La note finale est celle que les éléments de preuve étayent. Le jailbreaking ne sera pas résolu par un meilleur modèle, car les modes de défaillance sont structurels : le respect des instructions est une capacité, et l’entraînement à la sécurité en est une plus étroite, et l’écart entre les deux est précisément là où se situe chaque attaque décrite dans cet article. Ce qui peut être résolu, c’est la conséquence — en veillant à ce qu’un modèle qui cesse de refuser ne puisse toujours pas faire grand-chose.