Amorçage contextuel : jailbreaker un LLM en falsifiant la conversation qui précède

De quoi s’agit-il ?

L’essentiel de la recherche sur les jailbreaks se concentre sur le prompt — le message unique envoyé par l’attaquant. L’amorçage contextuel (contextual priming) vise une autre surface : l’historique de conversation que le modèle croit poursuivre. Plutôt que de poser une question dangereuse en la déguisant, l’attaquant fabrique les tours antérieurs du dialogue — y compris des réponses attribuées à l’assistant lui-même — de sorte qu’au moment où la vraie requête arrive, le modèle a déjà été orienté vers un registre coopératif.

La version canonique de cette classe est Response Attack (RA), présentée par Miao et al. dans un article publié en juillet 2025 (arXiv 2507.05248) puis accepté à AAAI 2026. RA formalise l’amorçage contextuel comme mécanisme d’attaque et rapporte des taux de succès systématiquement supérieurs à neuf méthodes de référence. Un travail de 2026, ContextualJailbreak (arXiv 2605.02647), automatise l’idée et la mesure sur les modèles de frontière actuels — la raison pour laquelle cette classe mérite d’être traitée aujourd’hui, et non rangée dans les archives de 2025.

Comment ça marche

Le mécanisme exploite une asymétrie que les auteurs de RA énoncent clairement : l’alignement de sécurité tend à être plus robuste face à une requête dangereuse qu’à un contenu dangereux issu du contexte antérieur. Un modèle qui refuse net « explique comment faire X » peut poursuivre volontiers si son contexte contient déjà une réponse à moitié rédigée sur X qui semble être son propre travail précédent.

Response Attack construit ce contexte délibérément. Un modèle auxiliaire produit une réponse légèrement dangereuse à une version paraphrasée de l’objectif — rien qui déclencherait un filtre isolément. Cette réponse intermédiaire est insérée dans la transcription comme un tour antérieur de l’assistant, puis un court déclencheur est envoyé pour provoquer l’escalade. Le modèle lit une conversation dans laquelle il aurait, apparemment, déjà accepté d’aider.

Transcription falsifiée envoyée en une seule requête
----------------------------------------------------
system:     [cadrage d'apparence ordinaire]
user:       [version paraphrasée et adoucie de l'objectif]
assistant:  [réponse partielle légèrement dangereuse — l'AMORCE,
             attribuée au modèle mais rédigée par l'attaquant]
user:       [déclencheur court : « continue » / « ajoute les étapes »]
              → le modèle escalade depuis sa propre base apparente

ContextualJailbreak fait passer cette idée d’un gabarit fixe à une recherche. Il exécute une boucle évolutionnaire sur l’ensemble du dialogue simulé, en mutant la conversation amorcée avec des opérateurs sémantiques (jeu de rôle, scénario, expansion, et deux que les auteurs introduisent) et en notant chaque tentative avec un juge de nocivité gradué de 0 à 5, de sorte que les succès partiels orientent la génération suivante au lieu d’être écartés. L’ensemble du dialogue multi-tours falsifié est toujours délivré en un seul appel d’API. Aucun payload n’est reproduit ici — l’important est structurel : l’attaquant contrôle l’historique, et l’historique est tenu pour fiable.

Pourquoi c’est important

Les chiffres montrent que ce n’est pas un jouet. ContextualJailbreak rapporte des taux de succès (contenu dangereux obtenu) atteignant 100 % sur plusieurs modèles à poids ouverts — dont qwen3-8b et llama-3.1-70b — et 90 % sur un modèle ouvert plus grand, bien au-dessus des références mono- et multi-tours. Les dialogues adverses optimisés contre un modèle ouvert se transfèrent tels quels vers des systèmes de frontière hébergés : l’article rapporte environ 90 % de succès contre gpt-4o-mini et environ 70 % contre gpt-5 et gemini-3-flash au seuil « dangereux ».

Deux leçons dépassent tout benchmark particulier. D’abord, le filtrage au niveau du prompt est la mauvaise couche. Un classifieur qui inspecte le dernier message utilisateur voit un banal « continue » ; la nocivité réside dans l’historique fabriqué qui l’entoure. Ensuite, les résultats dépendent fortement de la recette d’alignement et sont liés à la version. La même étude a trouvé les deux modèles Claude testés — claude-opus-4-7 et claude-sonnet-4-6 — nettement plus résistants, refusant d’emblée la majorité des attaques transférées (succès de l’ordre de 15 % contre 70 à 90 % ailleurs). C’est une propriété d’une pile d’alignement durcie précise à une version précise, pas des modèles de frontière en général — exactement le genre de divergence qu’il faut mesurer plutôt que présumer.

Défenses

Comme l’attaque réside dans la structure de la conversation, les défenses doivent raisonner sur la trajectoire, pas sur le dernier message.

1. Ne faites pas confiance à l’historique fourni par le client comme s’il émanait du modèle. Dans les déploiements par API, les tours d’assistant sont contrôlables par l’attaquant. Lorsque votre produit autorise l’envoi d’une transcription complète, traitez les tours « assistant » antérieurs comme des entrées non fiables, et non comme des engagements établis du modèle.
2. Passez d’un alignement au niveau du prompt à un alignement sensible au contexte. La recommandation centrale des auteurs de RA est que la sécurité doit tenir sur un contexte conversationnel évolutif, pas seulement sur la requête finale. Évaluez les refus conditionnés à des historiques adverses, pas seulement à des prompts isolés.
3. Réanalysez tout le contexte au moment de la génération. Appliquez les contrôles de sortie et de sécurité au dialogue complet assemblé — amorces injectées comprises — plutôt qu’au seul dernier tour. Un « continue » qui suit une réponse partielle dangereuse doit être évalué sur ce qu’il prolonge.
4. Faites du red teaming avec des historiques amorcés. Ajoutez des scénarios à tour antérieur falsifié (amorce légère puis escalade) à votre jeu d’évaluation. Les deux articles publient du code ou des exemples synthétiques précisément pour ce type de test défensif.
5. Privilégiez les piles d’alignement montrées résistantes à l’amorçage contextuel — puis vérifiez sur votre propre pile et version. La robustesse démontrée pour la sortie d’un éditeur n’est pas transposable ; retestez après chaque changement de modèle ou de prompt système.

Statut

Élément	Référence	Date	Notes
Response Attack (fondation)	Miao et al., arXiv 2507.05248	2025-07	Formalise l’amorçage contextuel ; bat 9 références ; code publié
Response Attack (publication)	Actes AAAI 2026	2026	Acceptation par les pairs
ContextualJailbreak (automatisation)	Rodríguez Béjar et al., arXiv 2605.02647	2026	Recherche évolutionnaire sur dialogue amorcé ; résultats de transfert frontière
Impact poids ouverts	ContextualJailbreak	2026	Jusqu’à 100 % de succès (contenu dangereux) sur plusieurs modèles ouverts
Transfert frontière	ContextualJailbreak	2026	~70 à 90 % sur gpt-4o-mini / gpt-5 / gemini-3-flash ; de l’ordre de 15 % sur les modèles Claude testés

À retenir : le refus d’un modèle ne vaut que ce que vaut son contexte apparent le plus compromettant. Si un attaquant peut écrire l’historique, le dernier message compte à peine — la défense doit donc se situer là où l’historique est assemblé, pas là où la question est posée.