🤖 AI

SoK: Systematizing LLM Prompt Security: Taxonomies, Datasets, and Unified Evaluation of Attacks and Defenses

Cet article de Systématisation des Connaissances (SoK) aborde l'évaluation fragmentée de la sécurité des prompts des LLM en proposant des taxonomies unifiées, en formalisant les métadonnées d'évaluation et en publiant une plateforme modulaire comprenant de nouveaux jeux de données et outils afin de permettre des évaluations reproductibles, économes en coûts et comparables des attaques et des défenses.

Auteurs originaux : Hanbin Hong, Shuang Wu, Shuya Feng, Nima Naderloui, Shenao Yan, Jingyu Zhang, Ali Arastehfard, Heqing Huang, Yuan Hong

Publié 2026-07-07

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Hanbin Hong, Shuang Wu, Shuya Feng, Nima Naderloui, Shenao Yan, Jingyu Zhang, Ali Arastehfard, Heqing Huang, Yuan Hong

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez les modèles de langage étendus (LLM) comme des bibliothécaires incroyablement intelligents, mais légèrement naïfs. Ils sont embauchés pour répondre à des questions, écrire du code et aider à accomplir des tâches. Cependant, ces bibliothécaires ont un règlement strict : « Ne pas aider quiconque à faire quelque chose de dangereux ou d'illégal. »

Le problème est que des personnes astucieuses (les attaquants) ont trouvé le moyen de piéger ces bibliothécaires pour leur faire enfreindre leurs propres règles. Ils font cela en chuchotant des instructions dans une langue différente, en déguisant une mauvaise requête sous la forme d'un scénario de film, ou en demandant au bibliothécaire de prétendre être un méchant. C'est ce qu'on appelle un « jailbreak » (un déverrouillage).

Ce document est comme un audit de sécurité massif de tout le système de la bibliothèque. Les auteurs ont réalisé que tout le monde essayait de mesurer la performance des bibliothécaires, mais que tout le monde utilisait des règles différentes, des questions de test différentes et des juges différents. Une personne pourrait dire : « Notre bibliothécaire est sûr à 90 % ! », tandis qu'une autre dira : « Le nôtre n'est sûr qu'à 50 % ! ». Le papier soutient que vous ne pouvez pas comparer ces chiffres car ils ne mesurent pas la même chose.

Voici comment ce document corrige cela, expliqué simplement :

1. Les trois nouveaux « règlements » (Taxonomies)

Les auteurs ont créé trois listes organisées pour sortir du chaos, comme pour trier des jouets dans des bacs spécifiques :

La liste des « Truqueurs » (Attaques) : Ils ont catégorisé la façon dont les gens piègent le bibliothécaire.
- Exemple : Certains tours consistent à déguiser la mauvaise requête (comme écrire « comment fabriquer une bombe » dans un code secret). D'autres consistent à diviser la requête en petits morceaux inoffensifs qui, cumulés, forment quelque chose de mauvais. Certains utilisent même une seconde IA pour aider à rédiger le tour de passe-passe.
La liste des « Gardiens » (Défenses) : Ils ont catégorisé la façon dont les bibliothécaires tentent d'arrêter les tours.
- Exemple : Certains gardiens vérifient l'identité avant de laisser entrer la personne (Détection d'entrée). D'autres vérifient le sac après que la personne est partie (Détection de sortie). D'autres tentent de réécrire la requête pour la rendre sûre, ou tentent d'entraîner le bibliothécaire pour qu'il soit plus intelligent.
La liste des « Points Faibles » (Vulnérabilités) : Ils ont listé les faiblesses naturelles du bibliothécaire.
- Exemple : Le bibliothécaire peut être trop poli pour dire « non » si on lui demande gentiment (Manipulation psychologique), ou il peut être confus si on lui demande de résumer une histoire qui traite justement d'un crime (Exploitation de format).

2. Le « Laboratoire de test universel » (PromptSecurity)

Les auteurs ont construit une machine de test géante et modulaire appelée PromptSecurity. Voyez cela comme un niveau de jeu vidéo où vous pouvez changer de personnage, d'ennemi, d'arme et de arbitre, mais garder exactement les mêmes règles de jeu.

Pourquoi c'est important : Auparavant, les chercheurs testaient une nouvelle défense sur un modèle spécifique avec un ensemble de questions spécifique. Si cela fonctionnait, ils proclamaient la victoire. Mais peut-être que cela ne fonctionnait que parce que les questions étaient faciles !
La solution : Cette plateforme force tout le monde à exécuter ses tests sous les mêmes conditions exactes. Elle enregistre tout : combien de questions ont été posées, combien d'argent a coûté l'exécution du test, et exactement quel « arbitre » (juge IA) a décidé si la réponse était mauvaise. Cela garantit que si la Méthode A bat la Méthode B, c'est parce que la Méthode A est réellement meilleure, et non parce que le test a été truqué.

3. La collecte de « Big Data » (JAILBREAKDB)

Le document a rassemblé une immense bibliothèque de questions de test :

Plus de 445 000 tentatives de « Jailbreak » (les mauvaises requêtes).
Plus de 1 000 000 de requêtes « Bénignes » (les questions normales et sûres).
Ils les ont nettoyées et organisées afin que les chercheurs puissent les utiliser comme un « examen » standard pour n'importe quelle nouvelle IA.

4. Ce qu'ils ont découvert (Les résultats)

Lorsqu'ils ont lancé leurs tests universels, ils ont découvert certaines choses surprenantes :

L'arbitre compte : Le fait de demander à un arbitre de noter l'examen change le score. Si vous demandez à un arbitre de regarder uniquement le format de la réponse (par exemple, « Ont-ils commencé par "Je ne peux pas" ? »), il pourrait manquer une mauvaise réponse qui a été habilement cachée. Si vous lui demandez de regarder le sens, il pourrait la détecter. Le papier dit que nous devons être très prudents sur la manière dont nous jugeons la sécurité.
Petits modèles vs Grands modèles : Parfois, une IA plus petite et plus « faible » semble plus sûre parce qu'elle échoue simplement à comprendre le tour complexe utilisé par l'attaquant. Ce n'est pas que l'IA est plus intelligente, c'est qu'elle est trop limitée pour suivre les instructions.
L'effet de « Contrecoup » : Certaines défenses aggravent en réalité les choses ! Si vous essayez de « guider » l'IA pour qu'elle soit sûre en ajoutant une instruction de sécurité, cette instruction peut parfois confondre l'IA et la pousser à dire accidentellement quelque chose de préjudiciable. C'est comme mettre un panneau « Ne pas toucher » sur une exposition de musée, mais le panneau est si grand qu'il bloque la vue de l'œuvre, provoquant des heurts de la part des visiteurs.
Coût vs Sécurité : Les défenses les plus efficaces coûtent souvent beaucoup d'argent ou de temps à exécuter. Les défenses les moins chères bloquent souvent les questions normales (comme demander une recette) aussi souvent qu'elles interceptent les mauvaises requêtes.

La conclusion

Ce document ne se contente pas de dire « l'IA est dangereuse » ou « Voici une solution ». Il dit plutôt : « Arrêtez de comparer des pommes et des oranges. »

Il fournit les outils (les taxonomies, le jeu de données et la plateforme de test) pour que, dans le futur, lorsque quelqu'un prétendra que sa nouvelle IA est « sûre à 99 % », nous puissions vérifier son travail, voir exactement comment il a testé son modèle, et savoir si cette affirmation est réelle ou s'il ne s'agit que d'une illusion causée par une mauvaise configuration de test. Il transforme un domaine confus et désordonné en une science structurée.

Résumé technique : SoK : Systématiser la sécurité des prompts de LLM

Énoncé du problème
Le déploiement rapide des grands modèles de langage (LLM) en tant qu'interfaces pour l'information et les services a fait de la sécurité au niveau du prompt une préoccupation critique. Bien que le domaine ait connu des avancées rapides dans les attaques par jailbreak, les wrappers défensifs, les politiques de sécurité, les jeux de données et les juges automatisés, la communauté est confrontée à un problème de fragmentation important. Les travaux antérieurs reposent souvent sur des modèles de menace, des hypothèses d'accès, des budgets de coût, des jeux de données et des critères de succès incompatibles. Ce manque de standardisation rend difficile la comparaison des taux de succès d'attaque (ASR) ou des gains de défense rapportés. Par conséquent, il est souvent difficile de déterminer si le progrès observé provient d'une méthode plus forte, d'un modèle cible plus faible, de règles de jugement différentes ou simplement d'un budget de requêtes plus élevé. Le défi central est de déterminer si les affirmations de sécurité peuvent être comparées sous des conditions unifiées et auditables.

Méthodologie
Les auteurs proposent une approche systématique de l'évaluation de la sécurité des prompts de LLM, passant de démonstrations spécifiques à des articles à des mesures reproductibles et fondées sur une taxonomie. La méthodologie se compose de quatre composantes clés :

Trois taxonomies liées : Le papier établit un cadre conceptuel séparant les mécanismes techniques des capacités de l'attaquant et du défenseur :
- Taxonomie I (Attaques par jailbreak) : Classifie les attaques par modèle de menace (boîte noire vs boîte blanche) et par méthodologie technique (ex: modification de prompt, optimisation en boîte noire, techniques assistées par LLM, techniques multi-tours et exploitation des vulnérabilités du modèle). Elle traite les attaques comme étant compositionnelles, permettant à une seule méthode d'instancier plusieurs unités techniques atomiques.
- Taxonomie II (Défenses) : Groupe les défenses par objectif (détection vs atténuation) et par couche d'intervention (niveau entrée, niveau sortie, état interne, entraînement du modèle, modification du modèle, traitement de la sortie).
- Taxonomie III (Vulnérabilités des LLM) : Catégorise les modes de défaillance intrinsèques des modèles exploités par les attaques, tels que l'exploitation de format, la dépendance excessive aux instructions de l'utilisateur, la manipulation psychologique et l'ambiguïté contextuelle.
Protocole d'évaluation auditable : Les auteurs formalisent les hypothèses de menace, d'accès et de coût sous forme de métadonnées explicites. Ils définissent une expérience comme un tuple $\langle M, A, D, S, J \rangle$ , représentant le Modèle, l'Attaque, la Défense, le Jeu de données et le Juge. Ce protocole exige que les comparaisons ne soient valides que lorsque l'identité des composants et les paramètres (ex: LLM assistants, paramètres de décodage, budgets de requêtes, composition de la défense) sont identiques.
Plateforme PROMPTSECURITY : Une plateforme d'évaluation modulaire est introduite pour opérationnaliser le protocole. Elle représente chaque expérience comme un tuple configuré, permettant des comparaisons compatibles avec l'accès et auditables. La plateforme enregistre les identifiants d'échantillons, les sorties, les paramètres, le nombre de requêtes et les configurations du juge pour assurer la reproductibilité.
Jeux de données unifiés : Les auteurs publient JAILBREAKDB, un corpus organisé contenant 445 752 paires de prompts système-utilisateur de jailbreak provenant de 48 sources et 1 094 122 prompts bénins provenant de 14 sources. Ils publient également PROMPTSECURITY-EVAL, contenant 166 200 enregistrements de sorties de requêtes malveillantes et 9 200 enregistrements de sorties de l'utilité bénigne générés sous le protocole principal.

Principales contributions

Taxonomies au niveau des mécanismes : Le papier systématise le domaine via trois taxonomies liées qui supportent des mappages de sous-catégories multi-labels, permettant de faire des affirmations empiriques au niveau de la sous-catégorie de la taxonomie plutôt qu'au seul niveau de la méthode.
Plateforme d'évaluation unifiée : L'introduction de PROMPTSECURITY, qui traite la compatibilité d'accès, l'utilisation de LLM assistants et les rubriques de jugement comme des parties auditables de la revendication de sécurité, permettant des études d'ablation contrôlées à travers un espace de conception partagé.
Aperçus empiriques : La plateforme a été utilisée pour évaluer 11 modèles cibles, 21 réglages d'attaque, 10 états de défense et trois juges sous des réglages correspondants.
Jeux de données et classement : La publication de JAILBREAKDB et PROMPTSECURITY-EVAL, ainsi qu'un classement interactif pour parcourir les mesures compatibles du protocole principal.

Résultats et découvertes empiriques
L'évaluation produit plusieurs découvertes au niveau taxonomique :

Accès au modèle et capacité : Les modèles de pointe en boîte noire sont plus exposés aux attaques de transformation et d'obscurcissement de prompt qui aident le modèle cible à récupérer l'intention malveillante dissimulée. Inversement, les modèles plus faibles en boîte blanche suppriment souvent les prompts transformés complexes, non pas en raison d'une robustesse accrue, mais parce qu'ils échouent à exécuter la tâche d'attaque (ex: échec de l'analyse de prompts de style code).
Mécanismes d'attaque : Sur les modèles en boîte noire, les transformations de prompt à faible coût surpassent souvent les jailbreaks en langage naturel générés par assistant. Sur les modèles en boîte blanche, cet ordre change, l'apprentissage et l'affinement assistés par LLM montrant une plus grande persistance.
Efficacité de la défense : L'efficacité de la défense dépend du mécanisme. La détection et le routage d'entrée/sortie dominent l'atténuation moyenne. Cependant, l'accès en boîte blanche seul ne garantit pas une défense forte ; par exemple, le filtrage de gradient et l'optimisation du prompt de sécurité ont apporté peu ou même une atténuation moyenne négative dans certains cas.
Contre-effet des défenses : Les défenses peuvent introduire de nouveaux comportements malveillants. Le réglage du prompt de sécurité, par exemple, a augmenté l'ASR moyen des sorties malveillantes car le pilotage ajouté a parfois transformé des prompts auparavant sûrs en complétions malveillantes.
Sensibilité du juge : Le choix du juge affecte matériellement les conclusions de sécurité. Les vérifications de préfixe (instruments de format de refus) peuvent surcompter les sorties bénignes de non-refus et manquer les sorties malveillantes cachées derrière des ouvertures de type refus. Les juges conditionnés par le comportement sont très sensibles à la description spécifique du comportement fournie, ce qui entraîne une variance significative des mesures d'ASR.

Signification
Le papier soutient que la sécurité des prompts de LLM doit être évaluée au niveau des groupes de mécanismes sous un contrôle de configuration équitable. La signification de ce travail réside dans son passage de démonstrations spécifiques à un article vers une évaluation reproductible, sensible au coût et fondée sur une taxonomie. L'objectif n'est pas simplement d'identifier quelle méthode a un ASR plus élevé, mais de clarifier quel mécanisme, choix de réglage ou règle de jugement explique le comportement de sécurité rapporté. En fournissant une base de taxonomies liées, un protocole exécutable, une plateforme modulaire et des jeux de données unifiés, les auteurs visent à permettre des évaluations futures capables de distinguer le véritable progrès méthodologique des artefacts de conception expérimentale.

1. Les trois nouveaux « règlements » (Taxonomies)

2. Le « Laboratoire de test universel » (PromptSecurity)

3. La collecte de « Big Data » (JAILBREAKDB)

4. Ce qu'ils ont découvert (Les résultats)

La conclusion

Articles similaires