BrowseSafe++: cómo crear defensas más sólidas contra la inyección de prompts en el mundo real

Los agentes capaces de navegar por la web, como el asistente integrado en Comet o Computer, necesitan interactuar con páginas web: leen su contenido y lo utilizan para realizar acciones en nombre de sus usuarios. Esto los hace vulnerables a la inyección indirecta de prompts, en la que un atacante coloca texto malicioso en una página web. Si el agente sigue esas instrucciones, puede devolver una respuesta engañosa o realizar una acción que el usuario no ha solicitado.

En diciembre de 2025 lanzamos BrowseSafe, un benchmark y un modelo de detección para esta amenaza. Lo creamos añadiendo ataques sintéticos a páginas web realistas que los agentes probablemente encontrarían. Durante el último año, los ataques han evolucionado hasta volverse más sofisticados y parecerse más al contenido habitual de una página. En lugar de usar frases reveladoras como «ignora las instrucciones anteriores», suelen imitar contenido en el que el agente probablemente confíe, como un aviso oficial del sitio o una nota sobre las preferencias del usuario.

Motivados por estos cambios, creamos un benchmark actualizado, BrowseSafe++, para medir si los detectores de inyecciones actuales detectan estos ataques y si los agentes son capaces de resistirlos. Contiene 38.675 pares de páginas atacadas y limpias, construidos principalmente en torno a inyecciones recopiladas en el mundo real. En cada página, reescribimos el contenido circundante para proteger la privacidad, pero mantenemos el ataque de forma literal. Cada página está disponible en los cuatro formatos que leen los agentes de navegador: HTML, Markdown, árboles de accesibilidad y capturas de pantalla. Utilizamos un subconjunto del benchmark para entrenar BrowseSafe-Guard, un par de detectores de 800 millones de parámetros: un detector de texto y un detector multimodal. Los dos detectores de Guard identifican las inyecciones con mayor exactitud que los modelos con prompts que probamos, incluidos los modelos de frontera. Además, son más rápidos y baratos, y marcan por error muchas menos páginas normales.

Publicamos BrowseSafe++ como benchmark abierto. El sitio web del proyecto incluye enlaces al conjunto de datos, al SDK, al artículo de investigación y a una clasificación pública. Cualquier equipo puede evaluar su detector con páginas de prueba cuyas etiquetas no se proporcionan y enviar las etiquetas para su calificación y su posible inclusión en la clasificación. Para evaluar y enviar tus resultados, consulta Primeros pasos.

Construcción de un benchmark a partir de inyecciones observadas

BrowseSafe++ se basa en inyecciones de prompts observadas en sitios web reales. Entre septiembre de 2025 y septiembre de 2026, el detector de inyecciones de prompts de Comet marcó 1,15 millones de inyecciones en páginas que leyó su agente. Construimos 32.187 pares en torno a esas inyecciones y añadimos 6488 pares del benchmark BrowseSafe original, hasta un total de 38.675 pares. Cada par contiene una página atacada y su gemela limpia, que es la misma página sin la inyección.

Cómo son las inyecciones en el mundo real

Dos ejemplos del benchmark muestran cómo son estas inyecciones en la práctica.

En uno de ellos, una solicitud de compra falsa incita al agente a realizar una acción no autorizada. El detector de Comet marcó este bloque de texto en inglés en una página de documentación para desarrolladores en ruso en octubre de 2025:

El texto empieza y termina con órdenes y rellena la parte central con marketing corriente de tokens. Afirma proceder del propio desarrollador del agente y termina con un código de autorización para que la compra parezca aprobada.

En otro, una conversación falsificada pretende desbaratar la tarea del agente. Este texto se encontró en la página de un repositorio de código en marzo de 2026:

El texto está diseñado para parecer una conversación entre un usuario y un agente: <|im_start|> y <|im_end|> son marcadores que algunos modelos de chat utilizan para separar los turnos de una conversación. Un agente que cayera en este ataque respondería a la consulta falsificada del usuario con la frase del atacante.

Observamos patrones similares en las inyecciones marcadas:

• Imitan fuentes de confianza. Ambos ejemplos hacen que el texto de la página parezca proceder de una fuente en la que el agente confía: su desarrollador en el primero y su propia conversación en el segundo. Las inyecciones también pueden hacerse pasar por el propio sitio, imitando comprobaciones de seguridad y avisos de políticas, o por el usuario, presentando preferencias falsas. Aproximadamente dos de cada tres están redactadas en un lenguaje formal.
• Muchas están escritas en otros idiomas. En el 24,4 % de los pares, la inyección usa un idioma distinto del resto de su página. Normalmente, se trata de una instrucción en inglés en una página que no está en inglés, como en el primer ejemplo. Estos ataques se dirigen claramente a un agente que lee todos los idiomas y que suele tener el inglés como lengua nativa. Los cambios de idioma también dificultan la detección: en nuestra evaluación original de BrowseSafe, los ataques multilingües estaban entre los más difíciles de detectar.
• La mayoría busca acciones, no palabras. Más de cuatro de cada diez empujan al agente hacia una acción que el usuario nunca pidió, como la compra del token del primer ejemplo, y aproximadamente un tercio intenta que abandone la tarea del usuario, como en el segundo ejemplo. Solo alrededor del 3 % intenta introducir información falsa en la respuesta.
• A menudo se cuelan en contenido que cualquiera puede publicar. Un atacante no necesita controlar un sitio. Basta con una publicación en un foro o un documento compartido en sitios corrientes, y más de 23.000 inyecciones de BrowseSafe++ llegaron así. Incluso un dominio de confianza puede utilizarse para inyectar el texto de un atacante.

Las inyecciones presentes en el benchmark final abarcan 12 tipos de sitios web, 24 tipos de ataque, 6 objetivos del atacante y 18 ubicaciones en la página.

Ampliar

De una página marcada a un par del benchmark

No podemos incluir las páginas marcadas tal cual en el benchmark, porque pueden contener información personal del usuario para el que trabajaba el agente. Convertir una página en un par del benchmark apto para compartirse requiere tres fases principales:

1. Obtener la inyección: Recopilamos las páginas marcadas, eliminamos los duplicados y enmascaramos la información personal con PII-Tracer. A continuación, confirmamos que la página contiene una inyección; en concreto, exigimos que un panel de modelos coincida en que contiene una instrucción que intenta desviar a un agente de la tarea prevista por el usuario.
2. Construir el par: Un agente elimina el texto de la inyección de cada página y reescribe el contenido circundante, sustituyendo detalles como nombres y marcas por otros ficticios. Un segundo agente comprueba si en la página reescrita queda contenido del mundo real y devuelve los fallos con comentarios. Revisores humanos inspeccionan un 10 % aleatorio de las páginas; los problemas que encuentran se corrigen en el proceso, y las correcciones se aplican a todo el corpus. La inyección se vuelve a insertar en la página reescrita para crear la copia atacada y se omite en la copia limpia. Las dos páginas comparten la misma tarea, el mismo resultado esperado y las mismas instrucciones normales.
3. Verificar: Los agentes leen las páginas en diferentes formas, así que convertimos el HTML de cada página a Markdown, a un árbol de accesibilidad (una lista estructurada de los elementos de la interfaz de una página y sus etiquetas) y a una captura de pantalla. Otro agente comprueba que la inyección aparece en las cuatro vistas de la página atacada y que la página limpia se considera benigna en todas las vistas. Si la inyección falta en alguna de las vistas, la movemos a otro lugar de la página y volvemos a renderizarla, para garantizar que la inyección esté presente en la página atacada final en todas las vistas. Un último conjunto de comprobaciones automatizadas corrige los pares que aún conservan rastros de su origen, como nombres de host o de marcas reales.

Ampliar

BrowseSafe-Guard: detectores rápidos y precisos para cada vista

Un detector útil debe comprobar cada página de forma rápida y económica. También debe ser preciso tanto en las páginas atacadas como en las limpias. Una precisión alta es especialmente importante, ya que la mayoría de las páginas son seguras; incluso una tasa de falsos positivos relativamente baja haría que la mayoría de las alertas fueran falsas alarmas. Los modelos de uso general con prompts suelen quedarse cortos en precisión y son demasiado lentos y costosos para ejecutarlos en cada página.

Un detector entrenado con páginas atacadas y limpias recopiladas por separado podría aprender atajos que casualmente separan ambos conjuntos, como el tema o el diseño de una página. Sin embargo, un detector así no generaliza bien. En cambio, Guard se entrena con pares cuya única diferencia es la propia inyección, lo que ayuda a mejorar la precisión del detector. Para cada par, Guard lee por separado la página atacada y su gemela limpia, y asigna a cada una una puntuación según la probabilidad de que contenga una inyección. Se utilizan dos objetivos de entrenamiento para actualizar el modelo: el objetivo de clasificación estándar y un objetivo de ranking que penaliza a Guard a menos que la página atacada obtenga una puntuación superior a la de su gemela por al menos un margen fijo. Intuitivamente, el objetivo de clasificación enseña a Guard qué decisión tomar, y el objetivo de ranking vincula esa decisión a la propia inyección e ignora los distractores benignos. Así, Guard aprende a responder a la inyección en sí, y no al contenido de la página que la rodea.

Guard consta de dos detectores, cada uno ajustado mediante fine-tuning a partir de Qwen3.5-0.8B. El detector de texto lee una vista de texto de una página: HTML, Markdown o árbol de accesibilidad. El detector multimodal lee una captura de pantalla de la página completa. En producción, Guard lee una página en una sola pasada hacia delante y genera una puntuación de inyección, y la página se marca si la puntuación supera un umbral. Como Guard tiene solo 800 millones de parámetros y genera una única puntuación, es lo bastante rápido y económico como para ejecutarlo en cada página.

Evaluación del rendimiento

Comparamos Guard con 18 modelos a los que se pidió mediante prompts que detectaran inyecciones en un subconjunto reservado del benchmark. Presentamos cuatro métricas, medidas en BrowseSafe++:

• La exhaustividad (recall) es la proporción de páginas con inyección que marca el detector; mide cuántos ataques detecta, por lo que cuanto más alta, mejor.
• La tasa de falsos positivos (FPR) es la proporción de páginas limpias que el detector marca por error; mide con qué frecuencia genera falsas alarmas, por lo que cuanto más baja, mejor.
• La precisión es la proporción de páginas marcadas que realmente contienen una inyección; mide con qué frecuencia una alerta es correcta, por lo que cuanto más alta, mejor.
• F1 es la media armónica de la exhaustividad y la precisión; solo es alta cuando un detector detecta la mayoría de los ataques y pocas de sus marcas son falsas alarmas.

Utilizamos F1 como métrica principal, ya que un buen detector debe tener una precisión y una exhaustividad altas. Las cuatro métricas se promedian entre las tres vistas de texto.

Ampliar

Ampliar

Comparativa de modelos

Los modelos pequeños de pesos abiertos que probamos quedaron en las últimas posiciones. Mistral NeMo y Qwen3 30B-A3B marcan cada uno aproximadamente la mitad de las páginas limpias, mientras que Llama 3.1 8B rara vez marca algo y pasa por alto la mayoría de los ataques. Incluso el modelo más potente del grupo, GPT-OSS 20B, solo alcanza una puntuación F1 del 70,97 %. DeepSeek V3.1, un modelo de pesos abiertos mucho más grande, obtiene resultados ligeramente mejores, con una puntuación F1 del 75,23 %.

Los modelos de API ligeros, como GPT-5.4 nano, Gemini 3.1 Flash-Lite y Claude Haiku 4.5, detectan más ataques, con una sensibilidad (recall) de entre el 85 % y el 97 %. Sin embargo, el precio es una elevada proporción de falsas alarmas: Gemini 3.1 Flash-Lite tiene la tasa de falsos positivos (FPR) más baja del grupo, con un 35,2 %, y la FPR de Haiku es de casi el 69 %. Como resultado, la puntuación F1 máxima del grupo es del 80,9 %, alcanzada por Gemini 3.1 Flash-Lite.

Los modelos restantes son modelos de uso general más potentes, con puntuaciones F1 de entre el 85 % y el 92 %. Sin embargo, siguen enfrentándose a compromisos entre la exhaustividad y la FPR: los modelos que tienden a la cautela bloquean páginas legítimas, y los que marcan con menos frecuencia pasan por alto ataques. Claude Sonnet 5 tiene la exhaustividad más alta de todos los detectores, con un 98,73 %, pero una FPR del 24,65 %. Gemini 3.1 Pro y GPT-5.5 alcanzan una exhaustividad del 97,78 % y el 97,19 %, con FPR del 19,80 % y el 20,44 %, respectivamente. GPT-6 Astra tiene la mayor exactitud global, con una exhaustividad del 96,42 % y una FPR del 14,41 %. Decider queda en segundo lugar, con una exhaustividad del 96,02 % y una FPR del 17,44 %. Claude Opus 5.5 tiene la FPR más baja, de solo el 4,21 %, pero su exhaustividad del 77,71 % implica que pasa por alto más de uno de cada cinco ataques. Claude Fable 5.1 parece sólido en las páginas a las que responde, con una exhaustividad del 89,31 % y una FPR del 7,92 %, pero se niega a responder en aproximadamente el 30 % de las páginas, que la fila «(all)» cuenta como marcas.

Ampliar

Guard hace avanzar la frontera de Pareto y logra un mejor equilibrio entre ataques no detectados y falsas alarmas. Alcanza una puntuación F1 de alrededor del 95 % y ocupa el primer puesto en todas las vistas de texto. Solo marca aproximadamente una de cada 20 páginas limpias, en torno a un tercio de la tasa de Astra, el modelo con prompts más exacto. Esta diferencia se debe a nuestro entrenamiento: el modelo Qwen3.5-0.8B original en el que se basa Guard, con los mismos prompts que los demás modelos, solo alcanza una puntuación F1 del 64 % y marca casi tres de cada cuatro páginas limpias. En el escenario de la vista de capturas de pantalla, comparamos el detector multimodal de Guard con cuatro modelos capaces de procesar imágenes. Con capturas de pantalla de página completa, Guard obtiene una puntuación F1 de alrededor del 93 %, frente a aproximadamente el 79 % del mejor de los demás modelos que evaluamos.

Reconocer un ataque no es lo mismo que resistirlo

Intuitivamente, un modelo capaz de identificar correctamente una inyección también debería ignorarla cuando se encuentra con la página mientras completa tareas de los usuarios. Sin embargo, nuestros experimentos muestran que unas buenas puntuaciones de detección no garantizan que un modelo resista un ataque. Dimos a cada modelo la misma página atacada dos veces: una para juzgar si contenía una inyección y otra para llevar a cabo la tarea del usuario sin ver el veredicto anterior. Un juez independiente comprobó si había seguido la inyección. Todos los modelos probados siguieron algunas de las inyecciones que habían marcado, desde el 1,64 % de las páginas marcadas en el caso de GPT-6 Astra hasta el 24,73 % en el de Llama 3.1 8B.

Ampliar

Las puntuaciones de detección no predicen de forma fiable las diferencias entre modelos. Claude Sonnet 5 y GPT-5.5 detectan inyecciones prácticamente igual de bien, con puntuaciones F1 de alrededor del 88 % y el 89 %, respectivamente. Sin embargo, Sonnet 5 siguió una inyección que había marcado en el 19,74 % de las páginas, diez veces más a menudo que GPT-5.5, con un 1,97 %.

Un sistema desplegable para la defensa contra inyecciones

Estos resultados sugieren que tiene valor delegar la decisión de bloquear una página en un modelo especializado, en lugar de depender del modelo que lleva a cabo la tarea del usuario. Un detector independiente que analiza cada página antes de que actúe el agente proporciona una capa adicional de defensa y no tiene ninguna tarea que secuestrar ni herramientas de las que hacer un uso indebido.

Guard está diseñado para ser ese detector. Además de obtener la mayor puntuación F1 y la mayor exactitud de todos los modelos que probamos, su reducido tamaño lo hace lo bastante económico como para ejecutarlo en cada página. De media, Guard utilizó unos 0,15 segundos de tiempo de GPU por página de texto. En una H200 alquilada, estimamos un coste de 0,18 $ por cada 1000 páginas, frente a entre 18,95 y 180,61 $ de los modelos de API de frontera a precios de catálogo. En nuestra comparación, esto hace que el análisis frecuente sea mucho más barato sin renunciar a altas puntuaciones de detección.

La siguiente figura representa la exactitud de cada detector frente a su tiempo por página y su coste por cada 1000 páginas, ambos en escala logarítmica. Guard se sitúa en solitario en la esquina superior izquierda de ambos paneles: gana en exactitud, velocidad y coste. Todos los modelos con prompts tardan alrededor de un segundo o más por página, y los dos más exactos, GPT-6 Astra y Claude Fable 5.1, cuestan más de 100 $ por cada 1000 páginas.

Ampliar

Pruebas de defensas frente a ataques adaptativos

El benchmark BrowseSafe++ tiene un conjunto finito de inyecciones. Sin embargo, un atacante real puede lanzar un ataque adaptativo: cuando una inyección falla, puede reescribirla y volver a intentarlo. Por tanto, un agente que resiste la inyección original podría seguir siendo vulnerable a ataques futuros. Además, los modelos se entrenan con datos recopilados de internet, por lo que podrían aprender a resistir la mayoría de las inyecciones del benchmark; como lo vamos a publicar abiertamente, es probable que se sature y deje de diferenciar bien a los modelos. Para abordar ambos problemas, creamos BrowseSafe-Adapt, un entorno de pruebas en el que un modelo atacante puede reescribir las inyecciones. Cada prueba consta de tres fases:

1. Configurar el caso. Un caso agrupa una entrada de BrowseSafe++ con un agente objetivo. La entrada de BrowseSafe++ incluye un escenario con una consulta y una tarea del usuario, una página atacada y el resultado que busca el atacante. El agente trabaja en un entorno aislado que proporciona las herramientas y los datos sintéticos necesarios para ejecutar la tarea. Un modelo verificador independiente evalúa si el ataque logró su objetivo.
2. Ejecutar un intento: Insertamos la inyección actual en la página y dejamos que el agente lleve a cabo la tarea. El verificador comprueba la respuesta del agente y cualquier cambio que haya realizado en el entorno aislado para determinar si el ataque ha tenido éxito. El primer intento usa la inyección de la entrada original de BrowseSafe++.
3. Revisar y repetir: Si un ataque falla, archivamos el intento y un modelo crítico analiza qué ha salido mal. Un modelo atacante usa esos comentarios para reescribir la inyección; puede cambiar la redacción, el formato o la posición del ataque en la página. El objetivo del ataque, los criterios de éxito y el contenido circundante de la página no cambian. El siguiente intento usa el ataque actualizado. Este proceso se repite hasta que el ataque tiene éxito o el atacante alcanza un límite de intentos establecido.

Ampliar

Probamos siete agentes, cada uno basado en un modelo diferente: Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite y los modelos de pesos abiertos DeepSeek V3.1 y Kimi K2. Cada agente se enfrentó a las mismas 1024 tareas, con hasta 64 intentos por tarea. En el primer intento, el éxito de los ataques fue bajo en los siete agentes. Las inyecciones originales tuvieron éxito, como máximo, en el 4 % de las tareas evaluadas contra cualquier agente. Con el marco adaptativo, el éxito de los ataques aumentó drásticamente. El atacante tuvo éxito en al menos el 79 % de las tareas contra cinco de los siete agentes. Incluso los agentes más robustos resultaron vulnerables: los ataques siguieron teniendo éxito en aproximadamente dos de cada tres tareas contra GPT-5.5 y en aproximadamente una de cada tres contra Claude Sonnet 5.

La diferencia entre agentes es mayor cuando el objetivo del atacante es que el agente realice una llamada a una herramienta concreta. En las tareas con este tipo de objetivo, Sonnet 5 cedió en aproximadamente el 8 % de las tareas y GPT-5.5, en torno al 29 %. Los otros cinco cumplieron el objetivo del atacante en más de la mitad de sus tareas.

También ejecutamos BrowseSafe-Adapt contra el agente basado en Gemini 3.5 Flash-Lite, con Guard analizando previamente cada página. Guard bloqueó el 94,5 % de las inyecciones originales y casi duplicó el número medio de intentos que necesitaban los atacantes, de 9,7 a 17,0. Sin embargo, con los 64 intentos, el atacante siguió teniendo éxito en el 84,2 % de las tareas (93,6 % sin Guard), casi siempre con una inyección que Guard no había marcado. Esto coincide con la visión que expusimos cuando lanzamos BrowseSafe: ningún modelo de detección es una solución mágica, por lo que un detector debe formar parte de una defensa por capas.

Ampliar

Conclusión

Los agentes de navegador suelen ser vulnerables a la inyección indirecta de prompts, en la que ataques ocultos en páginas normales intentan interferir en la capacidad de los agentes para llevar a cabo las tareas de los usuarios. Los peligros no hacen más que crecer con el tiempo, tanto porque los agentes obtienen acceso a más datos y herramientas, lo que aumenta lo que está en juego en los ataques, como porque los atacantes pueden revisar sus inyecciones para hacerlas más eficaces.

Nuestro conjunto de herramientas BrowseSafe hace frente a estas amenazas. El benchmark BrowseSafe++ contiene 38.675 pares de páginas web construidos principalmente a partir de inyecciones reales, lo que permite un entrenamiento y una evaluación más fiables de los detectores. Los detectores BrowseSafe-Guard, entrenados con estos pares, ofrecen una detección muy precisa, rápida y económica, lo que permite analizar las páginas antes de que un agente actúe sobre ellas. El marco BrowseSafe-Adapt permite probar los modelos frente a inyecciones revisadas, lo que pone de manifiesto vulnerabilidades que podrían no ser evidentes en intentos únicos con inyecciones fijas.

En conjunto, esperamos que estas herramientas faciliten a investigadores e ingenieros la detección de fallos y la mejora de las defensas frente a los ataques de inyección de prompts a través de la web. Además, evaluamos y mejoramos continuamente las defensas integradas de Comet y Computer para mantener seguros a nuestros usuarios.

Primeros pasos

1. Instala el SDK y obtén acceso a los datos. El SDK se instala desde GitHub:

El conjunto de datos tiene acceso restringido. Solicita acceso una vez en su página de Hugging Face y, después, inicia sesión con hf auth login.

2. Envía tus resultados a la clasificación. Evalúa tu propio detector con la partición de prueba de BrowseSafe++:

Esto genera una decisión por página para cada vista que indiques; indica las tres vistas de texto para obtener una media en la tabla de clasificación de texto. Inicia sesión en el Space de la tabla de clasificación con tu cuenta de Hugging Face y sube predictions.jsonl. El Space devuelve la puntuación F1, la exactitud, la tasa de falsos positivos y las demás métricas de cada vista y, si lo deseas, publica el resultado en la tabla de clasificación. Cada cuenta (con una antigüedad mínima de 60 días) dispone de un envío puntuado por semana UTC. Las páginas de prueba son solo para evaluación: no las uses para entrenar ni las redistribuyas. La guía de envío explica el formato del archivo y las normas de publicación.

Cita

@online{perplexity2026BrowseSafePlusPlus,
  author = {{Perplexity} and Yuetian Chen and Kaiyuan Zhang and Yuntao Du and Thomas Li and Mark Tenenholtz and Kyle Polley and Jerry Ma and Denis Yarats and Ninghui Li and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{BrowseSafe++: Building stronger defenses against real-world prompt injection}},
  date = {2026-10-28},
  url = {https://www.perplexity.ai/hub/blog/browsesafe-plus-plus}
}