BrowseSafe++: construír defensas máis sólidas contra a inxección de prompts no mundo real

Os axentes que poden navegar pola web, como o asistente integrado en Comet ou Computer, necesitan interactuar coas páxinas web: len o seu contido e úsano para realizar accións en nome dos seus usuarios. Isto fainos vulnerables á inxección indirecta de prompts, na que un atacante coloca texto malicioso nunha páxina web. Se o axente segue esas instrucións, pode devolver unha resposta enganosa ou realizar unha acción que o usuario non solicitou.

En decembro de 2025 lanzamos BrowseSafe, un banco de probas e modelo de detección para esta ameaza. Construímolo engadindo ataques sintéticos a páxinas web realistas que os axentes probablemente atoparían. Ao longo do último ano, os ataques evolucionaron para seren máis sofisticados e pareceren máis ao contido habitual das páxinas. En lugar de usar frases reveladoras como “ignora as instrucións anteriores”, adoitan imitar contido no que é probable que o axente confíe, como un aviso oficial do sitio ou unha nota sobre as preferencias do usuario.

Motivados por estes cambios, creamos un benchmark actualizado, BrowseSafe++, para medir se os detectores de inxeccións actuais detectan estes ataques e se os axentes poden resistilos. Contén 38.675 pares de páxinas atacadas e limpas, construídos principalmente arredor de inxeccións recompiladas no mundo real. Para cada páxina, reescribimos o contido circundante para protexer a privacidade, pero mantemos o ataque literalmente. Cada páxina ofrécese nos catro formatos que len os axentes de navegador: HTML, Markdown, árbores de accesibilidade e capturas de pantalla. Usamos un subconxunto do benchmark para adestrar BrowseSafe-Guard, un par de detectores de 0,8B de parámetros: un detector de texto e un detector multimodal. Os dous detectores Guard identifican as inxeccións con máis exactitude que os modelos guiados por prompts que probamos, incluídos os modelos de fronteira. Ademais, son máis rápidos e baratos, e marcan por erro moitas menos páxinas normais.

Publicamos BrowseSafe++ como benchmark aberto. O sitio web do proxecto inclúe ligazóns ao conxunto de datos, ao SDK, ao artigo de investigación e a unha clasificación pública. Calquera equipo pode avaliar o seu detector con páxinas de proba cuxas etiquetas non se proporcionan e enviar as etiquetas para a súa cualificación e posible inclusión na clasificación. Para avaliar e enviar os teus resultados, consulta Primeiros pasos.

Construír un benchmark a partir de inxeccións observadas

BrowseSafe++ constrúese a partir de inxeccións de prompts observadas en sitios web reais. Entre setembro de 2025 e setembro de 2026, o detector de inxeccións de prompts de Comet marcou 1,15 millóns de inxeccións en páxinas que leu o seu axente. Construímos 32.187 pares arredor desas inxeccións e engadimos 6488 pares do benchmark orixinal de BrowseSafe, ata un total de 38.675 pares. Cada par contén unha páxina atacada e o seu xemelgo limpo, que é a mesma páxina sen a inxección.

Como son as inxeccións no mundo real

Dous exemplos do benchmark mostran como son estas inxeccións na práctica.

Nun deles, unha solicitude de compra falsa incita o axente a realizar unha acción non autorizada. O detector de Comet marcou este bloque de texto en inglés nunha páxina de documentación para desenvolvedores en ruso en outubro de 2025:

O texto comeza e remata con ordes e enche a parte central con publicidade habitual de tokens. Afirma proceder do propio desenvolvedor do axente e conclúe cun código de autorización para que a compra pareza aprobada.

Noutro, unha conversa falsificada pretende interromper a tarefa do axente. Este texto atopouse nunha páxina dun repositorio de código en marzo de 2026:

O texto está deseñado para parecer unha conversa entre un usuario e un axente: <|im_start|> e <|im_end|> son marcadores que algúns modelos de chat usan para separar as quendas dunha conversa. Un axente que caese neste ataque respondería á consulta falsificada do usuario coa frase do atacante.

Observamos patróns similares nas inxeccións marcadas:

• Imitan fontes de confianza. Ambos os exemplos fan que o texto da páxina soe como unha fonte na que o axente confía: o seu desenvolvedor no primeiro e a súa propia conversa no segundo. As inxeccións tamén poden facerse pasar polo propio sitio, imitando comprobacións de seguranza e avisos de políticas, ou polo usuario, presentando preferencias falsas. Arredor de dúas de cada tres están escritas en linguaxe formal.
• Moitas están escritas en linguas diferentes. No 24,4 % dos pares, a inxección usa unha lingua diferente da do resto da páxina. Normalmente, trátase dunha instrución en inglés nunha páxina que non está en inglés, como no primeiro exemplo. Este tipo de ataques diríxense claramente a un axente que le todas as linguas e que adoita ter o inglés como lingua nativa. Os cambios de lingua tamén dificultan a detección: na nosa avaliación orixinal de BrowseSafe, os ataques multilingües estaban entre os máis difíciles de detectar.
• A maioría buscan accións, non palabras. Máis de catro de cada dez empurran o axente cara a unha acción que o usuario nunca pediu, como a compra do token do primeiro exemplo, e arredor dun terzo tentan que abandone a tarefa do usuario, como no segundo exemplo. Só arredor dun 3 % tentan introducir información falsa na resposta.
• Adoitan aproveitar contido que calquera pode publicar. Un atacante non precisa controlar un sitio. Abonda cunha publicación nun foro ou un documento compartido en sitios comúns, e máis de 23 000 inxeccións de BrowseSafe++ chegaron por esta vía. Aínda así, un dominio de confianza pode utilizarse para inxectar o texto dun atacante.

As inxeccións presentes no benchmark final abranguen 12 tipos de sitios web, 24 tipos de ataque, 6 obxectivos do atacante e 18 localizacións na páxina.

Ampliar

Dunha páxina marcada a un par do banco de probas

Non podemos usar as páxinas marcadas tal como están no benchmark, porque poden conter información persoal do usuario para o que traballaba o axente. Converter unha páxina nun par de benchmark que se poida compartir require tres fases principais:

1. Obter a inxección: recompilamos as páxinas marcadas, eliminamos os duplicados e enmascaramos a información persoal con PII-Tracer. Despois, confirmamos que a páxina contén unha inxección; en concreto, esiximos que un panel de modelos coincida en que contén unha instrución que tenta desviar un axente da tarefa prevista polo usuario.
2. Construír o par: un axente elimina o texto da inxección de cada páxina e reescribe o contido circundante, substituíndo detalles como nomes e marcas por outros ficticios. Un segundo axente comproba se na páxina reescrita queda contido do mundo real e devolve os fallos con comentarios. Revisores humanos inspeccionan un 10 % aleatorio das páxinas; os problemas que atopan corríxense no proceso, e as correccións aplícanse a todo o corpus. A inxección vólvese inserir na páxina reescrita para crear a copia atacada e omítese na copia limpa. As dúas páxinas comparten a mesma tarefa, o mesmo resultado esperado e as mesmas instrucións normais.
3. Verificar: os axentes len as páxinas en diferentes formas, así que renderizamos o HTML de cada páxina como Markdown, como árbore de accesibilidade (unha lista estruturada dos elementos da interface dunha páxina e as súas etiquetas) e como captura de pantalla. Outro axente comproba que a inxección aparece nas catro vistas da páxina atacada e que a páxina limpa se considera benigna en todas as vistas. Se a inxección falta nalgunha das vistas, movémola a outro lugar da páxina e volvemos renderizala, para garantir que a inxección aparece na páxina atacada final en todas as vistas. Un conxunto final de comprobacións automatizadas corrixe os pares que aínda conservan rastros da súa orixe, como nomes de host ou de marcas reais.

Ampliar

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

Un detector útil ten que comprobar cada páxina de forma rápida e barata. Tamén ten que ser exacto tanto en páxinas atacadas como en páxinas limpas. A alta precisión é especialmente importante, xa que a maioría das páxinas son seguras; mesmo unha taxa de falsos positivos relativamente baixa faría que a maioría das alertas fosen falsas alarmas. Os modelos de propósito xeral guiados por prompts adoitan quedar curtos en precisión e son demasiado lentos e custosos para executalos en cada páxina.

Un detector adestrado con páxinas atacadas e limpas recollidas por separado podería aprender atallos que casualmente separan os dous conxuntos, como o tema ou a disposición dunha páxina. Porén, un detector así non xeneraliza ben. En cambio, Guard adéstrase con pares cuxa única diferenza é a propia inxección, o que axuda a mellorar a precisión do detector. Para cada par, Guard le por separado a páxina atacada e a súa xemelga limpa e asígnalle a cada unha unha puntuación segundo a probabilidade de que conteña unha inxección. Para actualizar o modelo empréganse dous obxectivos de adestramento: o obxectivo de clasificación estándar e un obxectivo de ordenación que penaliza Guard salvo que a páxina atacada obteña unha puntuación superior á da súa xemelga polo menos nunha marxe fixa. Intuitivamente, o obxectivo de clasificación ensínalle a Guard que decisión tomar, e o obxectivo de ordenación vincula esa decisión á propia inxección e ignora os distractores benignos. Isto adestra Guard para responder á propia inxección, e non ao contido circundante da páxina.

Guard consta de dous detectores, cada un deles axustado a partir de Qwen3.5-0.8B. O detector de texto le unha vista de texto dunha páxina: HTML, Markdown ou árbore de accesibilidade. O detector multimodal le unha captura de pantalla da páxina completa. En produción, Guard le unha páxina nunha única pasada cara adiante e devolve unha puntuación de inxección, e a páxina márcase se a puntuación supera un limiar. Como Guard só ten 800 millóns de parámetros e devolve unha única puntuación, é o bastante rápido e barato para executalo en cada páxina.

Avaliación do rendemento

Comparamos Guard con 18 modelos aos que se lles pediu mediante prompts que detectasen inxeccións nun subconxunto reservado do benchmark. Informamos de catro métricas, medidas en BrowseSafe++:

• A exhaustividade (recall) é a proporción de páxinas con inxeccións que o detector marca; mide cantos ataques detecta, polo que canto máis alta, mellor.
• A taxa de falsos positivos (FPR) é a proporción de páxinas limpas que o detector marca por erro; mide con que frecuencia xera falsas alarmas, polo que canto máis baixa, mellor.
• A precisión é a proporción de páxinas marcadas que realmente conteñen unha inxección; mide con que frecuencia unha alerta é correcta, polo que canto máis alta, mellor.
• A F1 é a media harmónica da exhaustividade e a precisión; só é alta cando un detector detecta a maioría dos ataques e poucas das súas marcas son falsas alarmas.

Usamos F1 como métrica principal, xa que un bo detector debe ter unha precisión e unha exhaustividade altas. As catro métricas promédianse nas tres vistas de texto.

Ampliar

Ampliar

Comparacións de modelos

Os modelos pequenos de pesos abertos que probamos quedaron no fondo da clasificación. Mistral NeMo e Qwen3 30B-A3B marcan cada un arredor da metade das páxinas limpas, mentres que Llama 3.1 8B case nunca marca nada e deixa pasar a maioría dos ataques. Mesmo o modelo máis potente do grupo, GPT-OSS 20B, só alcanza unha F1 do 70,97 %. DeepSeek V3.1, un modelo de pesos abertos moito maior, sae lixeiramente mellor parado, cunha F1 do 75,23 %.

Os modelos de API lixeiros, como GPT-5.4 nano, Gemini 3.1 Flash-Lite e Claude Haiku 4.5, detectan máis ataques, cunha exhaustividade (recall) de entre o 85 % e o 97 %. Porén, o prezo é unha alta proporción de falsas alarmas: Gemini 3.1 Flash-Lite ten a taxa de falsos positivos (FPR) máis baixa do grupo, cun 35,2 %, e a FPR de Haiku é de case o 69 %. Como resultado, a puntuación F1 máxima do grupo é do 80,9 %, alcanzada por Gemini 3.1 Flash-Lite.

Os modelos restantes son modelos de propósito xeral máis potentes, con puntuacións F1 entre o 85 % e o 92 %. Porén, seguen enfrontándose a compromisos entre exhaustividade e FPR: os modelos que tenden á cautela bloquean páxinas lexítimas, e os que marcan con menos frecuencia deixan pasar ataques. Claude Sonnet 5 ten a maior exhaustividade de todos os detectores, cun 98,73 %, pero unha FPR do 24,65 %. Gemini 3.1 Pro e GPT-5.5 alcanzan exhaustividades do 97,78 % e do 97,19 %, con FPR do 19,80 % e do 20,44 %, respectivamente. GPT-6 Astra ten a maior exactitude global, cunha exhaustividade do 96,42 % e unha FPR do 14,41 %. Decider queda en segundo lugar, cunha exhaustividade do 96,02 % e unha FPR do 17,44 %. Claude Opus 5.5 ten a FPR máis baixa, de só o 4,21 %, pero a súa exhaustividade do 77,71 % implica que deixa pasar máis dun de cada cinco ataques. Claude Fable 5.1 parece sólido nas páxinas que responde, cunha exhaustividade do 89,31 % e unha FPR do 7,92 %, pero négase a responder en preto do 30 % das páxinas, que a fila «(all)» conta como marcas.

Ampliar

Guard fai avanzar a fronteira de Pareto e consegue un mellor equilibrio entre ataques non detectados e falsas alarmas. Alcanza unha F1 de arredor do 95 % e sitúase en primeiro lugar en todas as vistas de texto. Só marca arredor dunha de cada 20 páxinas limpas, aproximadamente un terzo da taxa de Astra, o modelo guiado por prompts máis exacto. Esta diferenza débese ao noso adestramento: o Qwen3.5-0.8B orixinal sobre o que se constrúe Guard, co mesmo prompt que os outros modelos, só alcanza unha F1 do 64 % e marca case tres de cada catro páxinas limpas. No escenario da vista de capturas de pantalla, comparamos o detector multimodal de Guard con catro modelos capaces de procesar imaxes. Con capturas de pantalla de páxina completa, Guard obtén arredor dun 93 % de F1, fronte a arredor dun 79 % do mellor dos outros modelos que avaliamos.

Recoñecer un ataque non é o mesmo que resistilo

Intuitivamente, un modelo que pode identificar correctamente unha inxección tamén debería ignorala cando atopa a páxina mentres completa as tarefas do usuario. Porén, os nosos experimentos mostran que unhas boas puntuacións de detección non garanten que un modelo resista un ataque. Démoslle a cada modelo a mesma páxina atacada dúas veces: unha para xulgar se contiña unha inxección e outra para levar a cabo a tarefa do usuario sen ver o veredicto anterior. Un xuíz independente comprobou se seguía a inxección. Todos os modelos probados seguiron algunhas inxeccións que eles mesmos marcaran, desde o 1,64 % das páxinas marcadas no caso de GPT-6 Astra ata o 24,73 % no de Llama 3.1 8B.

Ampliar

As puntuacións de detección non predín de forma fiable as diferenzas entre modelos. Claude Sonnet 5 e GPT-5.5 detectan inxeccións case igual de ben, con puntuacións F1 de arredor do 88 % e do 89 %, respectivamente. Porén, Sonnet 5 seguiu unha inxección que el mesmo marcara no 19,74 % das páxinas, dez veces máis que GPT-5.5, cun 1,97 %.

Un sistema despregable para a defensa contra inxeccións

Estes resultados suxiren que paga a pena delegar a decisión de bloquear unha páxina nun modelo específico, en lugar de depender do modelo que leva a cabo a tarefa do usuario. Un detector independente que analiza cada páxina antes de que o axente actúe proporciona unha capa adicional de defensa e non ten ningunha tarefa que secuestrar nin ferramentas das que facer un mal uso.

Guard está deseñado para ser ese detector. Ademais de ter o F1 e a exactitude máis altos de todos os modelos que probamos, o seu pequeno tamaño fai que sexa o bastante barato para executalo en cada páxina. De media, Guard empregou uns 0,15 segundos de tempo de GPU por páxina de texto. Nunha H200 alugada, estimamos un custo de 0,18 $ por cada 1000 páxinas, fronte a 18,95–180,61 $ dos modelos de API de vangarda a prezos de tarifa. Na nosa comparación, isto fai que a análise frecuente sexa moito máis barata sen renunciar a altas puntuacións de detección.

A figura seguinte representa a exactitude de cada detector fronte ao seu tempo por páxina e ao seu custo por cada 1000 páxinas, ambos en escalas logarítmicas. Guard sitúase só na esquina superior esquerda dos dous paneis: gaña en exactitude, velocidade e custo. Todos os modelos guiados por prompts tardan arredor dun segundo ou máis por páxina, e os dous máis exactos, GPT-6 Astra e Claude Fable 5.1, custan máis de 100 $ por cada 1000 páxinas.

Ampliar

Probar as defensas contra ataques adaptativos

O benchmark BrowseSafe++ ten un conxunto finito de inxeccións. Porén, un atacante real pode lanzar un ataque adaptativo: cando unha inxección falla, o atacante pode reescribila e tentalo de novo. Como resultado, un axente que resiste a inxección orixinal aínda podería ser vulnerable a ataques futuros. Ademais, os modelos adéstranse con datos recompilados de internet, polo que poden aprender a resistir a maioría das inxeccións do benchmark; como o estamos a publicar, probablemente acabará saturándose e deixará de diferenciar ben os modelos. Para resolver ambos os problemas, creamos BrowseSafe-Adapt, un contorno de proba no que un modelo atacante pode reescribir inxeccións. Cada proba ten tres fases:

1. Preparar o caso. Un caso agrupa unha entrada de BrowseSafe++ cun axente obxectivo. A entrada de BrowseSafe++ inclúe un escenario cunha consulta e unha tarefa do usuario, unha páxina atacada e o resultado que desexa o atacante. O axente traballa nun contorno illado que proporciona as ferramentas e os datos sintéticos necesarios para executar a tarefa. Un modelo verificador independente avalía se o ataque conseguiu o seu obxectivo.
2. Executar un intento: inserimos a inxección actual na páxina e deixamos que o axente leve a cabo a tarefa. O verificador comproba a resposta do axente e calquera cambio que fixese no contorno illado para determinar se o ataque tivo éxito. O primeiro intento usa a inxección da entrada orixinal de BrowseSafe++.
3. Revisar e repetir: se un ataque falla, arquivamos o intento e un modelo crítico analiza o que saíu mal. Un modelo atacante usa eses comentarios para reescribir a inxección; pode cambiar a redacción, o formato ou a posición do ataque na páxina. O obxectivo do ataque, os criterios de éxito e o contido circundante da páxina mantéñense iguais. O seguinte intento usa o ataque actualizado. Este proceso repítese ata que o ataque ten éxito ou o atacante alcanza un límite de intentos establecido.

Ampliar

Probamos sete axentes, cada un baseado nun modelo diferente: Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite e os modelos de pesos abertos DeepSeek V3.1 e Kimi K2. Cada axente enfrontouse ás mesmas 1024 tarefas, con ata 64 intentos por tarefa. No primeiro intento, o éxito dos ataques foi baixo nos sete axentes. As inxeccións orixinais tiveron éxito, como moito, no 4 % das tarefas avaliadas contra calquera axente. Co marco adaptativo, o éxito dos ataques aumentou drasticamente. O atacante tivo éxito en polo menos o 79 % das tarefas contra cinco dos sete axentes. Mesmo os axentes máis robustos foron vulnerables: os ataques aínda tiveron éxito en preto de dúas de cada tres tarefas contra GPT-5.5 e en preto dunha de cada tres contra Claude Sonnet 5.

A diferenza entre axentes é maior cando o obxectivo do atacante é facer que o axente realice unha chamada concreta a unha ferramenta. Nas tarefas con este tipo de obxectivo, Sonnet 5 cedeu en preto do 8 % das tarefas e GPT-5.5 en preto do 29 %. Os outros cinco levaron a cabo o obxectivo do atacante en máis da metade das súas tarefas.

Tamén executamos BrowseSafe-Adapt contra o axente de Gemini 3.5 Flash-Lite, con Guard analizando antes cada páxina. Guard bloqueou o 94,5 % das inxeccións orixinais e case duplicou o número medio de intentos que necesitaron os atacantes, de 9,7 a 17,0. Non obstante, cos 64 intentos dispoñibles, o atacante aínda tivo éxito no 84,2 % das tarefas (93,6 % sen Guard), case sempre cunha inxección que Guard non marcou. Isto coincide coa visión que expuxemos cando lanzamos BrowseSafe: ningún modelo de detección é unha solución máxica, polo que un detector ten que formar parte dunha defensa en capas.

Ampliar

Conclusión

Os axentes de navegador adoitan ser vulnerables á inxección indirecta de prompts, na que ataques ocultos en páxinas normais tentan interferir na capacidade dos axentes para levar a cabo as tarefas dos usuarios. Os perigos só aumentan co tempo, tanto porque os axentes acceden a máis datos e ferramentas, o que eleva o que está en xogo nos ataques, como porque os atacantes poden revisar as súas inxeccións para que sexan máis eficaces.

A nosa suite BrowseSafe fai fronte a estas ameazas. O benchmark BrowseSafe++ contén 38.675 pares de páxinas web construídos principalmente a partir de inxeccións reais, o que permite un adestramento e unha avaliación máis fiables dos detectores. Os detectores BrowseSafe-Guard, adestrados con estes pares, ofrecen unha detección moi exacta, rápida e barata, o que permite analizar as páxinas antes de que un axente actúe sobre elas. O marco BrowseSafe-Adapt permite probar os modelos contra inxeccións revisadas e pon de relevo vulnerabilidades que poderían non ser evidentes en intentos únicos con inxeccións fixas.

En conxunto, agardamos que estas ferramentas lles faciliten aos investigadores e enxeñeiros atopar fallos e mellorar as defensas contra os ataques de inxección de prompts baseados na web. Tamén avaliamos e melloramos continuamente as defensas integradas de Comet e Computer para manter seguros os nosos usuarios.

Primeiros pasos

1. Instala o SDK e obtén acceso aos datos. O SDK instálase desde GitHub:

O acceso ao conxunto de datos está restrinxido. Solicita acceso unha vez na súa páxina de Hugging Face e despois inicia sesión con hf auth login.

2. Envía os resultados á clasificación. Avalía o teu propio detector coa partición de proba de BrowseSafe++:

Isto escribe unha decisión por páxina para cada vista que indiques; indica as tres vistas de texto para obter unha media na táboa de clasificación de texto. Inicia sesión no Space da táboa de clasificación coa túa conta de Hugging Face e sube predictions.jsonl. O Space devolve o F1, a exactitude, a taxa de falsos positivos e as demais métricas de cada vista e, se o escolles, publica o resultado na táboa de clasificación. Cada conta (cunha antigüidade mínima de 60 días) ten dereito a un envío puntuado por semana UTC. As páxinas de proba son só para avaliación: non adestres modelos con elas nin as redistribúas. A guía de envío explica o formato do ficheiro e as 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}
}