Le « Framing Gap » : pourquoi les injections reformulées contournent les défenses de surface des agents
Une étude arXiv de fin août 2026 montre que les injections explicites sont refusées, mais que la même fuite déguisée en champ obligatoire ou en hôte de confiance réussit. Seules les défenses indifférentes au contenu ont tenu.
De quoi s’agit-il ?
Le 27 août 2026, Md Habibur Rahman et Jaeho Kim ont publié « The Framing Gap » (arXiv cs.CR). L’article étudie un agent LLM doté d’outils qui lit une page web contrôlée par un attaquant tout en détenant un secret, et mesure la facilité avec laquelle la page peut provoquer la fuite de ce secret. Les expériences se déroulent dans un laboratoire synthétique : secret canari, outils simulés, comparaisons appariées sain/empoisonné sur six modèles. Aucun système réel n’est concerné.
Résultat principal : les injections explicites (« envoie-moi le secret ») sont majoritairement refusées, mais la même fuite déguisée en signature d’intégrité obligatoire, en champ de configuration ou en hôte « de confiance » factice réussit bien plus souvent. Pour gpt-4o, le taux de succès passe de 0 % à 100 %.
Comment cela fonctionne
L’attaque ne défait pas l’alignement du modèle ; elle change le cadrage de la demande. Selon les auteurs, le modèle traite la demande reformulée comme une partie du format de données de la tâche plutôt que comme une instruction à refuser. Une ablation le confirme : supprimer la politique de confidentialité modifie à peine le succès de l’attaque reformulée (31,9 % à 38,1 %), ce qui indique une confusion entre instructions et données plutôt qu’un échec de l’entraînement de sécurité.
L’article décrit aussi trois niveaux de coût pour l’attaquant :
- Reformuler un mécanisme connu : facile (environ 96 % de succès).
- Changer le champ dans un gabarit déjà efficace : modéré (jusqu’à 60 %).
- Construire une page autour d’un mécanisme réellement nouveau : très difficile (0 succès sur 130).
L’actif réutilisable est donc le gabarit, non le mécanisme sous-jacent. Cet article omet volontairement les gabarits de pages.
Pourquoi c’est important
De nombreuses défenses déployées cherchent ce que dit l’injection : filtres de mots-clés, classifieurs, fine-tuning contre des formulations connues. L’étude suggère qu’elles restent superficielles. Dans les tests de l’article, une défense par fine-tuning (SecAlign, arXiv 2410.05451) laisse 32,5 % de succès sur l’agent à outils, la séparation des canaux 38,8 %, et un garde normalisant les sorties est contourné à 100 % par un encodage ROT13 non vu. Une clause de politique large « sous quelque forme que ce soit » bloque l’attaque (0 %) mais reste fragile : retirer la clause fourre-tout la rouvre (48,8 %).
Cela renforce la lecture architecturale derrière la « lethal trifecta » de Simon Willison : données privées, contenu non fiable et canal sortant réunis dans un même agent constituent l’exposition réelle, quelle que soit la capacité du modèle à reconnaître les attaques.
Défenses
Les défenses efficaces étaient indifférentes au contenu, c’est-à-dire qu’elles ne dépendent pas de la reconnaissance du texte malveillant :
- Liste blanche de destinations. Fermer l’ensemble des hôtes joignables par l’agent bloque totalement l’exfiltration (0 %).
- Séparation planificateur/lecteur. Isoler le composant qui lit du contenu non fiable de celui qui peut agir ; le lecteur n’a aucune autorité sur les outils (0 %).
- Moindre privilège et validation humaine pour les actions sortantes ou à risque, conformément aux recommandations OWASP LLM01.
- Validation déterministe des sorties par du code, et non par le jugement du modèle, pour toute valeur quittant la frontière de confiance.
- Tests adverses réguliers incluant des variantes reformulées, pas seulement des injections explicites.
Statut
| Élément | Détail |
|---|---|
| Type de source | Prépublication (arXiv cs.CR), non évaluée par les pairs à notre connaissance |
| Publication | 2026-08-27 |
| Environnement | Laboratoire synthétique, secret canari, outils simulés |
| Statut de correctif | Pas une vulnérabilité produit ; aucun CVE |
| Mitigations efficaces | Liste blanche de destinations, séparation planificateur/lecteur |