Induction du langage « ivre » : comment un style de texte affaiblit la sécurité des LLM

De quoi s’agit-il ?

Dans « In Vino Veritas and Vulnerabilities: Examining LLM Safety via Drunk Language Inducement » (arXiv:2601.22169, soumis le 19 janvier 2026), Anudeex Shetty, Aditya Joshi et Salil S. Kanhere (UNSW Sydney) étudient si faire imiter à un modèle un discours en état d’ébriété dégrade son comportement de sécurité. Ces travaux ont reçu une nouvelle couverture médiatique le 28 septembre 2026 (Help Net Security). L’article est présenté comme un travail en cours.

Cinq modèles ont été testés : LLaMA2-7B, LLaMA3-8B, Mistral-7B, GPT-3.5 et GPT-4. Les auteurs rapportent une plus grande vulnérabilité aux jailbreaks sur JailbreakBench et davantage de fuites de données privées sur ConfAIde, qu’ils attribuent à l’anthropomorphisme : le modèle reproduit la désinhibition observée dans les textes humains.

Comment cela fonctionne

L’étude compare trois méthodes d’induction, décrites ici à haut niveau :

• Persona par prompt : on demande au modèle de se comporter comme s’il était ivre.
• Fine-tuning causal : entraînement sur DRUNKTEXT, un jeu de 63 577 textes (2 363 issus de TFLN et 61 214 de la communauté Reddit /drunk).
• Apprentissage par renforcement : optimisation PPO contre un modèle de récompense qui note le caractère « ivre » du texte.

Sur JailbreakBench (100 requêtes), les taux de réussite d’attaque (ASR) rapportés sont de 21 à 90 % pour le prompt, 41 à 74 % pour le fine-tuning et 35 à 53 % pour le RL, selon le modèle. Une référence plus lourde (prompt + recherche aléatoire) atteint 78 à 93 % mais exige bien plus de calcul ; c’est pourquoi les auteurs présentent l’induction « ivre » comme une alternative peu coûteuse. Sur ConfAIde, les violations de confidentialité contextuelle et les fuites augmentent sur les trois niveaux de scénarios.

Aucune chaîne d’exploitation n’est nécessaire pour comprendre le constat : le risque vient d’un changement de style ou de persona qui éloigne le modèle de la distribution sur laquelle ses refus ont été appris. L’évaluation du papier est mono-tour, en anglais uniquement et limitée à trois méthodes d’induction.

Pourquoi c’est important

D’abord, la sécurité d’un modèle dépend du registre et du persona, pas seulement du contenu sémantique de la requête. Tout système qui laisse l’utilisateur ou un tiers définir un persona, un ton ou un rôle (assistants de service client, produits de jeu de rôle, API de fine-tuning) élargit cette surface.

Ensuite, un fine-tuning sur du texte ordinaire issu des réseaux sociaux, sans intention malveillante, peut éroder les garde-fous. C’est pertinent pour les équipes qui adaptent des modèles open-weight sur des données d’utilisateurs.

Enfin, les défenses évaluées se sont montrées faibles. Sur LLaMA2-7B, les auteurs rapportent que SmoothLLM a fait monter l’ASR à 90 %, Rephrase l’a augmenté modestement et Retokenize n’a eu qu’un effet négligeable. Les défenses par perturbation semblent mal adaptées aux changements stylistiques, et les variantes les plus fortement fine-tunées leur résistaient.

Défenses

• Relancer les évaluations de sécurité après chaque fine-tuning ou changement de persona, y compris sur des corpus d’apparence anodine. Ajouter des variantes stylistiques (registres informel, altéré, émotionnel) aux suites de red teaming.
• Ne pas s’appuyer uniquement sur la perturbation des entrées. La compléter par une modération en sortie et des classifieurs de politique qui jugent la réponse plutôt que la forme du prompt.
• Encadrer les personas. Limiter ou relire les personas définis par l’utilisateur en production, et séparer la politique système du ton contrôlable par l’utilisateur.
• Protéger le contexte sensible. Garder secrets et données personnelles hors du contexte du modèle autant que possible, afin qu’un refus dégradé ne puisse pas les divulguer (les fuites de données privées étaient le second axe mesuré).
• Envisager une surveillance au niveau des représentations. Les auteurs proposent d’étudier le pilotage des représentations internes comme piste future ; il s’agit de recherche, pas encore d’un contrôle prêt à l’emploi.

Statut

Élément	Détail
Article	arXiv:2601.22169, soumis le 19 janv. 2026, travail en cours
Couverture presse	Help Net Security, 28 sept. 2026
Modèles testés	LLaMA2-7B, LLaMA3-8B, Mistral-7B, GPT-3.5, GPT-4
Limites	Mono-tour, anglais uniquement, trois techniques d’induction
Correctif éditeur	Sans objet : faiblesse comportementale, pas une faille logicielle ponctuelle