BrowseSafe++: criando defesas mais fortes contra injeção de prompt no mundo real

Agentes capazes de navegar na web, como o assistente integrado ao Comet ou ao Computer, precisam interagir com páginas da web, lendo o conteúdo e usando-o para realizar ações em nome dos usuários. Isso os torna suscetíveis à injeção indireta de prompt, em que um atacante insere texto malicioso em uma página da web. Se o agente seguir essas instruções, ele pode retornar uma resposta enganosa ou realizar uma ação que o usuário não solicitou.

Em dezembro de 2025, lançamos o BrowseSafe, um benchmark e modelo de detecção para essa ameaça. Nós o criamos adicionando ataques sintéticos a páginas web realistas que os agentes provavelmente encontrariam. Ao longo do último ano, os ataques evoluíram, tornando-se mais sofisticados e mais parecidos com o conteúdo comum das páginas. Em vez de usar frases reveladoras como “ignore as instruções anteriores”, eles frequentemente imitam conteúdos em que o agente tende a confiar, como um aviso oficial do site ou uma observação sobre as preferências do usuário.

Motivados por essas mudanças, criamos um benchmark atualizado, o BrowseSafe++, para medir se os detectores de injeção atuais identificam esses ataques e se os agentes conseguem resistir a eles. Ele contém 38.675 pares de páginas atacadas e limpas, construídos principalmente com base em injeções coletadas no mundo real. Para cada página, reescrevemos o conteúdo ao redor para proteger a privacidade, mas mantemos o ataque exatamente como foi encontrado. Cada página é fornecida nos quatro formatos que os agentes de navegador leem: HTML, Markdown, árvores de acessibilidade e capturas de tela. Usamos um subconjunto do benchmark para treinar o BrowseSafe-Guard, um par de detectores de 0,8 bilhão de parâmetros: um detector de texto e um detector multimodal. Os dois detectores do Guard identificam injeções com mais precisão do que os modelos instruídos via prompt que testamos, incluindo modelos de fronteira. Eles também são mais rápidos, mais baratos e sinalizam por engano muito menos páginas comuns.

Estamos lançando o BrowseSafe++ como um benchmark aberto. O site do projeto traz links para o conjunto de dados, o SDK, o artigo de pesquisa e um ranking público. Qualquer equipe pode avaliar seu detector em páginas de teste cujos rótulos não são fornecidos e enviar os rótulos para avaliação e possível inclusão no ranking. Para avaliar e enviar seus resultados, consulte Primeiros passos.

Construindo um benchmark a partir de injeções observadas

O BrowseSafe++ foi construído a partir de injeções de prompt observadas em sites reais. Entre setembro de 2025 e setembro de 2026, o detector de injeção de prompt do Comet sinalizou 1,15 milhão de injeções em páginas lidas pelo seu agente. Construímos 32.187 pares com base nessas injeções e adicionamos 6.488 pares do benchmark BrowseSafe original, totalizando 38.675 pares. Cada par contém uma página atacada e sua gêmea limpa, que é a mesma página sem a injeção.

Como as injeções aparecem no mundo real

Dois exemplos do benchmark mostram como essas injeções são na prática.

Em um deles, uma solicitação de compra falsa incentiva o agente a realizar uma ação não autorizada. O detector do Comet sinalizou este bloco de texto em inglês em uma página de documentação para desenvolvedores em russo, em outubro de 2025:

O texto começa e termina com ordens e preenche o meio com marketing comum de tokens. Ele alega vir do próprio desenvolvedor do agente e termina com um código de autorização para fazer a compra parecer aprovada.

Em outro, uma conversa forjada tenta atrapalhar a tarefa do agente. Este texto foi encontrado em uma página de repositório de código em março de 2026:

O texto foi criado para parecer uma conversa entre um usuário e um agente: <|im_start|> e <|im_end|> são marcadores que alguns modelos de chat usam para separar os turnos de uma conversa. Um agente que caísse nesse ataque responderia à consulta forjada do usuário com a frase do atacante.

Observamos padrões semelhantes entre as injeções sinalizadas:

• Elas imitam fontes confiáveis. Os dois exemplos fazem o texto da página soar como uma fonte em que o agente confia: seu desenvolvedor, no primeiro, e sua própria conversa, no segundo. As injeções também podem se passar pelo próprio site, imitando verificações de segurança e avisos de políticas, ou pelo usuário, apresentando preferências falsas. Cerca de duas em cada três são escritas em linguagem formal.
• Muitas são escritas em outros idiomas. Em 24,4% dos pares, a injeção usa um idioma diferente do restante da página. Isso normalmente assume a forma de uma instrução em inglês em uma página que não está em inglês, como no primeiro exemplo. Esses ataques são claramente direcionados a um agente que lê todos os idiomas e geralmente tem o inglês como língua nativa. A troca de idioma também dificulta a detecção: em nossa avaliação original do BrowseSafe, os ataques multilíngues estavam entre os mais difíceis de detectar.
• A maioria quer ações, não palavras. Mais de quatro em cada dez levam o agente a uma ação que o usuário nunca solicitou, como a compra do token no primeiro exemplo, e cerca de um terço tenta fazê-lo abandonar a tarefa do usuário, como no segundo exemplo. Apenas cerca de 3% tentam inserir informações falsas na resposta.
• Elas costumam se aproveitar de conteúdos que qualquer pessoa pode publicar. Um invasor não precisa controlar um site. Uma publicação em fórum ou um documento compartilhado em sites comuns é suficiente, e mais de 23.000 injeções no BrowseSafe++ chegaram dessa forma. Um domínio confiável ainda pode ser usado para injetar o texto de um invasor.

As injeções presentes no benchmark final abrangem 12 tipos de sites, 24 tipos de ataque, 6 objetivos do atacante e 18 posicionamentos na página.

Expandir

De uma página sinalizada a um par do benchmark

Não podemos usar as páginas sinalizadas no benchmark como estão, porque elas podem conter informações pessoais do usuário para quem o agente estava trabalhando. Transformar uma página em um par de benchmark compartilhável exige três etapas principais:

1. Obter a injeção: Coletamos as páginas sinalizadas, removemos duplicatas e mascaramos informações pessoais com o PII-Tracer. Em seguida, confirmamos que a página contém uma injeção; especificamente, exigimos que um painel de modelos concorde que ela contém uma instrução que tenta desviar um agente da tarefa pretendida pelo usuário.
2. Montar o par: Um agente remove o texto da injeção de cada página e reescreve o conteúdo ao redor, substituindo detalhes como nomes e marcas por outros fictícios. Um segundo agente verifica se restou conteúdo do mundo real na página reescrita e devolve as falhas com feedback. Revisores humanos inspecionam uma amostra aleatória de 10% das páginas; os problemas encontrados são corrigidos no pipeline, e as correções são aplicadas a todo o corpus. A injeção é reinserida na página reescrita para criar a cópia atacada e deixada de fora da cópia limpa. As duas páginas compartilham a mesma tarefa, o mesmo resultado esperado e as mesmas instruções comuns.
3. Verificar: Os agentes leem as páginas em diferentes formatos, por isso renderizamos o HTML de cada página como Markdown, como uma árvore de acessibilidade (uma lista estruturada dos elementos de interface de uma página e seus rótulos) e como uma captura de tela. Outro agente verifica se a injeção aparece nas quatro visualizações da página atacada e se a página limpa é considerada benigna em todas as visualizações. Se a injeção estiver ausente em uma das visualizações, nós a movemos para outro ponto da página e renderizamos novamente, garantindo que a injeção esteja presente na página atacada final em todas as visualizações. Um conjunto final de verificações automatizadas corrige os pares que ainda tenham vestígios de sua origem, como nomes de host ou de marcas reais.

Expandir

BrowseSafe-Guard: detectores rápidos e precisos para todas as visualizações

Um detector útil precisa verificar cada página de forma rápida e barata. Ele também precisa ser preciso tanto em páginas atacadas quanto em páginas limpas. A alta precisão é especialmente importante, já que a maioria das páginas é segura; mesmo uma taxa de falsos positivos relativamente baixa faria com que a maioria dos alertas fossem alarmes falsos. Modelos de uso geral instruídos via prompt costumam deixar a desejar em precisão e são lentos e caros demais para serem executados em todas as páginas.

Um detector treinado com páginas atacadas e páginas limpas coletadas separadamente poderia aprender atalhos que, por acaso, separam os dois conjuntos, como o tema ou o layout de uma página. Esse detector, no entanto, não generaliza bem. Em vez disso, o Guard treina com pares cuja única diferença é a própria injeção, o que ajuda a melhorar a precisão do detector. Para cada par, o Guard lê a página atacada e sua gêmea limpa separadamente e atribui a cada uma delas uma pontuação que indica a probabilidade de conter uma injeção. Dois objetivos de treinamento são usados para atualizar o modelo: o objetivo de classificação padrão e um objetivo de ranqueamento que penaliza o Guard, a menos que a página atacada receba uma pontuação maior que a de sua gêmea por pelo menos uma margem fixa. Intuitivamente, o objetivo de classificação ensina ao Guard qual decisão tomar, e o objetivo de ranqueamento vincula essa decisão à própria injeção e ignora distratores benignos. Isso treina o Guard para responder à própria injeção, e não ao conteúdo da página ao redor.

O Guard consiste em dois detectores, cada um ajustado a partir do Qwen3.5-0.8B. O detector de texto lê uma visualização de texto de uma página: HTML, Markdown ou árvore de acessibilidade. O detector multimodal lê uma captura de tela da página inteira. Na implantação, o Guard lê uma página em uma única passagem direta e gera uma pontuação de injeção, e a página é sinalizada se a pontuação ultrapassar um limite. Como o Guard tem apenas 0,8 bilhão de parâmetros e gera uma única pontuação, ele é rápido e barato o suficiente para ser executado em todas as páginas.

Avaliação de desempenho

Comparamos o Guard com 18 modelos instruídos via prompt a detectar injeções em um subconjunto reservado do benchmark. Relatamos quatro métricas, medidas no BrowseSafe++:

• O recall é a proporção de páginas com injeção que o detector sinaliza, o que mede quantos ataques ele identifica; portanto, quanto maior, melhor.
• A taxa de falsos positivos (FPR) é a proporção de páginas limpas que o detector sinaliza por engano, o que mede com que frequência ele gera alarmes falsos; portanto, quanto menor, melhor.
• A precisão é a proporção de páginas sinalizadas que realmente contêm uma injeção, o que mede com que frequência um alerta está correto; portanto, quanto maior, melhor.
• O F1 é a média harmônica entre recall e precisão; ele só é alto quando um detector identifica a maioria dos ataques e poucas de suas sinalizações são alarmes falsos.

Usamos o F1 como métrica principal, já que um bom detector deve ter alta precisão e alto recall. As quatro métricas são calculadas como médias das três visualizações de texto.

Expandir

Expandir

Comparações de modelos

Os modelos pequenos de pesos abertos que testamos ficaram nas últimas posições. O Mistral NeMo e o Qwen3 30B-A3B sinalizam cerca de metade das páginas limpas, enquanto o Llama 3.1 8B raramente sinaliza algo e deixa passar a maioria dos ataques. Mesmo o modelo mais forte do grupo, o GPT-OSS 20B, atinge um F1 de apenas 70,97%. O DeepSeek V3.1, um modelo de pesos abertos muito maior, se sai um pouco melhor, com F1 de 75,23%.

Modelos de API leves, incluindo GPT-5.4 nano, Gemini 3.1 Flash-Lite e Claude Haiku 4.5, detectam mais ataques, com recall entre 85% e 97%. No entanto, o custo é uma alta proporção de alarmes falsos; o Gemini 3.1 Flash-Lite tem a menor FPR do grupo, de 35,2%, e a FPR do Haiku é de quase 69%. Como resultado, a pontuação F1 máxima do grupo é de 80,9%, alcançada pelo Gemini 3.1 Flash-Lite.

Os demais modelos são modelos de uso geral mais fortes, com pontuações F1 entre 85% e 92%. No entanto, eles ainda precisam equilibrar recall e FPR: modelos que tendem à cautela bloqueiam páginas legítimas, e modelos que sinalizam com menos frequência deixam passar ataques. O Claude Sonnet 5 tem o maior recall entre todos os detectores, com 98,73%, mas uma FPR de 24,65%. O Gemini 3.1 Pro e o GPT-5.5 atingem recalls de 97,78% e 97,19%, com FPRs de 19,80% e 20,44%, respectivamente. O GPT-6 Astra tem a maior acurácia geral, com recall de 96,42% e FPR de 14,41%. O Decider vem em segundo lugar, com recall de 96,02% e FPR de 17,44%. O Claude Opus 5.5 tem a menor FPR, de apenas 4,21%, mas seu recall de 77,71% significa que ele deixa passar mais de um em cada cinco ataques. O Claude Fable 5.1 parece forte nas páginas que responde, com recall de 89,31% e FPR de 7,92%, mas se recusa a responder em cerca de 30% das páginas, que a linha “(all)” conta como sinalizações.

Expandir

O Guard avança a fronteira de Pareto, alcançando um equilíbrio melhor entre ataques não detectados e alarmes falsos. Ele atinge um F1 de cerca de 95% e fica em primeiro lugar em todas as visualizações de texto. Ele sinaliza apenas cerca de uma em cada 20 páginas limpas, aproximadamente um terço da taxa do Astra, o modelo instruído via prompt com maior acurácia. Essa diferença vem do nosso treinamento: o Qwen3.5-0.8B original, no qual o Guard se baseia, instruído via prompt da mesma forma que os outros modelos, atinge um F1 de apenas 64% e sinaliza quase três em cada quatro páginas limpas. No cenário de visualização por capturas de tela, comparamos o detector multimodal do Guard com quatro modelos com suporte a imagens. Com capturas de tela de página inteira, o Guard atinge cerca de 93% de F1, contra cerca de 79% do melhor entre os outros modelos que avaliamos.

Reconhecer um ataque não é o mesmo que resistir a ele

Intuitivamente, um modelo capaz de identificar corretamente uma injeção também deveria ignorá-la ao encontrar a página enquanto realiza as tarefas do usuário. No entanto, nossos experimentos mostram que boas pontuações de detecção não garantem que um modelo resistirá a um ataque. Fornecemos a cada modelo a mesma página atacada duas vezes: uma para avaliar se ela continha uma injeção e outra para realizar a tarefa do usuário sem ver o veredito anterior. Um juiz separado verificou se o modelo seguiu a injeção. Todos os modelos testados ainda seguiram algumas injeções que haviam sinalizado, de 1,64% das páginas sinalizadas, no caso do GPT-6 Astra, a 24,73%, no caso do Llama 3.1 8B.

Expandir

As pontuações de detecção não preveem de forma confiável as diferenças entre os modelos. O Claude Sonnet 5 e o GPT-5.5 detectam injeções quase igualmente bem, com pontuações F1 de cerca de 88% e 89%, respectivamente. No entanto, o Sonnet 5 seguiu uma injeção que havia sinalizado em 19,74% das páginas, dez vezes mais do que o GPT-5.5, com 1,97%.

Um sistema implantável para defesa contra injeções

Esses resultados sugerem que vale a pena delegar a decisão de bloquear uma página a um modelo de finalidade específica, em vez de depender do modelo que realiza a tarefa do usuário. Um detector separado que analisa cada página antes que o agente aja oferece uma camada extra de defesa e não tem nenhuma tarefa a ser sequestrada nem ferramentas a serem usadas indevidamente.

O Guard foi criado para ser esse detector. Além de ter o maior F1 e a maior acurácia entre todos os modelos que testamos, seu tamanho reduzido o torna barato o suficiente para ser executado em todas as páginas. Em média, o Guard usou cerca de 0,15 segundo de tempo de GPU por página de texto. Em uma H200 alugada, estimamos um custo de US$ 0,18 por 1.000 páginas, em comparação com US$ 18,95–180,61 para os modelos de API de ponta a preços de tabela. Isso torna a triagem frequente muito mais barata em nossa comparação, mantendo pontuações de detecção altas.

A figura abaixo mostra a acurácia de cada detector em relação ao tempo por página e ao custo por 1.000 páginas, ambos em escala logarítmica. O Guard aparece sozinho no canto superior esquerdo dos dois painéis: ele vence em acurácia, velocidade e custo. Todos os modelos instruídos via prompt levam cerca de um segundo ou mais por página, e os dois com maior acurácia, GPT-6 Astra e Claude Fable 5.1, custam mais de US$ 100 por 1.000 páginas.

Expandir

Testando defesas contra ataques adaptativos

O benchmark BrowseSafe++ tem um conjunto finito de injeções. No entanto, um atacante real pode realizar um ataque adaptativo: quando uma injeção falha, o atacante pode reescrevê-la e tentar novamente. Como resultado, um agente que resiste à injeção original ainda pode ser suscetível a ataques futuros. Além disso, os modelos são treinados com dados coletados da internet, então podem aprender a resistir à maioria das injeções presentes nela; como estamos lançando nosso benchmark publicamente, ele provavelmente ficará saturado e deixará de diferenciar bem os modelos. Para resolver os dois problemas, criamos o BrowseSafe-Adapt, um ambiente de testes em que um modelo atacante pode reescrever injeções. Cada teste tem três etapas:

1. Configure o caso. Um caso agrupa uma entrada do BrowseSafe++ com um agente-alvo. A entrada do BrowseSafe++ inclui um cenário com uma consulta e uma tarefa do usuário, uma página atacada e o resultado desejado pelo invasor. O agente trabalha em um sandbox que fornece as ferramentas e os dados sintéticos necessários para executar a tarefa. Um modelo verificador separado avalia se o ataque atingiu seu objetivo.
2. Executar uma tentativa: Inserimos a injeção atual na página e deixamos o agente realizar a tarefa. O verificador analisa a resposta do agente e quaisquer alterações que ele tenha feito no sandbox para determinar se o ataque teve sucesso. A primeira tentativa usa a injeção da entrada original do BrowseSafe++.
3. Revisar e repetir: Se um ataque falhar, arquivamos a tentativa, e um modelo crítico analisa o que deu errado. Um modelo atacante usa esse feedback para reescrever a injeção; ele pode alterar a redação, a formatação ou a posição do ataque na página. O objetivo do ataque, os critérios de sucesso e o conteúdo ao redor na página permanecem os mesmos. A próxima tentativa usa o ataque atualizado. Esse processo se repete até que o ataque tenha sucesso ou o atacante atinja um limite definido de tentativas.

Expandir

Testamos sete agentes, cada um baseado em um 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 agente enfrentou as mesmas 1.024 tarefas, com até 64 tentativas por tarefa. Na primeira tentativa, o sucesso dos ataques foi baixo em todos os sete agentes. As injeções originais tiveram sucesso em no máximo 4% das tarefas avaliadas contra qualquer agente. No framework adaptativo, o sucesso dos ataques aumentou drasticamente. O atacante teve sucesso em pelo menos 79% das tarefas contra cinco dos sete agentes. Mesmo os agentes mais fortes foram suscetíveis: os ataques ainda tiveram sucesso em cerca de duas em cada três tarefas contra o GPT-5.5 e em cerca de uma em cada três contra o Claude Sonnet 5.

A diferença entre os agentes é maior quando o objetivo do atacante é fazer o agente emitir uma chamada de ferramenta específica. Em tarefas com esse tipo de objetivo, o Sonnet 5 cedeu em cerca de 8% das tarefas e o GPT-5.5 em cerca de 29%. Os outros cinco executaram o objetivo do atacante em mais da metade das tarefas.

Também executamos o BrowseSafe-Adapt contra o agente Gemini 3.5 Flash-Lite com o Guard analisando previamente cada página. O Guard bloqueou 94,5% das injeções originais e quase dobrou o número médio de tentativas de que os atacantes precisaram, de 9,7 para 17,0. Com todas as 64 tentativas, no entanto, o atacante ainda teve sucesso em 84,2% das tarefas (93,6% sem o Guard), quase sempre com uma injeção que o Guard não sinalizou. Isso está de acordo com a visão que apresentamos quando lançamos o BrowseSafe: nenhum modelo de detecção é uma bala de prata, então um detector precisa fazer parte de uma defesa em camadas.

Expandir

Conclusão

Agentes de navegador costumam ser suscetíveis à injeção indireta de prompt, em que ataques ocultos em páginas comuns tentam interferir na capacidade dos agentes de realizar as tarefas dos usuários. Os perigos só aumentam com o tempo, tanto porque os agentes ganham acesso a mais dados e ferramentas, elevando o que está em jogo nos ataques, quanto porque os atacantes podem revisar suas injeções para torná-las mais eficazes.

Nosso conjunto BrowseSafe aborda essas ameaças. O benchmark BrowseSafe++ contém 38.675 pares de páginas da web construídos principalmente a partir de injeções reais, permitindo um treinamento e uma avaliação mais confiáveis de detectores. Os detectores BrowseSafe-Guard, treinados com esses pares, permitem uma detecção altamente precisa, rápida e barata, possibilitando analisar as páginas antes que um agente aja com base nelas. O framework BrowseSafe-Adapt permite testar modelos contra injeções revisadas, evidenciando vulnerabilidades que podem não ser aparentes em tentativas únicas com injeções fixas.

Esperamos que, juntas, essas ferramentas facilitem para pesquisadores e engenheiros a tarefa de encontrar falhas e aprimorar as defesas contra ataques de injeção de prompt baseados na web. Também estamos avaliando e aprimorando continuamente as defesas integradas do Comet e do Computer para manter nossos usuários seguros.

Primeiros passos

1. Instale o SDK e obtenha acesso aos dados. O SDK é instalado a partir do GitHub:

O acesso ao conjunto de dados é restrito. Solicite acesso uma única vez na página do Hugging Face e, em seguida, faça login com hf auth login.

2. Envie para o ranking. Avalie seu próprio detector na divisão de teste do BrowseSafe++:

Isso grava uma decisão por página para cada visualização que você listar; liste as três visualizações de texto para obter uma média no ranking de texto. Faça login no Space do ranking com sua conta do Hugging Face e envie predictions.jsonl. O Space retorna F1, acurácia, taxa de falsos positivos e as outras métricas de cada visualização e, se você quiser, publica o resultado no ranking. Cada conta (com pelo menos 60 dias de existência) tem direito a um envio pontuado por semana UTC. As páginas de teste são apenas para avaliação: não as use para treinamento nem as redistribua. O guia de envio aborda o formato do arquivo e as regras de publicação.

Citação

@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}
}