CodeSpear : quand le décodage sous contrainte grammaticale devient une surface de jailbreak

De quoi s’agit-il ?

Le 10 juin 2026, Yitong Zhang, Shiteng Lu et Jia Li ont publié Grammar-Constrained Decoding Can Jailbreak LLMs into Generating Malicious Code sur arXiv (cs.CR, 2606.11817). Le constat est volontairement contre-intuitif : une technique adoptée pour rendre la génération de code des LLM plus fiable peut être détournée en jailbreak.

Le décodage sous contrainte grammaticale (Grammar-Constrained Decoding, GCD) est le mécanisme derrière les fonctionnalités de sortie structurée et « code valide uniquement ». À chaque étape, le modèle échantillonnerait normalement sa distribution complète de tokens ; le GCD applique un masque par token qui annule tout token qui briserait la grammaire fournie, garantissant que la sortie se parse. Les auteurs nomment l’attaque CodeSpear et montrent qu’appliquer une contrainte grammaticale de code d’apparence anodine peut amener un modèle à compléter une requête malveillante qu’il refuserait autrement. L’attaque prolonge la surface « plan de contrôle » décrite dans When Grammar Guides the Attack (arXiv:2503.24191, 31 mars 2025), qui a le premier posé la sortie structurée comme un plan d’attaque orthogonal aux attaques par prompt.

Comment ça marche

L’alignement de sécurité est très majoritairement entraîné dans le plan du langage naturel : le modèle apprend à émettre une phrase de refus (« Je ne peux pas vous aider ») quand une requête est dangereuse. Or ce refus est une séquence de tokens. Le GCD opère un cran en dessous, sur les tokens qui ont seulement le droit d’être échantillonnés.

Le problème structurel est là : lorsqu’une contrainte grammaticale exige que les tokens suivants forment du code valide, les tokens qui composent un refus en langage naturel ne font plus partie de l’ensemble autorisé. Le modèle ne peut pas dire « Je ne ferai pas ça » car cette chaîne ne satisfait pas la grammaire. Contraint d’émettre quelque chose qui se parse comme du code, le chemin de moindre résistance devient de compléter le programme demandé, token par token. Le comportement de refus appris dans le plan du langage est tout simplement inatteignable dans le plan du code. Mesuré sur 10 LLM et 4 benchmarks, CodeSpear augmente le taux de succès d’attaque de plus de 30 points de pourcentage en moyenne par rapport aux jailbreaks de référence — sans aucune formulation adverse dans le prompt, la manipulation réside entièrement dans la contrainte de décodage.

Nous décrivons délibérément le mécanisme, pas une grammaire exécutable : la leçon durable est qu’une surface de contrôle située sous le prompt peut écraser la sécurité au niveau du prompt.

Pourquoi c’est important

C’est une forme de risque différente des attaques côté entrée comme les jailbreaks par encodage mathématique ou les attaques par slots positionnels. Celles-ci manipulent ce que vous dites au modèle. CodeSpear manipule la machinerie de décodage, ce qui lui permet de passer sous des défenses qui n’inspectent que le prompt utilisateur. Tout produit exposant des fonctionnalités de sortie structurée ou de « code sous contrainte » via une API confie à l’appelant un contrôle partiel de cette machinerie ; la menace est donc la plus aiguë pour les assistants de code et les endpoints de génération de code, où les contraintes grammaticales sont une capacité normale et annoncée. Le point de fond est architectural : une sécurité entraînée dans une modalité (langage naturel) ne se transfère pas automatiquement à une autre (code sous contrainte), et un attaquant capable de choisir la grammaire de sortie choisit la modalité.

Défenses

Le même papier livre une défense, CodeShield, et sa conception est l’enseignement actionnable :

• Aligner la sécurité dans la modalité du code, pas seulement dans le langage. CodeShield apprend au modèle à émettre du code leurre (honeypot) face à une requête GCD malveillante : une sortie sémantiquement inoffensive (elle n’implémente pas le comportement dangereux) mais structurellement diverse (impossible à éliminer en resserrant simplement la grammaire). Le modèle reste sûr même quand l’attaquant contrôle la grammaire.
• Préserver les refus en langage naturel là où ils restent atteignables. Quand aucune grammaire ne force une sortie code-uniquement, CodeShield conserve le refus normal : l’utilité légitime n’est pas sacrifiée.
• Traiter la contrainte de décodage comme une entrée non fiable. Si votre plateforme laisse les appelants fournir des grammaires ou des schémas JSON, journalisez-les et bornez-les, et ne supposez pas que les garde-fous au niveau du prompt couvrent ce chemin.
• Exécuter des classifieurs de sécurité côté sortie sur le code généré, indépendamment de la contrainte de décodage, afin qu’une complétion valide-mais-malveillante soit malgré tout détectée a posteriori.

CodeShield rétablirait la sécurité face à CodeSpear sur les 10 modèles testés tout en préservant l’utilité de génération de code légitime.

Statut

CodeSpear et CodeShield ont été publiés en préprint arXiv le 10 juin 2026 ; la surface d’attaque « plan de contrôle » sous-jacente avait été documentée pour la première fois en mars 2025. Les auteurs présentent les implications de sécurité du GCD comme un risque ouvert et peu examiné, plutôt qu’un bug unique corrigé — les fonctionnalités de sortie structurée sont répandues, et la réponse défensive est un changement d’alignement conscient de la modalité, pas un correctif d’une ligne.