Olá a todos!
Disclaimer habitual antes de começar: sou utilizador do Claude. Uso o Claude Code regularmente, já escrevi sobre ele aqui no blog várias vezes, e considero-o genuinamente uma das ferramentas mais úteis que tenho no meu arsenal técnico. Portanto não estou aqui a fazer um peditório para cancelarem as vossas contas nem a pregar que a Anthropic é o mal encarnado. Mas há coisas que não se podem ignorar, e isto é uma delas.
A 18 de abril de 2026, Alexander Hanff — que mantém o blogue That Privacy Guy e é uma das vozes mais sérias em privacidade e conformidade legal na Europa — publicou um artigo técnico detalhado que merece muito mais atenção do que está a receber. O título é direto ao assunto: “Anthropic secretly installs spyware when you install Claude Desktop”.
Vamos a isso.
O que é que ele encontrou, exatamente?
Hanff estava a fazer debugging a um Native Messaging helper num projeto pessoal e precisava de ver o que o Brave Browser tinha registado no seu laptop. E encontrou um ficheiro que não tinha instalado, não tinha autorizado, e sobre o qual nunca lhe tinham dito nada. O ficheiro estava neste caminho:
~/Library/Application Support/BraveSoftware/Brave-Browser/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
O conteúdo do ficheiro:
{
"name": "com.anthropic.claude_browser_extension",
"description": "Claude Browser Extension Native Host",
"path": "/Applications/Claude.app/Contents/Helpers/chrome-native-host",
"type": "stdio",
"allowed_origins": [
"chrome-extension://dihbgbndebgnbjfmelmegjepbnkhlgni/",
"chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/",
"chrome-extension://dngcpimnedloihjnnfngkgjoidhnaolf/"
]
}
Para quem não está familiarizado com o conceito: isto é um Native Messaging manifest. É o documento que um browser baseado em Chromium consulta quando uma extensão quer chamar um executável na máquina local. Os Native Messaging hosts correm fora da sandbox do browser, ao mesmo nível de privilégio que o utilizador. Ou seja, se uma extensão com um dos três IDs listados acima chegar ao Brave, o Brave fica pré-autorizado a correr o binário em /Applications/Claude.app/Contents/Helpers/chrome-native-host — na tua máquina, com as tuas permissões.
O único software que poderia ter escrito este ficheiro era o Claude Desktop. A única coisa que Hanff tinha instalado da Anthropic nessa máquina.
O Claude Desktop entrou no Brave — um browser de um vendor completamente diferente — e registou uma backdoor para uma extensão que ele nunca instalou.
Mas espera, só é Brave?
Não. Longe disso.
Quando Hanff reproduziu o problema numa segunda máquina e fez um scan completo, o resultado foi este:
~/Library/Application Support/Arc/User Data/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
~/Library/Application Support/BraveSoftware/Brave-Browser/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
~/Library/Application Support/Chromium/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
~/Library/Application Support/Microsoft Edge/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
~/Library/Application Support/Vivaldi/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
~/Library/Application Support/com.operasoftware.Opera/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
Sete ficheiros. Um para cada path de browser baseado em Chromium que a Anthropic conhece. E todos com o mesmo hash MD5 — byte a byte idênticos.
O detalhe que me faz levantar a sobrancelha: nessa segunda máquina, apenas o Brave e o Chrome estavam instalados. O Edge, o Arc, o Vivaldi, o Chromium e o Opera não estavam presentes em /Applications. Mas o Claude Desktop criou na mesma as pastas NativeMessagingHosts para esses quatro browsers — e colocou lá os manifestos. Se algum dia instalares qualquer um desses browsers no futuro, a bridge já está lá. Pré-autorizada. Desde o primeiro arranque do Claude Desktop.
Isto não é um bug. É uma decisão de design.
O que é que esta bridge faz quando é ativada?
Aqui é que a coisa fica séria.
Em repouso, a bridge não faz nada. O binário não corre até que uma extensão com um dos três IDs listados o invoque. A Anthropic vai usar exatamente este argumento para se defender. Mas deixem-me cortar isso pela raiz.
A própria documentação da Anthropic descreve as capacidades desta bridge quando está ativa:
“Claude opens new tabs for browser tasks and shares your browser’s login state, so it can access any site you’re already signed into.”
“Live debugging: read console errors and DOM state directly, then fix the code that caused them.”
“Data extraction: pull structured information from web pages and save it locally.”
“Task automation: automate repetitive browser tasks like data entry, form filling, or multi-site workflows.”
“Session recording: record browser interactions as GIFs to document or share what happened.”
Vou traduzir o que isto significa na prática: se tens o teu banco aberto numa tab, as capacidades documentadas desta bridge incluem lê-lo como se fosses tu. Se tens o portal de saúde, o Slack da tua empresa, ou a consola de administração da tua infraestrutura de produção, as capacidades documentadas incluem agir como tu nesses serviços.
Sem re-login. Sem prompt extra. Sem que percebas que está a acontecer.
E o binário corre fora da sandbox do browser, ao nível de privilégio do utilizador. Os Native Messaging hosts não aparecem em nenhum UI standard do macOS nem nos processos visíveis do browser — são invocados pelo browser e comunicam via stdio.
O log do próprio Claude Desktop confessa tudo
Uma das partes mais reveladoras do artigo de Hanff é que o Claude Desktop guarda o seu próprio log em ~/Library/Logs/Claude/main.log, e esse log regista abertamente a instalação, usando o nome interno Chrome Extension MCP:
2026-03-21 14:54:39 [info] App is installed, enabling initial check and auto-updates
2026-03-21 14:54:40 [info] [Chrome Extension MCP] Installed native host manifest for Chrome at ...
2026-03-21 14:54:40 [info] [Chrome Extension MCP] Installed native host manifest for Brave at ...
2026-03-21 14:54:40 [info] [Chrome Extension MCP] Installed native host manifest for Edge at ...
2026-03-21 14:54:40 [info] [Chrome Extension MCP] Installed native host manifest for Chromium at ...
2026-03-21 14:54:40 [info] [Chrome Extension MCP] Installed native host manifest for Arc at ...
2026-03-21 14:54:40 [info] [Chrome Extension MCP] Installed native host manifest for Vivaldi at ...
2026-03-21 14:54:40 [info] [Chrome Extension MCP] Installed native host manifest for Opera at ...
2026-03-21 14:54:40 [info] [Chrome Extension MCP] Native host installation complete
E há mais: contando todos os eventos de instalação nos logs do Claude Desktop, Hanff encontrou 31 eventos separados de Native host installation complete. Trinta e um. O que significa que o Claude Desktop não instala isto uma vez — reinstala a cada arranque. Os timestamps de modificação dos ficheiros confirmam que foram reescritos meses depois da criação inicial.
Se apagares o ficheiro manualmente, ele volta a aparecer na próxima vez que o Claude Desktop arrancar. É persistente por design.
Mas a Anthropic não disse que isto só funciona com Chrome e Edge?
Sim. E é aqui que a incongruência fica ainda mais difícil de explicar.
A documentação pública da Anthropic para o Claude Code afirma explicitamente:
“Chrome integration is in beta and currently works with Google Chrome and Microsoft Edge. It is not yet supported on Brave, Arc, or other Chromium-based browsers.”
Mas o log do Claude Desktop mostra instalações no Brave, Arc, Chromium, Vivaldi, e Opera — para além do Chrome e Edge. A posição documentada e o comportamento real do software divergem completamente.
Isto é particularmente relevante para quem usa o Brave por razões de segurança. Escolheste um browser com um modelo de segurança diferente, com proteções adicionais. E a Anthropic registou silenciosamente uma bridge out-of-sandbox dentro do Brave sem o conhecimento do Brave, sem o teu conhecimento, e sem suporte documentado para esse browser.
O problema legal: Artigo 5(3) da Diretiva ePrivacy
Hanff é especialista em conformidade legal na área da privacidade, e a sua análise legal é contundente.
O Artigo 5(3) da Diretiva 2002/58/EC — a Diretiva ePrivacy — é muito claro: o armazenamento de informação, ou o acesso a informação já armazenada, no equipamento terminal de um utilizador final é apenas permitido sob a condição de que o utilizador final em questão tenha dado o seu consentimento. Consentimento esse que tem de ser informado e prévio.
A Anthropic não pediu consentimento. Não informou. Não apresentou uma caixa de diálogo. Não teve um ecrã de configuração. Simplesmente instalou.
E isto não é só um problema de RGPD ou de boas práticas — é potencialmente uma violação direta de leis de acesso e uso indevido de computadores, que em muitas jurisdições europeias têm carácter criminal. A escala aqui importa: isto não é um utilizador. É potencialmente milhões de instalações do Claude Desktop em todo o mundo.
Os dark-side patterns identificados
O artigo de Hanff lista onze dark patterns distintos nesta implementação. Vou destacar os que me parecem mais graves:
Bundling forçado através de fronteiras de confiança. Instalei o Claude Desktop. Não instalei nada no Brave. Mas o Claude Desktop, uma aplicação da Anthropic, atravessou a fronteira de confiança entre dois vendors independentes e escreveu configuração na pasta de aplicação do Brave.
Default invisível, sem opt-in. Durante a instalação do Claude Desktop, no primeiro arranque, no uso normal — em nenhum momento apareceu uma caixa de diálogo a perguntar “Queres que o Claude registe uma bridge de integração com o browser?”. Nenhuma checkbox. Nenhum ecrã de consentimento.
Pré-autorização de software que o utilizador não instalou. O manifesto pré-autoriza três IDs de extensões Chrome. Tenho zero dessas extensões instaladas. Mas as três estão agora na whitelist para correr um helper out-of-sandbox na minha máquina.
Registo em browsers que não estão instalados. O Claude Desktop criou pastas e colocou manifestos em paths de browsers que não existem no sistema. Se algum dia instalares esses browsers, a bridge já está lá.
Re-instalação automática a cada arranque. Apagar o ficheiro não chega. O Claude Desktop reinstala a cada run. Isto torna a remoção permanente impossível sem desinstalar o Claude Desktop completo.
Nomeação genérica que obscurece o scope. O ficheiro chama-se com.anthropic.claude_browser_extension. Um utilizador que audite o seu sistema vê “uma integração do Claude” e assume que é inofensivo. Não pensa “isto dá acesso out-of-sandbox ao meu browser, a todas as minhas sessões autenticadas, para leitura de DOM e preenchimento de formulários”.
O vetor de ataque que ninguém está a mencionar
Há uma dimensão desta história que me preocupa especialmente e que não está a receber atenção suficiente.
A Anthropic publicou os seus próprios dados de segurança para o Claude for Chrome, e esses dados dizem que a taxa de sucesso de ataques de prompt injection é de 23,6% sem mitigações e 11,2% com as mitigações atuais. Um em cada quatro ataques tem sucesso antes de qualquer proteção. Um em cada nove tem sucesso mesmo com as proteções em vigor.
Agora combina isto com o facto de que o Claude Desktop pré-instalou a bridge em potencialmente todos os utilizadores que alguma vez correram o Claude.app — incluindo muitos que nunca instalaram nem pretendem instalar o Claude for Chrome. A bridge está lá. Dormida. À espera.
Se qualquer das três extensões pré-autorizadas for comprometida — por um takeover de conta na Anthropic, por uma atualização maliciosa na Chrome Web Store, por uma política de enterprise sideload, ou por uma pipeline de build comprometida — o atacante tem acesso out-of-sandbox na máquina da vítima sem precisar de nenhum passo adicional. A pré-registo eliminou a barreira que normalmente existiria.
E mesmo sem comprometimento externo: um ataque de prompt injection bem-sucedido contra o Claude for Chrome, através da bridge pré-instalada, tem agora um caminho direto para um helper a correr ao nível de privilégio do utilizador, fora da sandbox do browser.
O que a Anthropic devia ter feito
E não é que seja difícil. São práticas standard de software de desktop em 2026.
O mais básico: perguntar. No primeiro arranque do Claude Desktop, um diálogo simples: “Queres que o Claude se integre com o teu browser? Isto instala uma bridge de integração. Configura agora, ou salta — podes ativar mais tarde nas definições.” Três frases. Dois botões. Feito.
Melhor ainda: instalar o manifesto apenas como consequência do utilizador instalar afirmativamente a extensão do browser. O clique de instalação na Chrome Web Store já é o evento de consentimento. Deixá-lo fazer o seu trabalho, sem antecipar semanas antes no lado do desktop.
Se instalares com consentimento, instala apenas no browser para o qual estás a consentir. Não faças um registo em massa em todos os browsers Chromium que encontras no sistema. Não registes em browsers que não estão sequer instalados.
E surfacing básico: nas definições do Claude.app, lista todas as integrações de sistema atualmente registadas. Bridges de browser. Login items. Launch agents. Deixa o utilizador revogar cada uma de forma persistente.
A contradição central
Há algo que me incomoda especialmente nesta história, e é o contexto em que acontece.
A Anthropic é a empresa de IA que mais investe publicamente na narrativa de “segurança em primeiro lugar”. É a empresa que publicou a Constitutional AI. Que tem um documento de “Model Spec” sobre valores e segurança. Que se posiciona consistentemente como a alternativa responsável num mercado de IA que corre demasiado depressa.
E é esta empresa que, silenciosamente, sem pedir consentimento, instalou uma capability de acesso autenticado a sessões de browser — com acesso a DOM, preenchimento de formulários, e extração de dados — em potencialmente milhões de máquinas de utilizadores. Em browsers que não suporta oficialmente. Criando pastas para browsers que nem sequer estão instalados. Reinstalando a cada arranque para garantir persistência.
A incongruência entre o discurso público e o comportamento técnico real é demasiado grande para ser ignorada.
Como Hanff escreve no artigo original: “Uma empresa não pode credível afirmar que suporta direitos humanos… e no próximo momento minar os direitos fundamentais à privacidade e proteção de dados.”
O que fazer se tens o Claude Desktop instalado
Se tens o Claude Desktop instalado num Mac, podes verificar se tens estes ficheiros com:
find ~/Library/Application\ Support -name "com.anthropic.claude_browser_extension*"
Se o resultado mostrar ficheiros, eles foram instalados sem o teu conhecimento ou consentimento.
Para os remover permanentemente a única solução atual é desinstalar o Claude Desktop. Apagar os ficheiros individualmente não chega — o Claude Desktop reinstala-os no próximo arranque.
Se quiseres verificar o que está no log do próprio Claude Desktop:
grep "Chrome Extension MCP" ~/Library/Logs/Claude/main.log
Vais ver, a preto e branco, o histórico de todas as instalações.
Não sei se isto vai resultar numa ação legal, numa investigação de uma autoridade de proteção de dados europeia, ou simplesmente numa atualização silenciosa do Claude Desktop que remove ou gata este comportamento atrás de um opt-in adequado. Provavelmente a Anthropic vai corrigir rapidamente e fazer um “na verdade era uma funcionalidade em desenvolvimento” e seguir em frente.
Mas o que aconteceu é documentável, verificável, e grave. Um software instalou silenciosamente, sem consentimento, em potencialmente milhões de máquinas, uma ponte de acesso a browsers com capacidades documentadas de leitura de sessões autenticadas, DOM e formulários. Reinstala-se a cada arranque. Instala-se em browsers não suportados e em browsers não instalados.
Merece mais do que uma nota de rodapé numa atualização de changelog.
O artigo completo do Alexander Hanff, com toda a auditoria técnica detalhada, está em thatprivacyguy.com/blog/anthropic-spyware. Recomendo a leitura.
Até à próxima.
Nuno Higgs