Untrusted Content Masking : une défense prouvable pour les agents web
Un article de juillet 2026 restaure la frontière de confiance que les agents web perdent en lisant une page rendue — en masquant les zones DOM non fiables et en les routant vers un modèle à sortie typée pour bloquer l'injection par construction.
De quoi s’agit-il ?
Le 6 juillet 2026, Kristina Nikolić (ETH Zurich), Egor Zverev (ISTA), Javier Rando (Anthropic / ETH Zurich), Matthew Jagielski (Anthropic), Edoardo Debenedetti et Florian Tramèr (ETH Zurich) ont publié sur arXiv Untrusted Content Masking for Web Agents with Security Guarantees. L’article propose une défense — Untrusted Content Masking (UCM) — qui offre à un agent de navigation web une garantie prouvable contre le détournement de flux de contrôle par injection de prompt, tout en le laissant lire les pages et agir dessus.
Le problème de départ est connu. Les défenses assorties d’une garantie formelle contre l’injection de prompt reposent toutes sur une isolation stricte entre les instructions de confiance et les données non fiables. Dans une API d’appel d’outils textuelle, cette frontière est naturelle : l’agent lit l’interface d’une fonction, pas la charge utile brute non fiable. Un agent web n’a pas ce luxe — il doit observer une page rendue, qui, selon les auteurs, « entremêle contenu de confiance et contenu non fiable ». Cet enchevêtrement structurel dissout la frontière de confiance dont dépend la garantie. UCM cherche à la reconstruire à l’intérieur du navigateur. Il s’agit de travaux académiques évalués par les pairs sur une défense ; aucun exploit fonctionnel n’est reproduit ici.
Comment ça marche
L’observation clé : le DOM d’une page encode déjà assez de structure pour séparer les zones de confiance des zones non fiables sans en lire le contenu. UCM masque les zones non fiables avant même qu’elles n’atteignent l’agent, en remplaçant chacune par un espace réservé étiqueté qui conserve la mise en page et, si disponible, un label sémantique (advertisement, user comment, review) ainsi qu’un identifiant d’élément. L’agent voit la page de confiance complète et sa structure, mais n’est jamais exposé au texte ni aux images contrôlés par l’attaquant.
Lorsqu’une tâche a réellement besoin d’une valeur non fiable, l’agent ne la lit toujours pas. Il interroge un modèle en quarantaine (Q-Model) isolé : il référence l’identifiant de l’élément masqué, pose une question en langage naturel et déclare un type de retour parmi un ensemble fixe — bool, int, float, date, enum. Le Q-Model lit le contenu caché et renvoie une réponse contrainte par le type.
page rendue
├── zones de confiance ──────────► agent (visibilité totale)
└── zones non fiables
│ remplacées par un placeholder étiqueté [#c12: "user comment"]
▼
l'agent a besoin de la valeur ? ──► demande au Q-Model : "#c12 est-il un avis 5 étoiles ?" -> bool
▼
le Q-Model lit le texte caché, renvoie : true
│ (un bool ne peut pas transporter "navigate to evil.com")
▼
l'instruction injectée ne peut pas se propager dans le flux de contrôle de l'agent
Parce qu’un booléen ou un entier ne peut pas faire passer clandestinement une instruction en texte libre, le détournement de flux de contrôle est bloqué par construction, quelle que soit l’ingéniosité de l’injection. Qui trace les frontières ? Un propriétaire de site actif étiquette directement les zones non fiables — les auteurs constatent que 15 à 30 sélecteurs CSS par site suffisent pour GitLab, Booking.com et Reddit. Pour un propriétaire passif qui ne fournit rien, un LLM déduit les frontières à partir d’un DOM assaini de son contenu (structure et balises conservées, texte retiré pour que l’étiqueteur lui-même ne puisse être injecté) et émet des sélecteurs CSS.
Pourquoi c’est important
Ce sont les chiffres qui comptent. Face au benchmark WASP avec des attaques renforcées, UCM atteint 0 % de taux de succès d’attaque sur Claude Sonnet 4.5, Claude Sonnet 4.6 et GPT-5.4. L’utilité tient : sur dix suites de tâches sur mesure, l’agent masqué égale l’agent non protégé, pour un surcoût de 1,05×–1,84× — et environ 15 % des tâches sont en fait moins chères, car une page allégée est plus facile à parcourir. Sur de vraies tâches WebArena GitLab, le Q-Model à sortie typée résout la majorité des cas, et une option de repli par chaîne de caractères approuvée par l’utilisateur restaure l’utilité complète.
La leçon d’architecture prolonge des travaux comme la triade létale. Les filtres heuristiques peuvent être vaincus par des attaquants adaptatifs ; les défenses garanties antérieures achetaient leur garantie en rendant l’agent aveugle au contenu de la page, ce qui détruisait l’utilité. UCM supprime au contraire la surface d’attaque — le contenu non fiable n’entre jamais dans le contexte de l’agent — tout en laissant l’agent dérouler sa boucle habituelle de raisonnement et d’action.
Défenses
Pour les équipes qui construisent ou durcissent des agents à usage d’ordinateur, l’article propose un motif concret plutôt qu’un filtre de plus.
Tracez la frontière de confiance au niveau du DOM, pas dans le flux de tokens. Décider ce qui est de confiance à partir de la structure — avant qu’un quelconque texte non fiable ne soit lu — est ce qui rend l’isolation solidement applicable, contrairement aux filtres par mots-clés ou par classifieur qui doivent d’abord ingérer la charge utile.
Routez les lectures non fiables via un modèle isolé à sortie typée. Contraindre le Q-Model à répondre en bool/int/date/enum est le mécanisme qui empêche une instruction injectée de revenir sous forme de flux de contrôle. Réservez l’extraction de texte libre à un chemin d’approbation explicite de l’utilisateur.
Attention au risque résiduel de flux de données. UCM garantit l’intégrité du flux de contrôle, pas la justesse des valeurs : une réponse bien typée mais choisie par l’attaquant peut encore induire en erreur. Les auteurs bornent ce risque en interrogeant chaque élément non fiable dans un appel Q-Model frais et isolé, de sorte que la manipulation d’agrégats exige que l’attaquant contrôle une large part des entrées, et en signalant plusieurs correspondances positives comme signal d’altération. Complétez avec des politiques au niveau des actions et une confirmation utilisateur pour les actions sensibles.
Connaissez l’ancrage de confiance. La garantie suppose un propriétaire de site honnête et un étiquetage correct ; un site entièrement malveillant reste dangereux quoi qu’il arrive, et les failles de contenu actif (XSS qui échappe à une zone étiquetée ou réécrit le DOM à l’exécution) sont explicitement hors périmètre.
Statut
| Élément | Détail |
|---|---|
| Divulgation | Préprint arXiv 2607.05277 v1, publié le 6 juillet 2026 (CC BY 4.0) |
| Classe | Défense — intégrité de flux de contrôle prouvable contre l’injection sur agents web via masquage DOM + modèle typé en quarantaine |
| Testé sur | Agents : Claude Sonnet 4.5, Claude Sonnet 4.6, GPT-5.4 · Q-Model : Claude Sonnet 4.5 |
| Résultat rapporté | 0 % d’ASR sur WASP renforcé ; utilité préservée ; surcoût 1,05×–1,84× |
| Étiquetage des frontières | Propriétaire actif : 15–30 sélecteurs CSS/site · Propriétaire passif : inférence LLM sur DOM assaini (F1 0,84–0,997) |
| Limites connues | Attaques de flux de données (valeurs bien typées mais fausses) ; hypothèse propriétaire honnête + étiquetage correct ; XSS / contenu actif hors périmètre |
| Code | github.com/ethz-spylab/untrusted-content-masking |