Quando ler uma página também permite agir

Um assistente que resume um artigo só precisa de interpretar o conteúdo. Um agente de navegador pode ir mais longe: ler páginas, navegar entre sites e, consoante as permissões, clicar ou escrever numa sessão em que a pessoa já iniciou sessão. Esta diferença alarga aquilo que pode fazer em nome de alguém, mas também aumenta as consequências de um erro. O Google assinala que os agentes podem operar em sessões autenticadas e que uma ação indesejada pode incluir uma transação ou a exposição de dados sensíveis. https://developer.chrome.com/docs/agents/security https://blog.google/security/architecting-security-for-agentic/

Por isso, a questão não é apenas se o modelo responde bem a uma pergunta, mas que conteúdo vê, que ações está autorizado a executar e quem verifica se cada passo corresponde ao objetivo da pessoa. A fronteira entre ler e agir é essencial: resumir uma avaliação tem um impacto diferente de enviar uma mensagem, iniciar sessão ou concluir um pagamento. A documentação do Chrome apresenta as suas medidas como defesas em camadas, não como uma propriedade mágica do modelo que torne inofensivo qualquer texto da Web. https://blog.google/security/architecting-security-for-agentic/

Uma página pode conter instruções dirigidas ao agente

A injeção indireta de instruções ocorre quando uma ordem dirigida ao modelo aparece nos dados que este consulta, em vez de chegar diretamente da pessoa. Pode estar numa página manipulada, em conteúdo de terceiros incorporado ou em contribuições de utilizadores, como comentários e avaliações. O Google descreve dois riscos concretos para ferramentas Web: definições de ferramentas com instruções ocultas e respostas aparentemente normais que incorporam texto hostil. https://developer.chrome.com/docs/agents/security https://blog.google/security/architecting-security-for-agentic/

O problema é que o modelo processa texto de várias fontes enquanto tenta cumprir uma tarefa. Se confundir o conteúdo de uma página com uma ordem legítima, pode desviar-se do objetivo original. O site não precisa de ter autoridade sobre o agente; basta que o texto influencie o planeamento. O Google avisa explicitamente que a natureza probabilística dos modelos impede garantir a segurança apenas dentro do próprio modelo. Por isso, mesmo uma instrução escondida ou misturada com informação útil deve ser tratada como conteúdo não fiável, e não como uma autorização do utilizador. https://developer.chrome.com/docs/agents/security

A investigação ilustra a dimensão desta superfície de ataque, embora os seus resultados não devam ser automaticamente generalizados a todos os navegadores. Um estudo publicado como pré-publicação no arXiv em maio de 2025 analisou, em modo white-box, um projeto de navegação de código aberto e reportou injeção de instruções, contorno da validação de domínios e exposição de credenciais. Trata-se da análise de um projeto e de uma configuração específicos: é evidência de que as falhas são possíveis, não uma medição universal dos agentes atuais nem uma prova sobre o Chrome. https://arxiv.org/abs/2505.13076

Camadas que reduzem a margem para abusos

O guia do Chrome para agentes que utilizam WebMCP recomenda várias barreiras determinísticas: limitar o volume de entrada, restringir as origens Web com as quais o agente pode interagir e pedir confirmação antes de agir. Também aconselha a tratar as respostas das ferramentas como dados não fiáveis. A lógica é reduzir tanto o material hostil que entra no contexto como os caminhos disponíveis para que uma instrução manipuladora cause danos. São recomendações de conceção para quem desenvolve agentes, não uma garantia de que qualquer extensão ou navegador as aplique automaticamente. https://developer.chrome.com/docs/agents/security

Outra técnica descrita é o spotlighting: assinalar ou transformar conteúdo não fiável para que o modelo o interprete como dados, e não como ordens. O Chrome alerta para os compromissos envolvidos nas opções. Delimitar texto tem baixo custo, mas pode falhar se os delimitadores forem manipulados; codificá-lo em Base64 dificulta certos truques estruturais, embora consuma mais contexto. Em ambos os casos, o sistema tem de explicar ao modelo como deve tratar esse conteúdo. São medidas complementares, não um filtro infalível que consiga reconhecer todas as intenções maliciosas. https://developer.chrome.com/docs/agents/security

O Google descreve também uma arquitetura para as capacidades agentivas do Chrome: um modelo planeador propõe ações e um componente separado, denominado User Alignment Critic, verifica se estas correspondem ao objetivo do utilizador. A empresa afirma que esse crítico recebe metadados das ações, e não conteúdo Web sem filtragem, e que pode rejeitar propostas. Além disso, os conjuntos de origens procuram limitar os sites que o agente pode ler e aqueles em que pode agir. A publicação indica que a primeira implementação dessa limitação era mais simples e que o desenho continuaria a ser aperfeiçoado. https://blog.google/security/architecting-security-for-agentic/

Confirmações e limites declarados

A confirmação humana pode funcionar como travão quando uma ação pode ter consequências. O Google diz que o seu agente do Chrome pede autorização antes de determinados sites sensíveis, antes de iniciar sessão através do Google Password Manager e antes de ações como compras, pagamentos ou envio de mensagens. Menciona também um registo de passos e a possibilidade de pausar ou parar a tarefa. Estas são funcionalidades descritas pelo fornecedor; isso não significa que estejam todas disponíveis em qualquer região, versão ou produto, nem que a pessoa tenha de aprovar todos os detalhes da mesma forma. https://blog.google/security/architecting-security-for-agentic/

A própria documentação reconhece limitações: os classificadores podem não detetar todo o conteúdo concebido para influenciar o agente, e as defesas precisam de testes e melhorias contínuos. O Google explica que recorre a exercícios automatizados de red team para gerar sites de teste e observar se as proteções travam os ataques. Esta avaliação ajuda a detetar regressões, mas uma taxa de sucesso medida num conjunto de testes não prova a ausência de vulnerabilidades futuras nem abrange todas as páginas, idiomas, fluxos de trabalho e combinações de ferramentas. A conclusão prudente é que as camadas aumentam o custo do ataque e podem conter o impacto, não que o tornem impossível. https://blog.google/security/architecting-security-for-agentic/

O que a pessoa utilizadora pode fazer

Antes de delegar uma tarefa, convém verificar que permissões o navegador ou a extensão solicita e limitar o acesso aos sites de que a tarefa realmente precisa. Se uma funcionalidade puder enviar dados, alterar uma conta ou fazer uma compra, é razoável manter a supervisão e confirmar o destinatário, os campos e o resultado antes de aprovar. O guia do Chrome recomenda limitar as origens e pedir confirmação para as ações; não se trata de transferir toda a responsabilidade para a pessoa, mas de manter um ponto de controlo sobre efeitos difíceis de reverter. https://developer.chrome.com/docs/agents/security

Também ajuda separar tarefas de baixo impacto — por exemplo, organizar informação pública — de operações que envolvam credenciais, dados médicos, informação financeira ou mensagens privadas. Se um agente encontrar uma instrução inesperada numa página, não se deve presumir que faz parte do pedido original. É preferível parar e rever a ação proposta. A supervisão reduz a exposição, mas não substitui os controlos técnicos: as orientações oficiais insistem nas restrições de origem, na avaliação periódica e nas confirmações, enquanto a investigação disponível mostra que podem surgir falhas em diferentes componentes do sistema. Não há fundamento para prometer proteção absoluta. https://developer.chrome.com/docs/agents/security https://arxiv.org/abs/2505.13076