Séparateurs dynamiques : durcir le Polymorphic Prompt Assembling contre l'injection

De quoi s’agit-il ?

Le 28 mai 2026, Nima Dorzhiev et Peng Liu ont publié Strengthening Polymorphic Prompt Assembling: Dynamic Separator Generation Against Emerging Prompt Injection Attacks (arXiv:2605.30534). C’est un papier défensif court — cinq pages — qui corrige une faiblesse d’une défense existante contre la prompt injection, plutôt que d’annoncer une nouvelle attaque.

La défense en question est le Polymorphic Prompt Assembling (PPA), introduit dans arXiv:2506.05739 en juin 2025. L’idée du PPA est simple : la prompt injection exige généralement que l’attaquant devine et casse la structure qui sépare les instructions système de confiance de l’entrée utilisateur non fiable. Si l’on rend cette structure aléatoire, l’attaquant ne peut plus prédire de façon fiable où se situe la frontière. Le PPA tire des paires de séparateurs depuis un pool fixe au moment de l’assemblage, à un coût d’exécution quasi nul. Le papier de mai 2026 identifie ce que ce pool fixe laisse passer, et le comble.

Comment ça marche

La faille visée par le nouveau papier est le rayon d’impact (blast radius). Dans le PPA d’origine, les séparateurs sont tirés d’un pool statique. Les pools sont finis, et les séparateurs peuvent fuiter — un payload injecté qui parvient à réafficher ou refléter le délimiteur courant le dévoile. Une fois un séparateur connu, il peut être réutilisé contre toute requête future qui tire la même paire. Une seule fuite compromet de nombreuses requêtes.

Le correctif consiste à ne plus réutiliser de séparateurs du tout. Au lieu de tirer dans un pool, la défense dérive un délimiteur frais pour chaque requête à partir d’un condensé SHA-256 à séparation de domaine, clé par trois entrées :

separator = H( domain_tag || timestamp || session_id || nonce )
                    │            │            │           │
        évite les collisions     entropie par      imprévisible
        inter-contextes          requête           à chaque appel

Chaque prompt assemblé reçoit une paire canari (BEGIN, END) unique. Comme la paire n’est jamais réutilisée, un séparateur qui fuite n’expose que l’unique requête à laquelle il appartenait — le rayon d’impact passe de « de nombreuses requêtes futures » à « une seule ». La construction est déterministe à partir de ses entrées (le harnais peut donc toujours reconnaître ses propres délimiteurs lorsqu’il analyse la sortie du modèle) mais imprévisible pour un attaquant dépourvu du nonce.

Les chiffres rapportés, évalués sur Llama-3.3-70B-Instruct-Turbo avec validation croisée sur DeepSeek-V4-Flash :

• Contre le payload d’obfuscation « M1 » (leetspeak et formulation d’urgence), le mode dynamique a abaissé le taux de succès d’attaque de 0,88 à 0,38 — une réduction de 2,3× que les auteurs rapportent comme statistiquement significative via des intervalles de confiance de Wilson à 95 % non chevauchants.
• Contre un payload format_breakout_salad, le taux de fuite des séparateurs statiques (0,467) est tombé à 0,000 en mode dynamique, confirmant empiriquement l’argument du rayon d’impact.
• Le surcoût est de 2,7 microsecondes d’assemblage de prompt par requête, sans fine-tuning du modèle, et le changement est rétrocompatible avec le SDK PPA existant.

Notez le plafond, exposé honnêtement : un taux de 0,38 est une nette amélioration, pas une immunité. La randomisation structurelle augmente le coût de l’injection ; elle ne l’élimine pas.

Pourquoi c’est important

La prompt injection reste en tête du Top 10 OWASP pour les applications LLM (LLM01), et la plupart des garde-fous en production tombent dans deux camps : des classifieurs lourds à base de modèles qui ajoutent de la latence tout en manquant les formulations inédites, ou des filtres de chaînes fragiles. Le PPA relève d’une troisième catégorie — une défense structurelle peu coûteuse qui ne dépend pas de la reconnaissance du contenu d’une attaque, mais seulement du fait de priver l’attaquant de la connaissance de la disposition du prompt.

Le résultat sur les séparateurs dynamiques compte parce qu’il montre que cette catégorie dispose d’un levier d’ingénierie net. Passer d’un pool statique à une dérivation par requête est une petite modification de code, au gain de sécurité mesurable et reproductible, pour un coût à l’échelle de la microseconde. Pour les équipes qui assemblent déjà leurs prompts à partir de gabarits, c’est le genre de mitigation qui se livre en une après-midi plutôt qu’en un trimestre — et qui se compose avec les classifieurs et le cloisonnement des capacités, sans les remplacer.

Défenses

Si vous développez des applications LLM et voulez appliquer la leçon :

1. Traitez la frontière du prompt comme un secret, par requête. Quel que soit le schéma de séparation entre instructions système et entrée non fiable, ne réutilisez pas un jeu fixe de délimiteurs. Dérivez-les par requête à partir de matériel imprévisible (un nonce, plus session et horodatage), afin qu’une seule fuite ne puisse être rejouée.
2. Utilisez une séparation de domaine dans la dérivation. Une étiquette de domaine dans l’entrée du hachage empêche un séparateur généré pour un contexte d’être valide dans un autre — la même hygiène que la dérivation de clés cryptographiques.
3. Tenez les délimiteurs hors des chemins de réflexion visibles par le modèle. Supprimez ou neutralisez tout écho des séparateurs courants dans les sorties d’outils et les réponses du modèle avant qu’ils ne réintègrent un prompt, pour réduire d’emblée la surface de fuite.
4. Superposez, ne substituez pas. La randomisation structurelle est un multiplicateur de force, pas une garantie — un taux résiduel de 0,38 reste réel. Combinez-la avec le filtrage entrée/sortie, des portées d’outils au moindre privilège, et la discipline de la « triade létale » : ne pas accorder à un composant qui traite des entrées non fiables à la fois l’accès aux données privées et un canal d’exfiltration.
5. Mesurez avec des intervalles de confiance. L’usage par le papier d’intervalles de Wilson plutôt que de pourcentages bruts est une bonne habitude. Lorsque vous testez un garde-fou en A/B, rapportez l’incertitude pour qu’un écart bruité de 5 points ne soit pas pris pour un effet réel.

Statut

Élément	Référence	Date	Notes
Polymorphic Prompt Assembling (PPA)	arXiv:2506.05739	2025-06	Défense d’origine ; pool de séparateurs statique
Génération de séparateurs dynamiques	arXiv:2605.30534	2026-05-28	Séparateurs SHA-256 par requête ; corrige le rayon d’impact
Modèles d’évaluation	selon le papier	2026-05	Llama-3.3-70B-Instruct-Turbo ; DeepSeek-V4-Flash (croisé)
Effet rapporté	selon le papier	2026-05	Payload M1 : 0,88 → 0,38 ; taux de fuite 0,467 → 0,000
Surcoût	selon le papier	2026-05	~2,7 µs/requête ; sans fine-tuning ; SDK rétrocompatible

À retenir : non, « la prompt injection n’est pas résolue ». Mais une défense structurelle connue avait un bug de secret réutilisé, quelqu’un l’a corrigé avec une dérivation par requête, et les chiffres publiés disent que le correctif est peu coûteux et mesurable. C’est exactement le type de durcissement incrémental pour lequel les défenseurs devraient lire la littérature.