Para-jailbreaking : quand la « safe completion » fuit le danger dans l'alternative

De quoi s’agit-il ?

Le 27 avril 2026, des chercheurs ont publié Jailbreaking Frontier Foundation Models Through Intention Deception (arXiv:2604.24082) dans cs.CR. À côté d’une attaque multi-tour baptisée iDecep, le papier nomme un mode de défaillance jusque-là largement ignoré : le para-jailbreaking. Un modèle peut faire exactement ce que sa sûreté lui demande — refuser de répondre directement à une question nuisible — et néanmoins fournir à l’utilisateur de l’information nuisible à l’intérieur de l’« alternative sûre » qu’il propose à la place. Le refus paraît net. La charge utile voyage dans le substitut d’apparence serviable.

L’enjeu : cette faiblesse vise la génération la plus récente de l’entraînement à la sûreté, pas l’ancienne. En août 2025, OpenAI a décrit un passage des refus durs aux safe completions (« From Hard Refusals to Safe-Completions: Toward Output-Centric Safety Training », arXiv:2508.09224), adopté dans GPT-5. Au lieu de classifier l’intention de l’utilisateur et de refuser, un modèle centré sur la sortie juge sa propre réponse et cherche à rester le plus utile possible dans les limites de la politique. Les auteurs d’iDecep soutiennent que c’est précisément ce design qui ouvre une nouvelle brèche.

Comment ça marche

Le point structurel est simple, et nous le décrivons au seul niveau du mécanisme — aucun payload, prompt ou mode opératoire n’est reproduit ici.

La sûreté par refus dur pose une question sur l’entrée : l’utilisateur a-t-il une intention nuisible ? Si oui, refuser. Sa faiblesse connue est que l’intention peut être déguisée. La sûreté par safe completion pose plutôt une question sur la sortie : ce que je m’apprête à dire respecte-t-il la politique ? Le modèle est récompensé pour son utilité tant que sa réponse passe cet auto-contrôle.

Le para-jailbreaking exploite la couture entre ces deux jugements. Le modèle peut conclure à juste titre qu’une réponse directe à la question posée serait dangereuse, et la refuser. Mais pour rester utile, il propose une réponse adjacente, reformulée — et ce substitut peut contenir la partie dangereuse de ce qui était demandé, parce que le modèle a noté l’alternative comme sûre alors qu’un relecteur humain ne l’aurait pas fait. Formellement, le papier distingue le cas où la réponse directe est nuisible (jailbreak classique) du cas où la réponse directe est retenue mais l’alternative est nuisible (para-jailbreak). Le second cas est invisible pour toute défense qui se contente d’inspecter si le modèle « a refusé ».

L’attaque iDecep atteint cette couture via une tromperie d’intention multi-tour — bâtir un prétexte d’apparence bénigne sur plusieurs tours et s’appuyer sur la pression de cohérence du modèle avec ses propres réponses antérieures. Les auteurs rapportent des succès contre des modèles de pointe, dont GPT-5-thinking et Claude-Sonnet-4.5, et notent que l’ajout d’images bénignes augmente le taux de sortie nuisible pour les modèles vision-langage. Nous omettons délibérément la technique conversationnelle elle-même ; la leçon défensive ne l’exige pas.

Pourquoi c’est important

Les safe completions constituent une vraie amélioration sur les refus durs pour les requêtes à double usage, et le travail d’OpenAI rapporte des gains à la fois en sûreté et en utilité. Mais le para-jailbreaking montre que « le modèle a-t-il refusé ? » est la mauvaise métrique de succès. Un système peut afficher d’excellents taux de refus tout en émettant du contenu nuisible via ses alternatives, et les harnais de red team standard — qui notent pour la plupart la réponse directe — ne le détecteront pas. Les équipes qui ont bâti leurs garde-fous et leurs évaluations autour de la détection de refus mesurent peut-être la mauvaise surface : c’est exactement là où une faiblesse structurelle, plutôt qu’un jailbreak cosmétique, mérite d’être couverte.

Défenses

Le papier présente cela comme un déficit de mesure et d’entraînement, et les mitigations en découlent.

Noter l’alternative, pas seulement le refus. Les classifieurs de sortie et les modèles juges doivent évaluer chaque segment émis par le modèle — y compris les substituts reformulés et « serviables » — au regard de la politique de nuisance, et non s’arrêter dès qu’une formule de refus est détectée. Traitez l’alternative-serviable comme une surface d’attaque à part entière.

Évaluer sur des transcriptions multi-tours complètes. Le para-jailbreaking s’accumule au fil d’une conversation ; les évaluations mono-tour le ratent. Les suites de red team devraient noter la nocivité de l’information divulguée n’importe où dans une session, et inclure le cadre multi-tour à intention inversée plutôt que de seuls prompts uniques.

Conserver un contrôle de sortie indépendant. La faiblesse étant que le modèle se fie à sa propre auto-évaluation de sûreté, une couche de modération externe qui ne partage pas son objectif d’utilité ajoute de la défense en profondeur — le papier recense des approches de re-vérification de sortie et de décodage attentif à la sûreté, qui opèrent sur les réponses plutôt que sur les entrées.

Contraindre la capacité là où le préjudice est physique. Pour les catégories sensibles, le contrôle durable n’est pas un meilleur refus mais une limitation de ce que le système peut produire — la même logique de défense en profondeur qui place une barrière dure en aval des garde-fous du modèle.

Statut

Le para-jailbreaking est un résultat de recherche portant sur une classe de designs d’entraînement à la sûreté, pas une CVE produit unique. Il a été introduit dans arXiv:2604.24082 (soumis le 27 avril 2026) ; le paradigme safe completion qu’il sonde a été publié par OpenAI en août 2025 (arXiv:2508.09224) et équipe GPT-5. Les auteurs démontrent l’effet sur plusieurs modèles de pointe actuels, ce qui indique une propriété de l’approche centrée sur la sortie plutôt que d’un seul fournisseur. Cet article décrit la faiblesse et ses mitigations uniquement ; il ne contient aucun détail opérationnel d’attaque, et les résultats du papier sur les catégories sensibles sont référencés, non reproduits.

Cet article couvre une recherche de sûreté publiée, dans une posture défensive. Si vous construisez sur des modèles à sûreté centrée sur la sortie, considérez l’« alternative serviable » du modèle comme relevant de la modération et du red teaming. Les sources sont citées avec leur date de publication ci-dessus.