SnapGuard: detectar la inyección en lo que el agente ve, no en lo que parsea
Un artículo de abril de 2026 propone un detector ligero para agentes web basados en capturas de pantalla, donde las defensas textuales son ciegas. Lee los píxeles renderizados — estabilidad de gradientes y texto con polaridad invertida — en 1,81 s por página.
¿Qué es esto?
SnapGuard es una técnica defensiva para detectar la inyección de prompts dirigida a agentes web basados en capturas de pantalla — esa familia de agentes «computer use» (Computer Use de Anthropic, el agente de navegador de OpenAI, SeeAct, UI-TARS) que deciden qué hacer mirando una captura renderizada de la página en lugar de parsear su HTML o su DOM. El método se describe en «SnapGuard: Lightweight Prompt Injection Detection for Screenshot-Based Web Agents», arXiv:2604.25562, publicado el 28 de abril de 2026.
La observación central: la mayoría de las defensas desplegadas están centradas en el texto. Inspeccionan el HTML, el DOM o la salida textual de una herramienta en busca de instrucciones maliciosas. Pero un agente basado en capturas nunca lee ese texto — lee píxeles. Una instrucción presente solo en la imagen renderizada (o renderizada de un modo que el escáner de HTML no marca) atraviesa por tanto esas defensas sin más. SnapGuard traslada el detector al canal que el agente usa realmente: la captura de pantalla.
Cómo funciona
Ya existían defensas multimodales, pero se apoyaban en un gran modelo de visión-lenguaje (VLM) encargado de leer toda la página y juzgarla. Eso es costoso: una página web moderna es densa, y pedir a un VLM grande que comprenda su semántica global en cada paso consume tiempo de inferencia y memoria de GPU. La contribución de SnapGuard es reformular la detección como un análisis de representación multimodal más económico sobre la captura, construido sobre dos señales complementarias.
La primera es un indicador de estabilidad visual. El contenido inyectado suele insertarse como regiones visualmente uniformes — banners planos, superposiciones, bloques de texto rellenados — que producen distribuciones de gradiente anormalmente suaves frente a la textura orgánica de una página real. SnapGuard marca esas regiones estadísticamente anómalas sin tener que entender lo que dicen.
La segunda es una señal textual orientada a la acción, recuperada mediante inversión de la polaridad de contraste. Las cargas de inyección se ocultan con frecuencia en texto de bajo contraste o casi invisible, para que un humano no lo note pero un agente capaz lo lea igualmente. Invertir la polaridad de contraste hace aflorar ese texto tenue, que un extractor ligero puede luego analizar en busca de lenguaje imperativo que dispare acciones («enviar», «aprobar», «ir a…»).
Captura de pantalla (lo que ve el agente)
│
├─▶ comprobación de estabilidad visual ── ¿región plana/uniforme? ──┐
│ ├─▶ alerta
└─▶ inversión de polaridad ── ¿texto imperativo oculto? ────────────┘
Sin pasada VLM sobre toda la página. ~1,81 s por página (medido).
En la evaluación del artículo, SnapGuard alcanza un F1 de 0,75 frente a 0,71 de una baseline de prompting con GPT-4o, ejecutándose unas 8× más rápido (~1,81 s por página). La cuestión no es que 0,75 resuelva el problema — es que se obtiene una detección competitiva en el canal visual sin pagar un juicio VLM completo en cada acción.
Por qué importa
Los agentes basados en capturas son precisamente los que más conviene proteger, porque suelen tener un alcance amplio, a nivel de sistema: un navegador que pilotan, archivos que tocan, formularios que envían. También son los agentes que las defensas existentes cubren peor. Una defensa que inspecciona el HTML es estructuralmente ciega a una carga que solo existe en los píxeles renderizados — el mismo punto ciego que hace eficaces la inyección solo por imagen y los benchmarks de inyección visual. SnapGuard importa porque coloca un detector en el canal en el que el agente confía, a un coste lo bastante bajo para correr en línea en cada paso.
Conviene ser preciso con el alcance. SnapGuard defiende el canal visual; según el propio planteamiento de los autores, no atrapa inyecciones solo de HTML que nunca se muestran visualmente. Es por tanto un complemento, no un reemplazo, de las defensas del lado del texto y de benchmarks como WAInjectBench. La lectura honesta: los agentes de capturas necesitan ambos detectores, del lado de los píxeles y del lado del marcado, porque a un atacante le basta con el canal que tu pila olvidó.
Defensas
SnapGuard es en sí una defensa, así que lo esencial es desplegarlo bien — y saber qué disponer a su alrededor.
-
Detectar en el canal que el agente consume de verdad. Si tu agente actúa sobre capturas, una defensa de texto/DOM no basta. Ejecuta un detector del lado de los píxeles (estilo SnapGuard: estabilidad de gradientes + inversión de polaridad) sobre la misma imagen que el agente razona, en cada paso, no solo al cargar la página.
-
Mantener también la defensa del lado del marcado. Como el detector visual se pierde las cargas solo de HTML, combínalo con un escáner de texto/DOM. Trátalos como cubriendo puntos ciegos distintos, y alerta si cualquiera de los dos se dispara.
-
No hacer de la detección la única línea. Los detectores corren con un F1 no trivial, no 1,0 — algunas inyecciones pasarán. Combínalos con controles arquitectónicos para que una detección fallida no sea una brecha: bloquea las acciones de alto impacto (compras, envíos, borrados, uso de credenciales) tras comprobaciones de política explícitas o confirmación humana, y acota estrictamente las credenciales del agente. Es la lógica de la tríada letal y de la regla de dos de los agentes: si el contenido de página no confiable, la capacidad sensible y la vía de exfiltración no pueden coincidir, una carga que se cuela no escala.
-
Presupuestar el coste en línea. Si los equipos evitan el juicio VLM en cada paso es por latencia y coste de GPU. Un detector ligero como SnapGuard hace asequible el filtrado por paso, lo que permite ejecutarlo de verdad en producción y no como auditoría fuera de línea.
-
Volver a probar en tu propio agente y tus páginas. El F1 de un detector depende del conjunto de datos. La heurística de estabilidad visual puede dar falsos positivos en interfaces legítimamente planas (modales, espacios publicitarios), y la inversión de contraste puede perderse texto renderizado como imagen aplanada. Mide la tasa de falsos positivos contra tu tráfico real antes de confiarle el bloqueo de acciones, y ajústalo hacia el señalamiento/la redacción en lugar del bloqueo duro de toda la página.
Estado
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| Artículo SnapGuard | arXiv:2604.25562 | 2026-04-28 | Detector ligero para agentes web de capturas de pantalla |
| Resultado reportado | F1 0,75 vs 0,71 (baseline GPT-4o-prompt) | — | ~8× más rápido, ~1,81 s por página |
| Señales usadas | Indicador de estabilidad visual + texto con polaridad invertida | — | Sin pasada VLM sobre toda la página |
| Limitación declarada | Solo canal visual | — | Se pierde inyecciones solo de HTML; combinar con una defensa de texto/DOM |
| Relacionados | WARD, VPI-Bench (arXiv:2506.02456), WAInjectBench (arXiv:2510.01354) | — | Defensas/benchmarks de inyección para agentes web |
El encuadre útil no es «otra defensa más». Es que las defensas tienen que vivir en el mismo canal del que lee el agente — y para una clase creciente de agentes, ese canal es una captura de pantalla, no una cadena de texto.