SnapGuard : détecter l'injection dans ce que l'agent voit, pas dans ce qu'il parse

De quoi s’agit-il ?

SnapGuard est une technique défensive pour détecter l’injection de prompt visant les agents web fondés sur captures d’écran — cette famille d’agents « computer use » (Computer Use d’Anthropic, l’agent navigateur d’OpenAI, SeeAct, UI-TARS) qui décident quoi faire en regardant une capture d’écran rendue d’une page plutôt qu’en parsant son HTML ou son DOM. La méthode est décrite dans « SnapGuard: Lightweight Prompt Injection Detection for Screenshot-Based Web Agents », arXiv:2604.25562, publié le 28 avril 2026.

L’observation centrale : la plupart des défenses déployées sont centrées sur le texte. Elles inspectent le HTML, le DOM ou la sortie textuelle d’un outil à la recherche d’instructions malveillantes. Or un agent fondé sur captures d’écran ne lit jamais ce texte — il lit des pixels. Une instruction présente uniquement dans l’image rendue (ou rendue d’une façon que le scanner HTML ne signale pas) passe donc directement à travers ces garde-fous. SnapGuard déplace le détecteur sur le canal que l’agent utilise réellement : la capture d’écran.

Comment ça marche

Des défenses multimodales existaient déjà, mais elles s’appuyaient sur un grand modèle vision-langage (VLM) chargé de lire toute la page et de la juger. C’est coûteux : une page web moderne est dense, et demander à un gros VLM d’en comprendre la sémantique globale à chaque étape consomme du temps d’inférence et de la mémoire GPU. La contribution de SnapGuard est de reformuler la détection comme une analyse de représentation multimodale plus économique sur la capture d’écran, fondée sur deux signaux complémentaires.

Le premier est un indicateur de stabilité visuelle. Le contenu injecté est souvent inséré sous forme de régions visuellement uniformes — bannières plates, surcouches, blocs de texte rembourrés — qui produisent des distributions de gradients anormalement lisses par rapport à la texture organique d’une vraie page. SnapGuard signale ces régions statistiquement anormales sans avoir à comprendre ce qu’elles disent.

Le second est un signal textuel orienté action, récupéré par inversion de polarité de contraste. Les charges utiles d’injection sont fréquemment dissimulées dans du texte à faible contraste ou quasi invisible, pour qu’un humain ne le remarque pas mais qu’un agent capable le lise quand même. Inverser la polarité de contraste fait ressortir ce texte ténu, qu’un extracteur léger peut ensuite analyser à la recherche de formulations impératives déclenchant une action (« envoyer », « approuver », « aller à… »).

Capture d'écran (ce que l'agent voit)
        │
        ├─▶ contrôle de stabilité visuelle ── région plate/uniforme ? ──┐
        │                                                               ├─▶ alerte
        └─▶ inversion de polarité ── texte impératif caché ? ───────────┘

  Pas de passe VLM sur toute la page. ~1,81 s par page (mesuré).

Dans l’évaluation du papier, SnapGuard atteint un F1 de 0,75 contre 0,71 pour une baseline de prompting GPT-4o, tout en s’exécutant environ 8× plus vite (~1,81 s par page). L’enjeu n’est pas que 0,75 résolve le problème — c’est qu’on obtient une détection compétitive sur le canal visuel sans payer un jugement VLM complet à chaque action.

Pourquoi c’est important

Les agents fondés sur captures d’écran sont précisément ceux que l’on souhaite le plus protéger, car ils disposent généralement d’une portée large, au niveau système : un navigateur qu’ils pilotent, des fichiers qu’ils manipulent, des formulaires qu’ils soumettent. Ce sont aussi les agents que les défenses existantes couvrent le plus mal. Un garde-fou qui inspecte le HTML est structurellement aveugle à une charge utile qui n’existe que dans les pixels rendus — le même angle mort qui rend efficaces l’injection par image seule et les benchmarks d’injection visuelle. SnapGuard compte parce qu’il place un détecteur sur le canal auquel l’agent fait confiance, à un coût assez faible pour tourner en ligne à chaque étape.

Il faut être précis sur le périmètre. SnapGuard défend le canal visuel ; selon le cadrage même des auteurs, il n’attrape pas les injections uniquement HTML qui ne s’affichent jamais visiblement. C’est donc un complément, et non un remplacement, des garde-fous côté texte et des benchmarks comme WAInjectBench. La lecture honnête : les agents à captures d’écran ont besoin des deux détecteurs, côté pixels et côté balisage, car un attaquant n’a besoin que du canal que votre pile a oublié.

Défenses

SnapGuard est lui-même une défense ; l’essentiel est donc de bien le déployer — et de savoir quoi disposer autour.

1. Détecter sur le canal réellement consommé par l’agent. Si votre agent agit sur des captures d’écran, un garde-fou texte/DOM ne suffit pas. Faites tourner un détecteur côté pixels (style SnapGuard : stabilité des gradients + inversion de polarité) sur l’image même que l’agent raisonne, à chaque étape, pas seulement au chargement de la page.

2. Conserver aussi le garde-fou côté balisage. Comme le détecteur visuel rate les charges utiles uniquement HTML, associez-le à un scanner texte/DOM. Traitez-les comme couvrant des angles morts différents, et alertez si l’un ou l’autre se déclenche.

3. Ne pas faire de la détection l’unique ligne. Les détecteurs tournent à un F1 non trivial, pas à 1,0 — certaines injections passeront. Combinez-les avec des contrôles architecturaux pour qu’une détection manquée ne soit pas une compromission : verrouillez les actions à fort impact (achats, envois, suppressions, usage d’identifiants) derrière des vérifications de politique explicites ou une confirmation humaine, et limitez strictement les identifiants de l’agent. C’est la logique de la triade létale et de la règle de deux des agents : si le contenu de page non fiable, la capacité sensible et la voie d’exfiltration ne peuvent coexister, une charge utile manquée ne dégénère pas.

4. Budgéter le coût en ligne. Si les équipes évitent le jugement VLM à chaque étape, c’est par latence et coût GPU. Un détecteur léger comme SnapGuard rend le filtrage par étape abordable, ce qui permet de le faire tourner réellement en production plutôt qu’en audit hors ligne.

5. Re-tester sur votre propre agent et vos pages. Le F1 d’un détecteur dépend du jeu de données. L’heuristique de stabilité visuelle peut générer des faux positifs sur des interfaces légitimement plates (modales, emplacements publicitaires), et l’inversion de contraste peut rater du texte rendu sous forme d’image aplatie. Mesurez le taux de faux positifs sur votre trafic réel avant de lui confier le verrouillage d’actions, et réglez-le vers le signalement/la rédaction plutôt que le blocage dur de toute la page.

Statut

Élément	Référence	Date	Notes
Papier SnapGuard	arXiv:2604.25562	2026-04-28	Détecteur léger pour agents web à captures d’écran
Résultat rapporté	F1 0,75 vs 0,71 (baseline GPT-4o-prompt)	—	~8× plus rapide, ~1,81 s par page
Signaux utilisés	Indicateur de stabilité visuelle + texte à polarité inversée	—	Pas de passe VLM sur toute la page
Limite annoncée	Canal visuel uniquement	—	Rate les injections uniquement HTML ; à associer à un garde-fou texte/DOM
Connexes	WARD, VPI-Bench (arXiv:2506.02456), WAInjectBench (arXiv:2510.01354)	—	Défenses/benchmarks d’injection pour agents web

Le bon cadrage n’est pas « un garde-fou de plus ». C’est que les défenses doivent vivre sur le même canal que celui que lit l’agent — et pour une classe croissante d’agents, ce canal est une capture d’écran, pas une chaîne de caractères.