PuzzleMask : quand la prose ordinaire échappe au modèle filtre

De quoi s’agit-il ?

De nombreux déploiements de LLM placent un petit modèle « filtre » rapide devant un modèle « cible » plus capable. Le filtre examine chaque entrée et bloque ce qui viole la politique. Le 10 septembre 2026, Check Point a publié PuzzleMask, une technique qui met en évidence la faiblesse de ce schéma : une instruction non conforme peut être dissimulée dans une prose ordinaire et correctement ponctuée, sans encodage, caractères invisibles ni autre obfuscation que les filtres d’entrée recherchent habituellement.

Les auteurs soulignent qu’il ne s’agit pas d’un jailbreak de l’alignement du modèle cible : la technique ne fait que contourner le filtre d’entrée. Les détails de construction ont été volontairement omis dans les publications, et le sont aussi ici.

Comment cela fonctionne

L’idée repose sur un écart de capacités. Le filtre lit le texte visible et le juge anodin ; un modèle plus puissant, disposant de suffisamment de temps de raisonnement et d’outils comme un interpréteur de code, peut reconstituer l’instruction cachée et agir en conséquence.

Check Point rapporte les résultats suivants dans son cadre expérimental contrôlé (ce ne sont pas des taux de contournement universels) :

• Quatre filtres (gpt-4o-mini, gpt-oss-safeguard, claude-3-haiku, llama-guard3) signalaient correctement les versions simples, mais ont classé comme sûr chaque prompt enveloppé (23 prompts ; 5 applicables pour Llama Guard 3).
• Une cible GPT-5 Thinking, avec un effort de raisonnement élevé et Python disponible, a reconstitué et exécuté l’instruction dans 17 essais applicables sur 18. Chaque réussite a demandé plus d’une minute de raisonnement et plusieurs exécutions de code.
• Les modèles de classe Opus d’Anthropic ont résisté à toutes les tentatives. Les auteurs évoquent un classifieur interne, tout en précisant que ce point n’est pas vérifié.
• La technique a été signalée à Anthropic, Meta et OpenAI avant publication ; les articles ne mentionnent aucun correctif.

Pourquoi c’est important

La classification des entrées est souvent traitée comme la frontière de sécurité. PuzzleMask illustre qu’un filtre moins capable ne peut pas prédire de façon fiable ce qu’un modèle plus puissant déduira du même texte. Tout pipeline où le garde est moins capable que le modèle qu’il protège, et où ce dernier dispose d’outils, hérite de cet écart. L’impact dépend de ce que la cible peut faire : limité avec des outils en lecture seule, plus grave avec un accès au shell, aux fichiers ou au réseau.

Défenses

• Séparez la classification de politique de l’autorisation : appliquez le moindre privilège sur les outils et une approbation au moment de l’action, afin qu’une entrée manquée ne devienne pas une action nuisible.
• Surveillez les sorties, le raisonnement et les appels d’outils de la cible (commandes shell, écritures de fichiers, appels réseau, usage d’identifiants), pas seulement ses entrées.
• Réduisez l’écart de capacités : utilisez un garde plus puissant ou escaladez les entrées ambiguës vers un modèle de sécurité plus fort.
• Paraphrasez les entrées non fiables avant filtrage ; cela peut casser la structure cachée, au prix de latence et d’une possible dégradation du contenu légitime.
• Durcissez la politique du garde pour les formulations suspectes. Dans les tests de Check Point, une clause de politique a permis à gpt-4o-mini de signaler les 23 prompts, mais le taux de faux positifs doit être mesuré.
• Considérez les textes récupérés ou fournis par l’utilisateur comme non fiables, et journalisez les décisions modèle-vers-outil pour l’audit.

Statut

Élément	Détail
Type de source	Recherche éditeur (Check Point), expériences contrôlées
Publication	10 septembre 2026
Filtres contournés	gpt-4o-mini, gpt-oss-safeguard, claude-3-haiku, llama-guard3
Reconstitution par la cible	GPT-5 Thinking : 17 essais sur 18
Divulgation	Signalé à Anthropic, Meta, OpenAI ; aucun correctif rapporté
Vulnérabilité / CVE	Aucun attribué ; il s’agit d’une technique, pas d’un bug produit