StakeBench: ¿quién paga realmente cuando inyectan a un agente web?

What is this?

StakeBench es un benchmark de inyección de prompts para agentes web en condiciones reales, presentado en un artículo enviado a arXiv el 11 de junio de 2026 (arXiv:2606.13385) por investigadores de Nanyang Technological University, ST Engineering, IBM Research y la University of Illinois Urbana-Champaign. Su argumento central: los benchmarks existentes están centrados en el ataque — miden si una inyección tiene éxito técnico — mientras que en despliegues reales la pregunta relevante depende de la víctima: quién sufre el daño cuando un agente es manipulado. Un mismo exploit puede perjudicar al usuario, a un vendedor tercero o a la plataforma, con gravedad y visibilidad muy distintas.

How it works

StakeBench ancla su evaluación en el comercio electrónico, instanciado sobre OneStopMarket de VisualWebArena — un entorno funcional donde contenido no confiable (reseñas, valoraciones, metadatos de producto) fluye directamente al contexto del agente. El benchmark organiza 12 objetivos de ataque según la parte que sufre el daño (Usuario, Vendedor, Plataforma), realizados mediante 22 plantillas reutilizables (9 de inyección directa, 13 indirecta) e instanciados en 12 categorías de producto, produciendo 264 casos adversarios ejecutables.

Cada ejecución se puntúa en tres ejes: tasa de éxito del ataque (ASR), tasa de desviación de la tarea (TDR — ¿se vio afectada la tarea delegada por el usuario?) y tasa de irregularidad conductual (BIR — ¿se desestabilizó la ejecución?). ASR y TDR definen conjuntamente cuatro regímenes de fallo:

Régimen	ASR	TDR	Significado
Robust Behavior	bajo	bajo	el ataque falla, la tarea se completa
Stealthy Parasitism	alto	bajo	el ataque triunfa, el usuario no ve nada
Misaligned Disruption	bajo	alto	el ataque falla pero arruina la tarea
Compounded Failure	alto	alto	se violan el objetivo adversario y la integridad de la tarea

Los autores evaluaron dos sistemas de agentes de tipo producción — NanoBrowser (extensión de navegador multiagente, con módulos separados de planificación y navegación) y BrowserUse (bucle de control iterativo de agente único) — cada uno con GPT-5 y Gemini-2.5-Flash como modelos base.

Why it matters

Las cifras son malas en todos los frentes: la inyección indirecta alcanzó un ASR de entre 41,67 % y 68,16 % en cada configuración probada, y ni un solo objetivo de ataque fue resistido de forma fiable. Pero lo que hace útil este artículo es la lente de partes afectadas. Algunos ataques triunfan sin perturbar en absoluto la tarea del usuario — dañando a vendedores terceros tras la apariencia de un comportamiento perfectamente normal (parasitismo sigiloso). La evaluación convencional, centrada en el usuario, literalmente no puede ver este modo de fallo: la tarea se completó, el usuario quedó satisfecho, y otro pagó el precio.

Dos hallazgos más merecen atención. Primero, la elección del modelo domina sobre la arquitectura: cambiar de GPT-5 a Gemini-2.5-Flash elevó el ASR de inyección indirecta 26,49 puntos en NanoBrowser y 6,2 puntos en BrowserUse, con BrowserUse-Gemini registrando el peor TDR (45,09 %) y BIR (28,85 %) de todas las configuraciones. Segundo, un experimento preliminar de manipulación visual de imágenes de producto sugiere que la superficie de inyección va más allá del texto — las señales de valoración por sí solas no neutralizaron la influencia visual.

Defenses

El artículo caracteriza la vulnerabilidad y deja la evaluación de defensas para trabajo futuro, pero sus hallazgos se traducen directamente a la práctica. Modele su superficie de amenaza por parte afectada: no pregunte solo «¿pueden inyectar a mi agente?» sino «¿quién resulta dañado si ocurre?» — el éxito de la tarea de cara al usuario no es evidencia de seguridad. Trate reseñas, valoraciones y metadatos de producto como canales no confiables que entran al contexto del agente, con separación de procedencia o saneamiento antes del modelo. Vuelva a evaluar cualquier cambio de modelo base antes de desplegarlo: StakeBench muestra que un cambio de backbone puede mover el ASR más de 26 puntos con arquitectura idéntica. Monitorice señales a nivel de proceso (irregularidad en llamadas a herramientas, inestabilidad de navegación — el análogo del BIR) y no solo resultados, porque el parasitismo sigiloso deja los resultados intactos. Y para operadores de marketplaces: las compras mediadas por agentes desplazan los incentivos de fraude hacia la manipulación de contenido dirigida a agentes, lo que merece su propio pipeline de detección de abuso.

Status

Elemento	Detalle
Artículo	arXiv:2606.13385, enviado el 11 de junio de 2026
Benchmark	264 casos, 22 plantillas, 12 objetivos — público en GitHub (StakeBench/SBC)
Sistemas evaluados	NanoBrowser y BrowserUse, con GPT-5 y Gemini-2.5-Flash
Peor ASR (inyección indirecta)	68,16 % (rango 41,67–68,16 % según configuración)
Estado de parche	No es un fallo de un solo proveedor — es la medición de una debilidad sistémica de los agentes web