O Sequestro Zero-Click Expõe um Risco Central de Segurança em Navegadores de IA

O Google News destacou um alerta de que navegadores de IA podem ser sequestrados sem que a vítima clique, aprove ou abra conscientemente um comando malicioso. Pesquisadores de segurança afirmam que conteúdo elaborado pode redirecionar um agente enquanto ele executa uma tarefa comum. A mesma automação que economiza tempo pode então expor arquivos, credenciais, mensagens ou contas autenticadas.

A pesquisa se concentra no PleaseFix, uma classe de vulnerabilidades que a Zenity Labs apresentou em março de 2026 e ampliou na Black Hat USA. Diferentemente da engenharia social convencional, o ataque mira o software que atua em nome do usuário. Um convite de calendário, publicação social, site ou formulário de newsletter pode se tornar o canal de instruções.

Isso cria um conflito que os fabricantes de navegadores não podem descartar como mais um bug isolado. Navegadores de IA precisam de amplo acesso para concluir tarefas úteis em diferentes sites. Esse acesso se torna perigoso quando o agente não consegue separar com segurança o objetivo do usuário das instruções inseridas em conteúdo não confiável.

A Dark Reading informou que pesquisadores da Zenity encontraram caminhos de ataque em grandes arquiteturas de navegadores agênticos, incluindo produtos conectados à OpenAI, Google, Anthropic, Microsoft e Perplexity. A questão importante deixou de ser se um produto precisa de uma correção. É se a navegação autônoma pode preservar os limites de segurança conhecidos da Web enquanto ainda atua com a autoridade do usuário.

PleaseFix Transforma Conteúdo Rotineiro em Gatilho de Ataque

O PleaseFix desloca a engenharia social de persuadir uma pessoa para redirecionar o agente que já possui a autoridade dessa pessoa.

Ataques ClickFix tradicionais convencem usuários a realizar uma ação insegura, frequentemente copiando um comando ou aprovando um prompt suspeito. O PleaseFix remove esse gargalo humano. Em vez disso, o atacante insere instruções onde um navegador de IA as encontrará durante um fluxo de trabalho normal.

A Zenity divulgou inicialmente o PleaseFix em 3 de março de 2026. Seus pesquisadores demonstraram dois caminhos de exploração envolvendo o Perplexity Comet. Um deles podia usar um convite de calendário para conduzir o agente do navegador a arquivos locais e enviar seu conteúdo para um destino controlado pelo atacante.

O segundo caminho visava fluxos de trabalho de gerenciamento de senhas. Segundo a Zenity, o atacante não precisou explorar diretamente o gerenciador de senhas. O conteúdo malicioso redirecionou o agente do navegador enquanto ele operava dentro de uma sessão autenticada.

A Perplexity corrigiu o problema subjacente no navegador antes da divulgação pública. A Zenity afirmou que a 1Password confirmou que a causa-raiz não estava dentro de seu gerenciador de senhas. Essa distinção importa porque o agente atuou como intermediário autorizado entre sistemas que, de outra forma, eram legítimos.

A categoria técnica é a injeção indireta de prompt. Ela ocorre quando um modelo de IA trata dados não confiáveis como uma instrução, embora o usuário nunca tenha emitido essa instrução. Uma página da web, e-mail, documento ou evento de calendário pode carregar o texto malicioso.

O ataque pode permanecer oculto enquanto o agente conclui a tarefa visível. Um usuário pode pedir a um navegador de IA que aceite um convite ou resuma uma página. O agente pode retornar a resposta esperada enquanto realiza uma ação adicional escolhida pelo atacante.

Michael Bargury, cofundador e CTO da Zenity, descreveu a falha como uma quebra de confiança no agente, e não apenas como um gerenciador de senhas ou site defeituoso. A pesquisa PleaseFix da empresa afirma que a instrução injetada herda qualquer acesso que o usuário tenha concedido ao agente.

Esse acesso herdado muda o impacto. Uma página da web comprometida normalmente opera dentro das restrições do navegador. Um agente comprometido pode navegar entre abas, ler serviços conectados, inserir texto, clicar em controles e invocar outras ferramentas.

Na Black Hat, os pesquisadores ampliaram a descoberta para além das demonstrações originais do Comet. Eles descreveram uma técnica chamada colisão de intenção. Ela evita dizer diretamente a um agente que abandone a solicitação do usuário.

Em vez disso, o conteúdo malicioso fornece uma definição falsa de como a solicitação deve ser concluída. Se o usuário pede para se inscrever em uma newsletter, o ataque pode dizer ao agente que uma ação maliciosa não relacionada faz parte do cadastro.

O agente ainda parece alinhado à tarefa original. Ele simplesmente aceitou um caminho controlado pelo atacante para concluí-la. Isso torna menos eficazes verificações simples de instruções obviamente conflitantes.

A reportagem da Dark Reading de julho afirmou que a Zenity encontrou arquiteturas e garantias de segurança materialmente diferentes entre navegadores agênticos. Ainda assim, os pesquisadores disseram que cada produto expunha alguma rota de ataque. Esse padrão transforma o sequestro zero-click de agentes em um problema de categoria.

Uma única correção pode fechar uma cadeia demonstrada. Ela não elimina a colisão subjacente entre conteúdo não confiável, decisões autônomas e acesso autenticado.

Por Que os Navegadores de IA Colocam os Limites Conhecidos da Web Sob Pressão

Um navegador de IA ganha utilidade ao cruzar limites que os navegadores convencionais passaram décadas impondo.

A política de mesma origem é um desses limites. Em geral, ela impede que conteúdo de um site leia ou manipule conteúdo pertencente a outro. Uma página maliciosa não deveria obter acesso a uma sessão aberta de banco, e-mail ou ambiente de trabalho.

Agentes de navegador complicam esse modelo porque a atividade entre sites faz parte de sua finalidade. Uma tarefa de viagem pode exigir ler um site de reservas, comparar mapas, abrir e-mail, inserir dados de pagamento e atualizar um calendário. O agente precisa de visibilidade mais ampla do que qualquer página da web individual recebe.

Pesquisadores da University of Washington testaram sete navegadores agênticos no início de 2026. Seu estudo sobre mesma origem examinou Brave Leo AI, ChatGPT Atlas, Chrome with Gemini, Claude for Chrome, Microsoft Edge with Copilot, Firefox AI Mode e Perplexity Comet.

A equipe demonstrou um ataque completo de roubo de dados entre origens contra o ChatGPT Atlas no Agent Mode. Os pesquisadores também encontraram condições para ataques relacionados no Chrome with Gemini, Claude for Chrome e Perplexity Comet caso a injeção de prompt fosse bem-sucedida.

Na prova de conceito, um site malicioso incorporava conteúdo de outra origem. Uma instrução injetada orientava o agente a ler esse conteúdo e colocá-lo em um formulário enviado automaticamente. O agente se tornou a ponte que o código comum de navegador estava proibido de criar.

Os pesquisadores não afirmaram que todos os produtos testados sofriam da mesma exploração completa. A descoberta foi mais estrutural. Várias arquiteturas reduziram a eficácia da política de mesma origem à eficácia das defesas contra injeção de prompt.

Essa é uma dependência exigente. A injeção de prompt não é uma assinatura convencional que os defensores possam bloquear com segurança uma vez e esquecer. Atacantes podem reescrever uma instrução, ocultá-la em conteúdo visual, dividi-la entre elementos ou apresentá-la como parte da tarefa.

Uma pessoa pode ignorar texto pouco visível ou metadados inacessíveis da página. Um agente multimodal pode extrair e agir com base nessas informações. A Cloud Security Alliance observa que pesquisadores demonstraram instruções com cores que humanos têm dificuldade de perceber, mas que sistemas de IA ainda conseguem ler.

A memória cria outro problema de limite. Agentes podem condensar atividades anteriores em resumos que influenciam comportamentos posteriores. Se conteúdo hostil alcançar essa memória, sua fonte original pode se tornar menos visível durante decisões futuras.

A LayerX descreveu anteriormente Tainted Memories, um ataque que inseria instruções maliciosas na memória do ChatGPT Atlas. Outras divulgações usaram fragmentos de URL, documentos compartilhados e caminhos de recuperação no lado do servidor para entregar instruções adversariais.

Esses métodos diferem, mas exploram a mesma ambiguidade. O modelo recebe a intenção do usuário e conteúdo externo por canais que não fornecem uma procedência confiável das instruções.

Procedência de instruções significa saber quem forneceu um comando e qual autoridade ele deve ter. Softwares convencionais podem identificar código, entrada, permissões e processos por meio de estruturas técnicas explícitas. Modelos de linguagem frequentemente recebem esses elementos como texto em um contexto compartilhado.

Por isso, navegadores de IA pressionam as equipes de segurança em duas direções. Restringir o acesso reduz os danos, mas também reduz as tarefas que um agente consegue concluir. Expandir o acesso melhora a automação enquanto aumenta as consequências de uma decisão errada.

A equipe da University of Washington observou que o navegador menos arriscado em seus testes também tinha as capacidades mais limitadas. Essa descoberta resume a principal troca. Capacidade e exposição estão sendo ampliadas por muitas das mesmas escolhas de arquitetura.

As Manchetes do Google News Escondem um Problema Mais Profundo de Permissões

A manchete fala sobre prompts maliciosos, mas a falha de segurança maior envolve permissões que persistem depois que o agente interpreta mal uma instrução.

O Google News pode fazer o sequestro zero-click de agentes parecer mais uma história de vulnerabilidade em rápida evolução. Esse enquadramento corre o risco de concentrar a atenção na carga maliciosa engenhosa, em vez da autoridade disponível depois que ela funciona.

Um assistente de IA que apenas resume páginas públicas tem um raio de impacto limitado. Um agente que pode ler e-mails, acessar arquivos locais, usar credenciais armazenadas, enviar mensagens a contatos e fazer compras apresenta um risco diferente.

O ataque não precisa derrotar cada serviço conectado de forma independente. Ele pode manipular o agente que já foi autorizado a usá-los. A autenticação legítima se torna parte da cadeia de ataque.

Isso se assemelha a um deputy confuso, um problema de segurança no qual um componente confiável usa indevidamente sua autoridade em favor de outra parte. O navegador de IA acredita estar atendendo o usuário enquanto um atacante influencia como ele interpreta o objetivo do usuário.

O PleaseFix demonstra esse problema por meio de conteúdo comum. Outras pesquisas o estendem por diferentes canais de entrega. O GeminiJack teria usado documentos compartilhados do Google contendo instruções ocultas. O HashJack inseriu instruções após o símbolo de hash em URLs, uma área que controles de rede podem ignorar.

O ZombieAgent visou o comportamento de recuperação em um agente de pesquisa de IA. O CometJacking usou parâmetros de consulta elaborados e exigia um clique. As variações mostram que os defensores não podem proteger apenas páginas da web enquanto deixam e-mails, documentos, memória e respostas de ferramentas sem tratamento.

O NIST definiu o sequestro de agentes como uma forma de injeção indireta de prompt que leva um agente a perseguir o objetivo de um atacante. Suas avaliações de sequestro enfatizam testar se os agentes concluem objetivos maliciosos ocultos dentro dos recursos que processam.

Essa abordagem de avaliação é importante porque um sistema pode parecer seguro durante tarefas comuns de benchmark. Ele também pode bloquear uma frase conhecida de injeção enquanto permanece vulnerável a uma instrução redigida de outra forma.

A colisão de intenção torna o problema de testes mais difícil. O conteúdo hostil nem sempre contradiz a solicitação do usuário. Ele pode alegar que a etapa maliciosa é necessária para concluir a solicitação.

Uma verificação limitada de alinhamento pode ver uma solicitação de inscrição em newsletter seguida por interações com formulários e concluir que o plano continua relevante. Ela também precisa detectar que uma ação proposta atravessa uma origem, ferramenta ou privilégio não relacionado.

As permissões devem, portanto, estar vinculadas a uma tarefa específica, e não apenas à identidade geral do agente. Um pedido para resumir uma página da web não exige acesso a um gerenciador de senhas. Aceitar um convite de calendário não deve autorizar o envio de arquivos locais.

Permissões de curta duração e delimitadas por tarefa reduziriam o raio de impacto. O mesmo valeria para uma separação explícita entre acesso de leitura e de gravação. Um agente pode inspecionar várias fontes sem receber autoridade para transmitir seu conteúdo a outros lugares.

O mesmo princípio se aplica a implantações empresariais. Um agente de navegador conectado a registros de clientes, documentos internos, repositórios de código e sistemas de mensagens não deve receber um único conjunto indiferenciado de permissões.

As equipes de segurança também precisam ter visibilidade das ações dos agentes. Logs tradicionais podem mostrar uma sessão de usuário autenticado realizando solicitações válidas. Eles podem não mostrar se essas solicitações vieram da pessoa, do planejador do agente ou de conteúdo adversarial.

Isso enfraquece lógicas de detecção conhecidas. Pode não haver senha roubada, executável suspeito ou login não autorizado. A atividade prejudicial pode ocorrer por meio de um navegador aprovado em um dispositivo aprovado.

Para compradores empresariais, a principal questão sobre o produto não é se um navegador inclui filtragem contra injeção de prompt. Os compradores devem perguntar como o sistema delimita a autoridade, registra as fontes das instruções, isola origens e interrompe movimentações inesperadas de dados.

Os Fabricantes de Navegadores Estão Criando Proteções, Mas Nenhuma Elimina a Contrapartida

Defesas em camadas podem interromper caminhos de ataque conhecidos, mas nenhuma arquitetura publicada elimina a tensão subjacente entre autonomia e controle.

O Google identifica abertamente a injeção indireta de prompt como a principal nova ameaça enfrentada por navegadores agênticos. As defesas do Chrome propostas combinam treinamento de modelos, restrições de origem, revisão de ações, detecção de ameaças e confirmações para etapas críticas.

Um componente é o User Alignment Critic. Esse modelo separado revisa uma ação planejada e decide se ela atende ao objetivo declarado pelo usuário. O Google afirma que o crítico recebe metadados da ação sem ver o conteúdo não filtrado da página da web que influenciou o planejador.

Essa separação reduz a chance de que o mesmo texto malicioso contamine tanto o planejador quanto seu revisor. O crítico pode rejeitar uma ação desalinhada ou pedir ao planejador que desenvolva outro plano.

O Google também descreve os Agent Origin Sets. Eles limitam quais sites um agente pode ler e quais pode modificar durante uma tarefa. Uma função de controle confiável decide se uma origem pertence ao fluxo de trabalho solicitado.

O design avança em direção a uma autoridade delimitada por tarefa. No entanto, ainda precisa determinar quais origens são legitimamente relevantes. Um pedido de compras, viagens ou pesquisa pode naturalmente envolver vários sites desconhecidos.

Atacantes podem explorar essa ambiguidade. Uma página maliciosa pode apresentar outro destino como necessário para a conclusão. Falsos positivos também importam, porque bloqueios excessivos tornam o agente menos útil.

A OpenAI também trata a injeção de prompt como um desafio contínuo de segurança. Seu trabalho de segurança do Atlas descreve red teaming contínuo e atualizações de modelos, em vez de uma correção concluída.

A Microsoft adotou uma abordagem cautelosa em relação às ações agênticas no navegador. Suas orientações públicas descrevem restrições ao lançamento de aplicações externas, à inserção de informações sensíveis e a determinadas ações de alto impacto. O acesso experimental também limita a exposição enquanto os designs evoluem.

As confirmações continuam valiosas, especialmente antes de compras, mensagens, transferências de arquivos ou uso de credenciais. No entanto, uma caixa de diálogo de confirmação pode falhar se apresentar o enquadramento do atacante em vez da consequência real.

Os usuários também se condicionam a aprovar prompts frequentes. Uma ferramenta autônoma perde grande parte de seu apelo se cada etapa relevante exigir uma inspeção manual atenta. Um controle que os usuários aceitam rotineiramente oferece proteção limitada.

Os modelos de detecção enfrentam uma corrida adversarial. Pesquisadores podem gerar novas formulações, codificações, imagens e instruções em várias etapas. Um detector treinado com os prompts de ontem pode não identificar uma instrução expressa por contexto e implicação.

Isso não torna as defesas inúteis. Controles em camadas obrigam os atacantes a ultrapassar várias barreiras e limitam os danos quando uma delas falha. O problema é tratar qualquer modelo, política ou aviso isolado como uma fronteira suficiente.

A visão cética também exige cautela. As declarações amplas da Zenity descrevem uma classe de vulnerabilidade e várias demonstrações, não evidências de que todos os usuários de navegadores com IA tenham sido comprometidos. O acesso em provas de conceito não comprova exploração generalizada.

Os produtos também mudam rapidamente. A Perplexity corrigiu o problema no lado do navegador divulgado em março, enquanto outros fornecedores continuam modificando os controles de origem e confirmação. Uma descoberta contra uma versão não deve descrever automaticamente todas as versões posteriores.

Ainda assim, a ausência de exploração em massa conhecida não resolve a preocupação arquitetural. Navegadores com IA atuam em sessões autenticadas de alto valor, e a comunidade de segurança encontrou repetidamente caminhos de conteúdo não confiável para ações privilegiadas.

As empresas devem tratar esses produtos como automação privilegiada, não como software comum de produtividade. As revisões de implantação devem incluir as mesmas disciplinas usadas para contas de serviço, automação robótica de processos e ferramentas administrativas.

Isso significa limitar os serviços conectados, separar sessões pessoais e empresariais, desativar acessos de gravação desnecessários e monitorar ações de saída. Fluxos de trabalho de alto impacto devem manter verificação independente fora da própria interface do agente.

Três Sinais Mostrarão se os Navegadores com IA Estão se Tornando Mais Seguros

O próximo teste é saber se os fornecedores conseguem restringir a autoridade dos agentes sem reduzir a navegação autônoma a uma demonstração supervisionada.

O primeiro sinal é a aplicação de regras de origem específicas por tarefa. Os fabricantes de navegadores precisam demonstrar que os agentes não podem mover informações livremente entre sites não relacionados apenas porque ambos aparecem na mesma sessão.

Pesquisadores independentes devem repetir testes entre origens após grandes lançamentos. Uma defesa bem-sucedida impediria que uma instrução injetada adicionasse um novo destino, lesse conteúdo não relacionado ou enviasse informações sensíveis.

Isso reforçaria o argumento de que navegadores com IA podem preservar os limites centrais da Web. A continuidade de roubos em provas de conceito em produtos atualizados mostraria que os controles de origem ainda dependem demais de decisões falíveis dos modelos.

O segundo sinal é a confirmação independente para ações consequentes. O design mais robusto geraria informações de aprovação a partir de metadados confiáveis da ação, e não da página da web ou da narrativa do planejador.

Uma confirmação útil deve informar quais dados serão movidos, qual destino os receberá e qual conta executará a ação. Ela também deve impedir a escalada silenciosa de uma tarefa somente de leitura para uma operação de gravação.

Pesquisadores testarão se conteúdo malicioso consegue disfarçar, suprimir ou reformular esses avisos. Se as confirmações expuserem consistentemente a consequência real, enfraquecerão ataques de colisão de intenções. Se os usuários continuarem vendo prompts vagos, a proteção permanecerá frágil.

O terceiro sinal é a transparência nos relatórios de incidentes e avaliações. Os fornecedores devem publicar quais classes de ataque testam, quais permissões seus agentes possuem e quais ações sempre exigem aprovação humana.

Somente taxas agregadas de aprovação não serão suficientes. Os testes precisam incluir e-mails realistas, convites de calendário, frames incorporados, documentos, imagens, componentes de URL, entradas de memória e respostas de ferramentas. Eles também devem incluir ataques que sustentem a redação superficial da tarefa do usuário.

A OWASP classifica a injeção de prompt entre os riscos centrais para aplicações de modelos de linguagem. Suas orientações sobre injeção de prompt recomendam restringir o comportamento do modelo, validar resultados, separar conteúdo externo e aplicar o princípio do menor privilégio.

Relatórios públicos podem revelar se esses princípios funcionam em navegadores implantados. Também podem distinguir progresso arquitetural da correção de demonstrações individuais.

Os usuários não precisam abandonar todos os recursos de navegadores com IA enquanto esse trabalho continua. Devem adequar a autoridade do agente à sensibilidade da tarefa.

Resumir pesquisas públicas traz menos risco do que operar em sessões de e-mail, serviços bancários, armazenamento em nuvem ou gerenciamento de senhas. Perfis de navegador separados podem reduzir a exposição, embora não possam corrigir um design de agente inseguro.

As organizações devem começar com contas limitadas e fluxos de trabalho não críticos. Devem impedir que agentes acessem credenciais ou arquivos locais, a menos que uma tarefa específica aprovada exija esse acesso.

As equipes de segurança também devem presumir que o conteúdo pode ser hostil mesmo quando o serviço de hospedagem é confiável. Um documento compartilhado, evento de calendário, anúncio, ticket de suporte ou mensagem interna pode conter instruções controladas por atacantes.

O Google News continuará destacando descobertas individuais à medida que pesquisadores testam novos produtos. Os leitores devem olhar além de cada nome de produto e perguntar se o agente consegue distinguir intenção verificada de conteúdo não confiável.

A evidência decisiva virá de testes independentes repetidos. Um agente atualizado consegue rejeitar conteúdo hostil, permanecer dentro de origens específicas da tarefa e expor cada ação consequente antes da execução?

Até que os fornecedores consigam responder a essas perguntas de forma consistente, o sequestro de agentes sem clique continua sendo mais do que um ciclo temporário de bugs. É o custo de conceder ampla autoridade ao software antes de lhe dar uma forma confiável de reconhecer quem está emitindo o comando.