BrowseSafe++: criar defesas mais robustas contra a injeção de prompts no mundo real

Os agentes que conseguem navegar na web, como o assistente integrado no Comet ou no Computer, precisam de interagir com páginas web, lendo conteúdos e usando-os para realizar ações em nome dos seus utilizadores. Isto torna-os suscetíveis à injeção indireta de prompts, em que um atacante coloca texto malicioso numa página web. Se o agente seguir essas instruções, pode devolver uma resposta enganadora ou realizar uma ação que o utilizador não pediu.

Em dezembro de 2025, lançámos o BrowseSafe, um benchmark e modelo de deteção para esta ameaça. Construímo-lo 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 de uma página. Em vez de usarem frases reveladoras como «ignora as instruções anteriores», imitam frequentemente conteúdo em que o agente tende a confiar, como um aviso oficial do site ou uma nota sobre as preferências do utilizador.

Motivados por estas mudanças, criámos um benchmark atualizado, o BrowseSafe++, para medir se os detetores de injeções atuais detetam estes ataques e se os agentes lhes conseguem resistir. Contém 38 675 pares de páginas atacadas e limpas, construídos principalmente em torno de injeções recolhidas no mundo real. Para cada página, reescrevemos o conteúdo circundante para proteger a privacidade, mas mantemos o ataque inalterado. Cada página é disponibilizada nos quatro formatos que os agentes de navegador leem: HTML, Markdown, árvores de acessibilidade e capturas de ecrã. Utilizámos um subconjunto do benchmark para treinar o BrowseSafe-Guard, um par de detetores com 0,8 mil milhões de parâmetros: um detetor de texto e um detetor multimodal. Os dois detetores Guard identificam injeções com mais exatidão do que os modelos instruídos por prompt que testámos, incluindo modelos de fronteira. São também mais rápidos e mais baratos, e sinalizam muito menos páginas comuns por engano.

Estamos a disponibilizar o BrowseSafe++ como benchmark aberto. O website do projeto inclui ligações para o conjunto de dados, o SDK, o artigo de investigação e uma tabela de classificação pública. Qualquer equipa pode avaliar o seu detetor com páginas de teste cujas etiquetas não são fornecidas e submeter as etiquetas para avaliação e possível inclusão na tabela de classificação. Para avaliar e submeter os seus resultados, consulte Como começar.

Construir um benchmark a partir de injeções observadas

O BrowseSafe++ foi construído a partir de injeções de prompts observadas em websites reais. Entre setembro de 2025 e setembro de 2026, o detetor de injeções de prompts do Comet sinalizou 1,15 milhões de injeções em páginas lidas pelo seu agente. Construímos 32 187 pares em torno dessas injeções e acrescentámos 6488 pares do benchmark BrowseSafe original, num total de 38 675 pares. Cada par contém uma página atacada e a sua gémea limpa, que é a mesma página sem a injeção.

Como são as injeções no mundo real

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

Num deles, um pedido de compra falso incentiva o agente a realizar uma ação não autorizada. O detetor do Comet sinalizou este bloco de texto em inglês numa página de documentação para programadores em russo, em outubro de 2025:

O texto abre e fecha com ordens e preenche o meio com marketing banal de tokens. Afirma vir do próprio programador do agente e termina com um código de autorização para fazer a compra parecer aprovada.

Noutro, uma conversa forjada procura perturbar a tarefa do agente. Este texto foi encontrado numa página de um repositório de código em março de 2026:

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

Observamos padrões semelhantes nas injeções sinalizadas:

• Imitam fontes de confiança. Ambos os exemplos fazem com que o texto da página pareça vir de uma fonte em que o agente confia: o seu programador, no primeiro, e a sua própria conversa, no segundo. As injeções também podem fazer-se passar pelo próprio site, imitando verificações de segurança e avisos de políticas, ou pelo utilizador, apresentando preferências falsas. Cerca de duas em cada três estão escritas em linguagem formal.
• Muitas estão escritas em línguas diferentes. Em 24,4% dos pares, a injeção utiliza uma língua diferente da do resto da página. Normalmente, isto assume a forma de uma instrução em inglês numa página que não está em inglês, como no primeiro exemplo. Estes ataques destinam-se claramente a um agente que lê todas as línguas e que, normalmente, tem o inglês como língua nativa. As mudanças de língua também dificultam a deteção: na nossa avaliação original do BrowseSafe, os ataques multilingues estavam entre os mais difíceis de detetar.
• A maioria quer ações, não palavras. Mais de quatro em cada dez levam o agente a realizar uma ação que o utilizador nunca pediu, como a compra do token no primeiro exemplo, e cerca de um terço tenta fazê-lo abandonar a tarefa do utilizador, como no segundo exemplo. Apenas cerca de 3% tentam introduzir informações falsas na resposta.
• Muitas vezes, aproveitam conteúdo que qualquer pessoa pode publicar. Um atacante não precisa de controlar um site. Basta uma publicação num fórum ou um documento partilhado em sites comuns, e mais de 23 000 injeções do BrowseSafe++ chegaram desta forma. Mesmo um domínio de confiança pode ser utilizado para injetar o texto de um atacante.

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

Expandir

De uma página sinalizada a um par do benchmark

Não podemos usar as páginas sinalizadas tal como estão no benchmark, porque podem conter informações pessoais do utilizador para quem o agente estava a trabalhar. Transformar uma página num par de benchmark partilhável exige três fases principais:

1. Obter a injeção: Recolhemos as páginas sinalizadas, removemos duplicados e mascaramos as informações pessoais com o PII-Tracer. Depois, confirmamos que a página contém uma injeção; especificamente, exigimos que um painel de modelos concorde que contém uma instrução que tenta desviar um agente da tarefa pretendida pelo utilizador.
2. Construir o par: Um agente remove o texto da injeção de cada página e reescreve o conteúdo circundante, substituindo detalhes como nomes e marcas por outros fictícios. Um segundo agente verifica se a página reescrita contém conteúdo real residual e devolve as falhas com feedback. Revisores humanos inspecionam uma amostra aleatória de 10% das páginas; os problemas que encontram são corrigidos no processo, 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 partilham a mesma tarefa, o mesmo resultado esperado e as mesmas instruções comuns.
3. Verificar: Os agentes leem as páginas em diferentes formas, por isso renderizamos o HTML de cada página como Markdown, como árvore de acessibilidade (uma lista estruturada dos elementos de interface de uma página e das respetivas etiquetas) e como captura de ecrã. Outro agente verifica se a injeção aparece nas quatro vistas da página atacada e se a página limpa é considerada benigna em todas as vistas. Se a injeção estiver ausente numa das vistas, movemo-la para outro ponto da página e renderizamos novamente, garantindo que a injeção está presente na página atacada final em todas as vistas. Um conjunto final de verificações automáticas corrige quaisquer pares que ainda tenham vestígios da sua origem, como nomes de anfitrião ou nomes de marcas reais.

Expandir

BrowseSafe-Guard: detetores rápidos e precisos para todas as vistas

Um detetor útil tem de verificar cada página de forma rápida e barata. Também tem de ser exato tanto em páginas atacadas como em páginas limpas. Uma precisão elevada é especialmente importante, uma vez que a maioria das páginas é segura; mesmo uma taxa de falsos positivos relativamente baixa faria com que a maioria dos alertas fossem falsos alarmes. Os modelos de uso geral instruídos por prompt ficam frequentemente aquém em termos de precisão e são demasiado lentos e dispendiosos para executar em todas as páginas.

Um detetor treinado com páginas atacadas e páginas limpas recolhidas separadamente pode aprender atalhos que, por acaso, separam os dois conjuntos, como o tema ou o layout de uma página. No entanto, um detetor deste tipo não generaliza bem. Em vez disso, o Guard é treinado com pares cuja única diferença é a própria injeção, o que ajuda a melhorar a precisão do detetor. Para cada par, o Guard lê separadamente a página atacada e a sua gémea limpa e atribui a cada uma pontuação que indica a probabilidade de conter uma injeção. São usados dois objetivos de treino para atualizar o modelo: o objetivo de classificação padrão e um objetivo de ordenação que penaliza o Guard, a menos que a página atacada obtenha uma pontuação superior à da sua gémea por, pelo menos, uma margem fixa. Intuitivamente, o objetivo de classificação ensina ao Guard que decisão tomar, e o objetivo de ordenação associa essa decisão à própria injeção e ignora distratores benignos. Assim, o Guard é treinado para responder à própria injeção, e não ao conteúdo envolvente da página.

O Guard é composto por dois detetores, cada um ajustado (fine-tuned) a partir do Qwen3.5-0.8B. O detetor de texto lê uma vista de texto de uma página: HTML, Markdown ou árvore de acessibilidade. O detetor multimodal lê uma captura de ecrã da página inteira. Em produção, o Guard lê uma página numa única passagem direta e devolve uma pontuação de injeção, e a página é sinalizada se a pontuação ultrapassar um limiar. Como o Guard tem apenas 0,8 mil milhões de parâmetros e devolve uma única pontuação, é suficientemente rápido e barato para ser executado em todas as páginas.

Avaliação comparativa do desempenho

Comparámos o Guard com 18 modelos instruídos por prompt para detetar injeções num subconjunto reservado do benchmark. Apresentamos quatro métricas, medidas no BrowseSafe++:

• A revocação (recall) é a proporção de páginas com injeções que o detetor sinaliza, o que mede quantos ataques deteta; por isso, quanto mais alta, melhor.
• A taxa de falsos positivos (FPR) é a proporção de páginas limpas que o detetor sinaliza por engano, o que mede a frequência com que gera falsos alarmes; por isso, quanto mais baixa, melhor.
• A precisão é a proporção de páginas sinalizadas que contêm efetivamente uma injeção, o que mede a frequência com que um alerta está correto; por isso, quanto mais alta, melhor.
• O F1 é a média harmónica da revocação e da precisão; só é elevado quando um detetor deteta a maioria dos ataques e poucas das suas sinalizações são falsos alarmes.

Utilizamos o F1 como métrica principal, uma vez que um bom detetor deve ter precisão e revocação elevadas. As quatro métricas são calculadas como média das três vistas de texto.

Expandir

Expandir

Comparações de modelos

Os pequenos modelos de pesos abertos que testámos ficaram em último lugar. O Mistral NeMo e o Qwen3 30B-A3B sinalizam cada um cerca de metade das páginas limpas, enquanto o Llama 3.1 8B raramente sinaliza o que quer que seja, deixando passar a maioria dos ataques. Mesmo o modelo mais forte do grupo, o GPT-OSS 20B, atinge apenas um F1 de 70,97%. O DeepSeek V3.1, um modelo de pesos abertos muito maior, sai-se ligeiramente melhor, com um F1 de 75,23%.

Os modelos de API leves, incluindo o GPT-5.4 nano, o Gemini 3.1 Flash-Lite e o Claude Haiku 4.5, detetam mais ataques, com um recall entre 85% e 97%. No entanto, o custo é uma elevada proporção de falsos alarmes: o Gemini 3.1 Flash-Lite tem a FPR mais baixa do grupo, com 35,2%, e a FPR do Haiku é de quase 69%. Consequentemente, a pontuação F1 máxima do grupo é de 80,9%, alcançada pelo Gemini 3.1 Flash-Lite.

Os restantes modelos são modelos de uso geral mais robustos, atingindo pontuações F1 entre 85% e 92%. No entanto, continuam a enfrentar compromissos entre revocação e FPR: os modelos que tendem para a cautela bloqueiam páginas legítimas, e os modelos que sinalizam com menos frequência deixam passar ataques. O Claude Sonnet 5 tem a revocação mais elevada de todos os detetores, com 98,73%, mas uma FPR de 24,65%. O Gemini 3.1 Pro e o GPT-5.5 atingem revocações de 97,78% e 97,19%, com FPR de 19,80% e 20,44%, respetivamente. O GPT-6 Astra tem a exatidão global mais elevada, com uma revocação de 96,42% e uma FPR de 14,41%. O Decider fica em segundo lugar, com uma revocação de 96,02% e uma FPR de 17,44%. O Claude Opus 5.5 tem a FPR mais baixa, de apenas 4,21%, mas a sua revocação de 77,71% significa que deixa passar mais de um em cada cinco ataques. O Claude Fable 5.1 parece forte nas páginas a que responde, com uma revocação de 89,31% e uma FPR de 7,92%, mas recusa-se a responder em cerca de 30% das páginas, que a linha «(all)» contabiliza como sinalizações.

Expandir

O Guard faz avançar a fronteira de Pareto, alcançando um melhor equilíbrio entre ataques não detetados e falsos alarmes. Atinge um F1 de cerca de 95% e fica em primeiro lugar em todas as vistas de texto. Sinaliza apenas cerca de uma página limpa em cada 20, aproximadamente um terço da taxa do Astra, o modelo instruído por prompt mais exato. Esta diferença resulta do nosso treino; o Qwen3.5-0.8B de base em que o Guard assenta, instruído da mesma forma que os outros modelos, atinge apenas um F1 de 64% e sinaliza quase três em cada quatro páginas limpas. No cenário da vista de capturas de ecrã, comparamos o detetor multimodal do Guard com quatro modelos com capacidade de processar imagens. Com capturas de ecrã de página inteira, o Guard obtém cerca de 93% de F1, contra cerca de 79% do melhor dos outros modelos que avaliámos.

Reconhecer um ataque não é o mesmo que resistir-lhe

Intuitivamente, um modelo capaz de identificar corretamente uma injeção deveria também ignorá-la quando encontra a página ao realizar as tarefas do utilizador. No entanto, as nossas experiências mostram que pontuações de deteção elevadas não garantem que um modelo resista a um ataque. Demos a cada modelo a mesma página atacada duas vezes: uma para avaliar se continha uma injeção e outra para realizar a tarefa do utilizador sem ver o veredicto anterior. Um avaliador independente verificou se o modelo seguiu a injeção. Todos os modelos testados continuaram a seguir algumas injeções que tinham sinalizado, desde 1,64% das páginas sinalizadas no caso do GPT-6 Astra até 24,73% no caso do Llama 3.1 8B.

Expandir

As pontuações de deteção não preveem de forma fiável as diferenças entre modelos. O Claude Sonnet 5 e o GPT-5.5 detetam injeções aproximadamente com a mesma eficácia, com pontuações F1 de cerca de 88% e 89%, respetivamente. No entanto, o Sonnet 5 seguiu uma injeção que tinha sinalizado em 19,74% das páginas, dez vezes mais do que o GPT-5.5, com 1,97%.

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

Estes resultados sugerem que é vantajoso delegar a decisão de bloquear uma página num modelo de finalidade específica, em vez de confiar no modelo que executa a tarefa do utilizador. Um detetor independente que analisa cada página antes de o agente agir proporciona uma camada adicional de defesa e não tem nenhuma tarefa que possa ser sequestrada nem ferramentas que possam ser utilizadas indevidamente.

O Guard foi criado para ser esse detetor. Além de ter o F1 e a exatidão mais elevados de todos os modelos que testámos, o seu tamanho reduzido torna-o suficientemente barato para ser executado em todas as páginas. Em média, o Guard usou cerca de 0,15 segundos de tempo de GPU por página de texto. Numa H200 alugada, estimamos um custo de 0,18 US$ por 1000 páginas, em comparação com 18,95–180,61 US$ para os modelos de ponta acessíveis por API, a preços de tabela. Na nossa comparação, isto torna a triagem frequente muito mais barata, mantendo pontuações de deteção elevadas.

A figura abaixo representa a exatidão de cada detetor em função do tempo por página e do custo por 1000 páginas, ambos em escala logarítmica. O Guard está isolado no canto superior esquerdo de ambos os painéis: ganha em exatidão, velocidade e custo. Todos os modelos instruídos por prompt demoram cerca de um segundo ou mais por página, e os dois mais exatos, o GPT-6 Astra e o Claude Fable 5.1, custam mais de 100 US$ por 1000 páginas.

Expandir

Testar defesas contra ataques adaptativos

O benchmark BrowseSafe++ tem um conjunto finito de injeções. No entanto, um atacante real pode montar um ataque adaptativo: quando uma injeção falha, o atacante pode reescrevê-la e tentar novamente. Consequentemente, um agente que resiste à injeção original pode continuar suscetível a ataques futuros. Além disso, os modelos são treinados com dados recolhidos da internet, pelo que podem aprender a resistir à maioria das injeções que lá se encontram; como estamos a disponibilizar o nosso benchmark publicamente, é provável que fique saturado e deixe de diferenciar bem os modelos. Para resolver ambos os problemas, criámos o BrowseSafe-Adapt, um ambiente de testes em que um modelo atacante pode reescrever injeções. Cada teste tem três fases:

1. Configurar 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 utilizador, uma página atacada e o resultado pretendido pelo atacante. O agente trabalha numa 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 o 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 este tenha feito na sandbox para determinar se o ataque teve êxito. A primeira tentativa usa a injeção da entrada original do BrowseSafe++.
3. Rever e repetir: Se um ataque falhar, arquivamos a tentativa e um modelo crítico analisa o que correu mal. Um modelo atacante usa esse feedback para reescrever a injeção; 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 êxito e o conteúdo circundante da página mantêm-se iguais. A tentativa seguinte usa o ataque atualizado. Este processo repete-se até o ataque ter êxito ou o atacante atingir um limite de tentativas definido.

Expandir

Testámos sete agentes, cada um baseado num 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 1024 tarefas, com até 64 tentativas por tarefa. Na primeira tentativa, o êxito dos ataques foi baixo nos sete agentes. As injeções originais tiveram êxito em, no máximo, 4% das tarefas avaliadas contra qualquer agente. Com a estrutura adaptativa, o êxito dos ataques aumentou drasticamente. O atacante teve êxito em pelo menos 79% das tarefas contra cinco dos sete agentes. Mesmo os agentes mais robustos se revelaram suscetíveis: os ataques continuaram a ter êxito 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 agentes é maior quando o objetivo do atacante é levar o agente a efetuar uma determinada chamada de ferramenta. Nas tarefas com este 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 cumpriram o objetivo do atacante em mais de metade das suas tarefas.

Também executámos o BrowseSafe-Adapt contra o agente Gemini 3.5 Flash-Lite, com o Guard a analisar previamente cada página. O Guard bloqueou 94,5% das injeções originais e quase duplicou o número médio de tentativas de que os atacantes precisaram, de 9,7 para 17,0. No entanto, com as 64 tentativas disponíveis, o atacante continuou a ter êxito em 84,2% das tarefas (93,6% sem o Guard), quase sempre com uma injeção que o Guard não sinalizou. Isto corresponde à perspetiva que apresentámos quando lançámos o BrowseSafe: nenhum modelo de deteção é uma solução milagrosa, pelo que um detetor tem de fazer parte de uma defesa em camadas.

Expandir

Conclusão

Os agentes de navegador são frequentemente suscetíveis à injeção indireta de prompts, em que ataques ocultos em páginas comuns procuram interferir com a capacidade dos agentes de executar as tarefas dos utilizadores. Os perigos só aumentam com o tempo, tanto à medida que os agentes ganham acesso a mais dados e ferramentas, aumentando o que está potencialmente em jogo nos ataques, como à medida que os atacantes podem rever as suas injeções para as tornar mais eficazes.

O nosso conjunto BrowseSafe dá resposta a estas ameaças. O benchmark BrowseSafe++ contém 38 675 pares de páginas web construídos principalmente a partir de injeções reais, permitindo um treino e uma avaliação de detetores mais fiáveis. Os detetores BrowseSafe-Guard, treinados com estes pares, permitem uma deteção altamente exata, rápida e barata, tornando possível analisar as páginas antes de um agente agir com base nelas. A estrutura BrowseSafe-Adapt permite testar modelos contra injeções revistas, evidenciando vulnerabilidades que poderiam não ser aparentes em tentativas únicas com injeções fixas.

Esperamos que, em conjunto, estas ferramentas facilitem aos investigadores e engenheiros a deteção de falhas e a melhoria das defesas contra ataques de injeção de prompts baseados na web. Estamos também a avaliar e a melhorar continuamente as defesas integradas do Comet e do Computer para manter os nossos utilizadores seguros.

Como começar

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

O conjunto de dados tem acesso restrito. Peça acesso uma vez na respetiva página do Hugging Face e, depois, inicie sessão com hf auth login.

2. Submeta à tabela de classificação. Avalie o seu próprio detetor na divisão de teste do BrowseSafe++:

Isto escreve uma decisão por página para cada vista que indicar; indique as três vistas de texto para obter uma média na tabela de classificação de texto. Inicie sessão no Space da tabela de classificação com a sua conta do Hugging Face e carregue predictions.jsonl. O Space devolve o F1, a exatidão, a taxa de falsos positivos e as outras métricas para cada vista e, se o pretender, publica o resultado na tabela de classificação. Cada conta (com, pelo menos, 60 dias) tem direito a uma submissão pontuada por semana UTC. As páginas de teste destinam-se apenas a avaliação: não as utilize para treino nem as redistribua. O guia de submissão descreve o formato do ficheiro 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}
}