Les agents navigateurs résistent à l'injection artisanale — pas les agents de code

De quoi s’agit-il ?

Un preprint publié sur arXiv en juin 2026 par Nicholas Saban (Patronus AI / UC Berkeley), Domain-Conditioned Safety in Frontier Computer-Using Agents, pose une question que tout praticien déployant un agent devrait se poser : quand un article de red teaming annonce un taux de réussite d’injection de plus de 90 %, ce chiffre tient-il encore sur le modèle que vous faites réellement tourner aujourd’hui ?

La réponse documentée est non — et la raison est inconfortable pour la discipline. Les taux de réussite d’attaque (ASR) publiés dans la littérature sur les agents computer-use (CUA), qui vont d’environ 42 % à 98 %, se concentrent sur des modèles retirés et sur le modèle le plus faible du panel de chaque article. Reproduites en simples templates écrits à la main sur les modèles de pointe actuels, la plupart de ces techniques cessent totalement de fonctionner. Mais ce durcissement s’avère étroit : il vit sur la surface navigateur que les éditeurs stressent en priorité, et il ne se transpose pas aux fichiers de skills des agents de code.

Comment ça marche

L’étude publie CUA-HANDCRAFTED, un benchmark public de 793 épisodes couvrant 24 tâches web multi-étapes réparties sur 8 sites, 56 templates d’attaque issus de 8 familles, 5 niveaux de profondeur d’injection et 4 configurations de prompt système. Point essentiel : les attaques ne sont pas nouvelles — ce sont des reconstructions lisibles par un humain des techniques décrites dans les articles de red teaming antérieurs (RL-Hammer, WASP, TRAP, RedTeamCUA, MUZZLE, superpositions de pop-ups), transcrites depuis la prose de ces papers plutôt que rejouées depuis des chaînes publiées.

Testé sur deux modèles de pointe actuels, le résultat navigateur constitue un plancher :

Surface du benchmark        Modèle           ASR artisanal
--------------------------  ---------------  --------------------------------
Navigateur (multi-étapes)   Sonnet 4.6       0 / 140  (borne sup. 95 % : 2,60 %)
Navigateur (multi-étapes)   GPT-5.4          inclus dans le même 0/140
Navigateur, ablation prompt L0_bare/L1_help  toujours 0 % — résistance dans les poids
Skills de code (SKILLBENCH) Sonnet 4.6       jusqu'à 40 / 40  = 100 %
Skills de code (SKILLBENCH) GPT-5.4          jusqu'à 79 / 100 = 79 %

Deux choix de conception rendent le résultat navigateur crédible. D’abord une ablation de prompt : réduire le prompt système à une configuration nue ou simplement serviable ne rouvre pas les attaques, ce qui signifie que la résistance à l’injection est inscrite dans les poids du modèle, et non ajoutée par un prompt système défensif. Ensuite un plafond d’attaquant RL : un attaquant adaptatif à suffixe aléatoire intégré au harness (une baseline de type AutoInject) obtient lui aussi 0/100 dans un budget de cinq requêtes par cible et environ 10 $ de dépense API — preuve que l’écart entre attaques artisanales et attaques publiées tient à la formulation optimisée, pas à la catégorie d’attaque. Une réplication de 50 épisodes de la classe pop-up par canal image (VPI-Bench) tombe à environ 3 % sur les modèles de pointe, refermant une attaque du canal image à laquelle les anciens modèles cédaient. Aucun payload optimisé n’est reproduit ici ; l’intérêt réside entièrement dans la mesure.

Pourquoi c’est important

L’article recadre un chiffre que les équipes sécurité se citent entre elles. Les taux de 42 à 98 % de la littérature semblent tenir avant tout aux chaînes d’injection découvertes par RL, hors distribution, et non aux idées d’attaque que ces papers nomment. Quand la chaîne n’est pas publiée — et l’audit constate que « modèle cible retiré + chaînes non publiées » s’applique à quatre des six papers examinés — le chiffre annoncé n’est pas reproductible sur le modèle que vous déployez. C’est autant un problème de sourcing qu’un problème de sécurité, et c’est exactement le type d’affirmation qu’un défenseur doit pouvoir vérifier avant de bâtir un budget dessus.

Le résultat le plus lourd de conséquences est le durcissement conditionné au domaine. Les mêmes poids Claude Sonnet 4.6 qui résistent à l’injection navigateur à 0/140 cèdent à l’injection de skills artisanale dans un harness d’agent de code jusqu’à 100 % ; GPT-5.4 cède jusqu’à 79 %. La system card de Sonnet 4.6 d’Anthropic rapporte elle-même une injection navigateur passant d’environ 49 % à environ 1,3 % entre deux générations de modèle — une vraie amélioration de 38×, mais que ce travail montre spécifique à la modalité navigateur. Les éditeurs durcissent la surface que les chercheurs martèlent le plus, et cet effort ne se généralise pas automatiquement aux surfaces d’appels d’outils et de fichiers de skills qu’exposent les agents de code. C’est l’extension outil-contre-outil de l’observation antérieure selon laquelle la sûreté au niveau texte ne se transpose pas aux surfaces d’appels d’outils.

En pratique : n’extrapolez pas un score de sûreté d’agent navigateur à votre agent de code, à vos outils MCP ou à votre pipeline de skills d’agent. Ce sont des surfaces de menace différentes, au durcissement différent — et, à l’aune des preuves actuelles, bien plus faible.

Défenses

• Traitez les ASR publiés comme spécifiques à une surface. Un faible taux d’injection navigateur sur un modèle de pointe ne dit presque rien de ce même modèle dans un harness d’agent de code ou MCP. Re-mesurez sur la surface que vous déployez réellement, et privilégiez les benchmarks qui publient leurs chaînes d’attaque pour que vous puissiez les reproduire.
• Durcissez l’ingestion de skills des agents de code séparément. Puisque l’injection de skills est l’endroit où les poids de pointe échouent encore, appliquez-y des contrôles de provenance, la revue ou le sandboxing des skills tiers et un cloisonnement d’outils au moindre privilège — ne supposez pas que l’alignement au niveau modèle couvre ce point. Voir notre couverture des skills d’agent malveillants et du red teaming de skills.
• Maintenez des contrôles hors bande quel que soit le score du modèle. La résistance au niveau des poids est bienvenue mais fragile d’un domaine à l’autre ; associez-la à des défenses hors bande évaluées de façon adaptative, des limites d’exfiltration et une confirmation humaine pour les actions à conséquence, conformément au cadre de la trifecta létale.
• Quand vous faites du red teaming, publiez les chaînes. La reproductibilité est une défense : une attaque que vous ne pouvez pas rejouer est une attaque que vous ne pouvez pas tester en régression après la prochaine mise à jour de modèle. Rapportez le texte optimisé, la version exacte du modèle et le harness, sinon le chiffre se dégrade en folklore.
• Surveillez les désaccords entre benchmarks. Ce résultat s’inscrit dans un constat plus large : les benchmarks de sûreté se contredisent entre eux ; triangulez plusieurs sources avant de faire confiance à un seul chiffre.

Statut

Élément	Détail
Publication	Preprint arXiv, juin 2026 (Saban, Patronus AI / UC Berkeley)
ASR navigateur (pointe)	0/140 multi-étapes ; borne sup. Clopper–Pearson 95 % : 2,60 %
ASR skills de code (mêmes poids)	jusqu’à 100 % (Sonnet 4.6), jusqu’à 79 % (GPT-5.4)
Benchmark publié	CUA-HANDCRAFTED — 793 épisodes, 56 templates, 8 familles d’attaque
Audit de reproductibilité	« cible retirée + chaînes non publiées » dans 4 papers sur 6
Référence éditeur	System card Sonnet 4.6 d’Anthropic : ASR injection navigateur ~49 % → ~1,3 %

Il s’agit d’un résultat de recherche/benchmark, pas d’une vulnérabilité produit ; aucun CVE ne s’applique. Les versions de modèles et les chiffres sont ceux rapportés par le preprint cité et la system card de l’éditeur.