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

Los agentes que pueden navegar por la web, como el asistente integrado en Comet o Computer, necesitan interactuar con páginas web: leen su contenido y lo usan 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 solicitó.

En diciembre de 2025 lanzamos BrowseSafe, un benchmark y modelo de detección para esta amenaza. Lo creamos agregando ataques sintéticos a páginas web realistas que los agentes probablemente encontrarían. Durante el último año, los ataques han evolucionado para ser más sofisticados y parecerse más al contenido común 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 identifican estos ataques y si los agentes pueden 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 conservamos el ataque textualmente. Cada página viene en los cuatro formatos que leen los agentes de navegador: HTML, Markdown, árboles de accesibilidad y capturas de pantalla. Usamos un subconjunto del benchmark para entrenar BrowseSafe-Guard, un par de detectores de 0.8B de parámetros: un detector de texto y un detector multimodal. Los dos detectores de Guard identifican inyecciones con mayor exactitud que los modelos guiados por prompts que probamos, incluidos modelos de frontera. Además, son más rápidos y económicos, y marcan por error muchas menos páginas comunes.

Publicamos BrowseSafe++ como un benchmark abierto. El sitio web del proyecto incluye enlaces al conjunto de datos, al SDK, al artículo de investigación y a una tabla de 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 posible inclusión en la tabla de clasificación. Para evaluar y enviar tus resultados, consulta Primeros pasos.

Construcción de un benchmark a partir de inyecciones observadas

BrowseSafe++ se construyó a partir de 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 6,488 pares del benchmark original de BrowseSafe, para un total de 38,675 pares. Cada par incluye una página atacada y su gemela limpia, que es la misma página sin la inyección.

Así lucen las inyecciones en el mundo real

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

En uno, 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 en medio incluye publicidad común de tokens. Afirma provenir 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 busca alterar 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 usan para separar los turnos de una conversación. Un agente que cayera en este ataque respondería a la consulta falsificada del usuario y contestaría 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 suene como 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 verificaciones de seguridad y avisos de políticas, o por el usuario, presentando preferencias falsas. Alrededor de dos de cada tres están redactadas en 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. Por lo general, 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 están claramente dirigidos a un agente que lee todos los idiomas y que, por lo general, tiene 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 estuvieron 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 de tokens 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.
• Suelen aprovechar 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 comunes, y más de 23,000 inyecciones de BrowseSafe++ llegaron de esta forma. Incluso un dominio de confianza puede usarse 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 usar las páginas marcadas tal como están en el benchmark, porque pueden contener información personal del usuario para el que trabajaba el agente. Convertir una página en un par de benchmark que se pueda compartir requiere tres etapas principales:

1. Obtener la inyección: Recopilamos las páginas marcadas, eliminamos duplicados y enmascaramos la información personal con PII-Tracer. Luego, 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 que el usuario pretendía.
2. Construir el par: Un agente elimina el texto de la inyección de cada página y reescribe el contenido circundante, reemplazando detalles como nombres y marcas por otros ficticios. Un segundo agente revisa la página reescrita en busca de contenido real residual y devuelve los fallos con retroalimentación. 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. Ambas páginas comparten la misma tarea, el mismo resultado esperado y las mismas instrucciones comunes.
3. Verificar: Los agentes leen las páginas en distintas 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 aparezca en las cuatro vistas de la página atacada y que la página limpia se considere 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 renderizar, para garantizar que la inyección aparezca en la página atacada final en todas las vistas. Un conjunto final de verificaciones automatizadas corrige cualquier par que aún conserve 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 revisar cada página de forma rápida y económica. También debe ser exacto tanto en páginas atacadas como en páginas limpias. La alta precisión 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 propósito general guiados por prompts suelen quedarse cortos en precisión y son demasiado lentos y costosos para ejecutarse en cada página.

Un detector entrenado con páginas atacadas y páginas 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 usan dos objetivos de entrenamiento para actualizar el modelo: el objetivo estándar de clasificación y un objetivo de ranking que penaliza a Guard a menos que la página atacada obtenga una puntuación mayor que la de su gemela por al menos un margen fijo. Intuitivamente, el objetivo de clasificación le enseña a Guard qué decisión tomar, y el objetivo de ranking vincula esa decisión con la propia inyección e ignora los distractores benignos. Así, Guard aprende a responder a la inyección en sí, en lugar de al contenido que la rodea en la página.

Guard consta de dos detectores, cada uno ajustado 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 adelante y genera una puntuación de inyección; 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 ejecutarse en cada página.

Evaluación del rendimiento

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

• La exhaustividad (recall) es la proporción de páginas con inyección que el detector marca; mide cuántos ataques detecta, así que un valor más alto es 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, así que un valor más bajo es 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, así que un valor más alto es mejor.
• F1 es la media armónica de la exhaustividad y la precisión; solo es alta cuando un detector identifica la mayoría de los ataques y pocas de sus marcas son falsas alarmas.

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

Ampliar

Ampliar

Comparaciones de modelos

Los modelos pequeños de pesos abiertos que probamos quedaron en los últimos lugares. Mistral NeMo y Qwen3 30B-A3B marcan cada uno aproximadamente la mitad de las páginas limpias, mientras que Llama 3.1 8B casi nunca marca nada y pasa por alto la mayoría de los ataques. Incluso el modelo más sólido del grupo, GPT-OSS 20B, solo alcanza un F1 de 70.97%. DeepSeek V3.1, un modelo de pesos abiertos mucho más grande, obtiene resultados ligeramente mejores, con un F1 de 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 un recall de entre 85% y 97%. Sin embargo, el costo es una alta proporción de falsas alarmas: Gemini 3.1 Flash-Lite tiene la FPR más baja del grupo, con 35.2%, y la FPR de Haiku es de casi 69%. Como resultado, la puntuación F1 máxima del grupo es de 80.9%, obtenida por Gemini 3.1 Flash-Lite.

Los modelos restantes son modelos de propósito general más sólidos, con puntuaciones F1 de entre 85% y 92%. Sin embargo, aún enfrentan disyuntivas entre exhaustividad y 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 98.73%, pero una FPR de 24.65%. Gemini 3.1 Pro y GPT-5.5 alcanzan exhaustividades de 97.78% y 97.19%, con FPR de 19.80% y 20.44%, respectivamente. GPT-6 Astra tiene la mayor exactitud general, con una exhaustividad de 96.42% y una FPR de 14.41%. Decider ocupa el segundo lugar, con una exhaustividad de 96.02% y una FPR de 17.44%. Claude Opus 5.5 tiene la FPR más baja, de apenas 4.21%, pero su exhaustividad de 77.71% significa que pasa por alto más de uno de cada cinco ataques. Claude Fable 5.1 se ve sólido en las páginas que responde, con una exhaustividad de 89.31% y una FPR de 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 un F1 de aproximadamente 95% y ocupa el primer lugar en todas las vistas de texto. Solo marca aproximadamente una de cada 20 páginas limpias, cerca de un tercio de la tasa de Astra, el modelo guiado por prompts más exacto. Esta diferencia proviene de nuestro entrenamiento: el Qwen3.5-0.8B original en el que se basa Guard, usado con prompts de la misma manera que los demás modelos, solo alcanza un F1 de 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 aproximadamente 93% de F1, frente a aproximadamente 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 las tareas del usuario. Sin embargo, nuestros experimentos muestran que obtener buenas puntuaciones de detección no garantiza que un modelo resista un ataque. Le dimos a cada modelo la misma página atacada dos veces: una para juzgar si contenía una inyección y otra para realizar la tarea del usuario sin ver el veredicto anterior. Un juez independiente verificó si siguió la inyección. Todos los modelos probados siguieron aun así algunas 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 confiable las diferencias entre modelos. Claude Sonnet 5 y GPT-5.5 detectan inyecciones casi igual de bien, con puntuaciones F1 de aproximadamente 88% y 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 que GPT-5.5, con 1.97%.

Un sistema desplegable para la defensa contra inyecciones

Estos resultados sugieren que es útil delegar la decisión de bloquear una página a un modelo especializado, en lugar de depender del modelo que realiza la tarea del usuario. Un detector independiente que analiza cada página antes de que el agente actúe aporta una capa adicional de defensa y no tiene ninguna tarea que secuestrar ni herramientas que usar indebidamente.

Guard está diseñado para ser ese detector. Además de tener el F1 y la exactitud más altos de todos los modelos que probamos, su tamaño reducido lo hace lo bastante económico como para ejecutarse en cada página. En promedio, Guard usó unos 0.15 segundos de tiempo de GPU por página de texto. En una H200 rentada, estimamos un costo de $0.18 por cada 1,000 páginas, frente a $18.95–180.61 de los modelos de API de frontera a precios de lista. En nuestra comparación, esto abarata mucho el análisis frecuente y, al mismo tiempo, mantiene puntuaciones de detección altas.

La siguiente figura compara la exactitud de cada detector con su tiempo por página y su costo por cada 1,000 páginas, ambos en escala logarítmica. Guard aparece solo en la esquina superior izquierda de ambos paneles: gana en exactitud, velocidad y costo. Todos los modelos guiados por prompts tardan aproximadamente 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 US$100 por cada 1,000 páginas.

Ampliar

Pruebas de las defensas contra ataques adaptativos

El benchmark BrowseSafe++ tiene un conjunto finito de inyecciones. Sin embargo, un atacante real puede montar un ataque adaptativo: cuando una inyección falla, puede reescribirla y volver a intentarlo. Como resultado, 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 sus inyecciones; como vamos a publicar nuestro benchmark, 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 inyecciones. Cada prueba tiene tres etapas:

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 realice la tarea. El verificador revisa la respuesta del agente y cualquier cambio que haya hecho en el entorno aislado para determinar si el ataque tuvo é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é salió mal. Un modelo atacante usa esa retroalimentación 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 se mantienen iguales. 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 distinto: 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 enfrentó las mismas 1,024 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 sólidos fueron vulnerables: los ataques aún tuvieron é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 específica. En las tareas con este tipo de objetivo, Sonnet 5 cedió en aproximadamente el 8% de las tareas y GPT-5.5 en aproximadamente el 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 con Gemini 3.5 Flash-Lite, con Guard analizando primero cada página. Guard bloqueó el 94.5% de las inyecciones originales y casi duplicó el número promedio de intentos que necesitaron los atacantes, de 9.7 a 17.0. Sin embargo, con los 64 intentos disponibles, el atacante aun así tuvo éxito en el 84.2% de las tareas (93.6% sin Guard), casi siempre con una inyección que Guard no marcó. Esto coincide con la postura 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 en 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 comunes buscan interferir con la capacidad de los agentes para realizar 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 eleva lo que está en juego en los ataques, como porque los atacantes pueden revisar sus inyecciones para hacerlas más efectivas.

Nuestra suite BrowseSafe aborda 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 confiables de los detectores. Los detectores BrowseSafe-Guard, entrenados con estos pares, permiten una detección muy exacta, rápida y económica, lo que hace posible analizar las páginas antes de que un agente actúe sobre ellas. El marco BrowseSafe-Adapt permite probar 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 encontrar fallas y mejorar las defensas contra ataques de inyección de prompts basados en la web. También 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 sola vez en su página de Hugging Face y luego inicia sesión con hf auth login.

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

Esto escribe una decisión por página para cada vista que indiques; indica las tres vistas de texto para obtener un promedio 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 el F1, la exactitud, la tasa de falsos positivos y las demás métricas de cada vista y, si así lo eliges, publica el resultado en la tabla de clasificación. Cada cuenta (con al menos 60 días de antigüedad) obtiene un envío evaluado por semana UTC. Las páginas de prueba son solo para evaluación: no entrenes con ellas ni las redistribuyas. La guía de envío explica el formato del archivo y las reglas 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}
}