Privacidade em Agentes de Código IA: 5 Mitos Desmentidos

Dezenas de e-mails de golpe por dia, personalizados com seu nome e sobrenome reais, e a falha não é um banco de dados invadido nem uma lista de marketing vazada. É o cabeçalho User-Agent que seu agente de código com IA anexou a requisições web que você nunca aprovou conscientemente. Foi isso que desenvolvedores descobriram ao rastrear uma onda de spam até o Claude Code, que vinha carimbando o e-mail da conta dos usuários em requisições HTTP de saída durante buscas e acessos a páginas na web. A explicação da própria Anthropic é quase pior que o bug: eles tinham injetado o e-mail da conta no contexto do modelo para que ele pudesse escrever tags @author sensatas, e o modelo, sendo um bot prestativo e cidadão exemplar, passou a fornecê-lo a qualquer site que pedisse um contato. Passei anos auditando o comportamento de rede de ferramentas que rodam em máquinas de desenvolvedores, e esse incidente é um caso didático quase perfeito. Então vamos pegar as cinco crenças que mais ouço sobre privacidade de ferramentas agênticas e testar cada uma contra o que de fato aconteceu.

Mito 1: “Meu agente de código só conversa com a API do provedor do modelo”

Esse é o modelo mental com que quase todo mundo começa: o agente é um cano sofisticado entre seu terminal e os servidores da Anthropic (ou da OpenAI, ou de quem for). Seu código entra, tokens saem, e o único endpoint de rede que importa é api.anthropic.com.

Não é bem assim. Uma CLI agêntica moderna é um cliente HTTP de uso geral que, por acaso, é guiado por um modelo de linguagem. Ela tem uma ferramenta WebFetch que busca URLs arbitrárias. Tem uma ferramenta WebSearch que acessa a infraestrutura de busca. E tem uma ferramenta Bash, o que significa curl, wget, pip install, npm install, git clone e qualquer outro binário com acesso à rede no seu sistema. Quando decide que precisa de documentação, um pacote, um changelog ou um documento da SEC, ele vai buscar, em qualquer lugar onde ache que a coisa está. Cada uma dessas requisições sai do seu endereço IP, da sua rede corporativa, carregando os cabeçalhos que o modelo decidiu escrever naquela manhã.

E o modelo pode ser criativo. Depois que a história do e-mail veio à tona, um engenheiro verificou os próprios logs do servidor web e encontrou requisições de subagentes com strings User-Agent como company-helm-research/1.0 (Claude Code agent run by [name], [company] platform team; docs lookup), com o nome do empregador e o repositório do GitHub em que estavam trabalhando. O agente não estava vazando um valor de configuração; estava compondo cabeçalhos identificadores a partir do contexto, como um estagiário prestativo que assina nome completo, time e projeto em todo e-mail de prospecção. Se quiser entender melhor por que a arquitetura torna isso tão fácil, já escrevemos sobre como as CLIs de código agênticas são construídas. A versão curta é que o loop, o contexto e o conjunto de ferramentas são exatamente tão poderosos quanto precisam ser para causar problemas.

O modelo mental correto: seu agente é um funcionário júnior com um notebook da empresa, uma conexão com a rede corporativa e uma pilha dos seus cartões de visita. Qualquer coisa no contexto dele pode sair do prédio por qualquer ferramenta que ele tenha.

Mito 2: “Colocar um e-mail de contato no User-Agent é só boa etiqueta para bots”

Esse tem um fundo de verdade, e é justamente isso que o torna perigoso. Existe uma convenção genuína de que rastreadores bem-comportados se identificam e fornecem um contato. Alguns serviços a exigem com rigor. A API EDGAR da SEC, por exemplo, rejeita sem rodeios requisições com um User-Agent genérico do curl e exige um contato declarado. Você pode verificar isso sozinho em dez segundos:

U='https://data.sec.gov/api/xbrl/companyconcept/CIK0000320193/us-gaap/Assets.json'
curl -s -o /dev/null -w '%{http_code}  default UA\n' "$U"
# 403  default UA
curl -s -o /dev/null -w '%{http_code}  declared contact\n' \
-A 'Acme Research admin@acme-research.example' "$U"
# 200  declared contact

Então, um modelo que aprendeu que “algumas APIs querem um endereço de contato no User-Agent” não está alucinando. Ele está reconhecendo padrões de uma etiqueta real da internet. E se esse modelo tem o e-mail da sua conta bem ali no contexto, ele tem exatamente um endereço de contato disponível para oferecer. O engenheiro da Anthropic que explicou o incidente disse isso: alguns sites pedem um contato aos agentes, e o Claude às vezes fornecia o e-mail que tinha.

Aqui o mito quebra. A convenção diz que o operador do bot fornece o próprio contato, a entidade que roda o rastreador, para que um sysadmin irritado consiga falar com alguém responsável. O rastreador da Anthropic se identifica como Anthropic. O do Google, como Google. Mas quando seu agente busca uma página, o contato do operador deveria ser a URL de suporte do fornecedor da ferramenta ou um endereço que você configurou deliberadamente, não o e-mail pessoal da conta que você usou para pagar a assinatura. A RFC 9110, sobre o User-Agent, desencoraja explicitamente informações identificadoras desnecessariamente detalhadas, e todo engenheiro de privacidade que conheço trata PII não solicitada em cabeçalhos de requisição como defeito, ponto final. A etiqueta para bots nunca foi feita para desanonimizar o humano por trás do bot.

E o alcance do dano é real, não teórico. Sites de terceiros arbitrários, incluindo os cantos da web infestados de golpes que um agente de busca inevitavelmente acessa, agora têm um endereço de e-mail verificado e associado ao nome de um engenheiro de software em atividade. Isso é uma semente para spear-phishing, entregue embrulhada para presente. Vários desenvolvedores rastrearam uma enxurrada súbita de spam personalizado diretamente a esse comportamento. “Boa cidadania de bot” que faz você ser exposto a spammers não é nem boa nem cidadania.

Mito 3: “Janelas de permissão e o sandbox mantêm minha identidade contida”

Toda ferramenta agêntica vem com algum tipo de UX de consentimento: o agente pergunta antes de executar comandos, mostra quais arquivos está lendo, talvez restrinja o acesso à web com aprovação por domínio. Isso cria uma impressão forte. Um desenvolvedor descreveu como a sensação de que “o LLM só tem acesso a coisas explicitamente adicionadas ao projeto”. Essa impressão é falsa, e o incidente do e-mail prova isso duas vezes.

Primeiro, sistemas de permissão controlam quais ferramentas rodam, não o que o modelo escreve dentro das requisições que essas ferramentas fazem. Aprovar “sim, busque esta URL” não diz nada sobre os cabeçalhos que o modelo compôs para aquela busca. Aprovar uma chamada Bash que roda curl diz ainda menos: a string do comando passa rápido na tela, e ninguém lê a flag -A. Segundo, a UI de permissões opera por ação, enquanto o vazamento é uma propriedade do contexto. Quando o e-mail da sua conta foi injetado no contexto do sistema, algo que os usuários nunca viram nem puderam desativar, ele ficou disponível para toda chamada de ferramenta, todo subagente e todo comando curl, durante toda a sessão. O perímetro do sandbox foi traçado em volta do sistema de arquivos, e o caminho de exfiltração era a própria geração de texto do modelo.

Esta é a parte em que quero ser direto, porque ela vai muito além do bug de um fornecedor: qualquer coisa no contexto de um agente está a uma instrução plausível de distância de sair da sua máquina. Chaves de API, nomes de hosts internos, conteúdo de arquivos, seu nome, seu empregador, seu e-mail. Contenção na camada de ferramentas não ajuda quando o próprio modelo é o canal de exfiltração. Por isso já argumentei que contenção e monitoramento resolvem problemas diferentes para agentes de IA, e você precisa saber qual dos dois está de fato obtendo. Uma caixa de diálogo de permissão é monitoramento vestido de controle. Ela mostra a ação, mas não consegue mostrar a intenção codificada nos parâmetros da ação.

Veredito: o sandbox, do jeito que veio, protegeu seus arquivos. Não fez nada pela sua identidade, porque sua identidade foi entregue ao modelo como matéria-prima.

Mito 4: “É uma configuração, ative a chave e você está seguro”

Quando o problema estourou, a exigência do relator original foi específica: isso não deveria ser uma configuração de opt-out, deveria ser removido do harness por completo. Esse instinto está correto, e a forma como a correção foi de fato aplicada mostra por que configurações são a primitiva errada para esse tipo de problema.

A correção veio em duas partes. Primeiro, um plugin embutido (cc-plugin-privacy, ativado por padrão a partir da v2.1.317) que deterministicamente bloqueia o comportamento: uma verificação rígida, não uma sugestão ao modelo. Segundo, e mais importante, a Anthropic removeu completamente o e-mail da conta do contexto do modelo. Repare na ordem de importância. O plugin é um filtro sobre a saída; remover o e-mail do contexto é remover a capacidade. Um filtro pode falhar. Um modelo que nunca conheceu seu e-mail não consegue vazá-lo, não importa quão criativamente componha cabeçalhos.

Você não consegue sair de uma exposição de dados com prompts. Se o modelo pode ver, o modelo pode emitir. A única redação confiável é a subtração.

Este é um padrão que vejo o tempo todo em ferramentas de agentes, e ele espelha o que já cobrimos em auditoria de clientes de API que funcionam como cofres de credenciais: material sensível é enfiado no lugar mais conveniente (contexto, ambiente, um arquivo de configuração) porque uma funcionalidade precisou dele uma vez, e depois ele vai junto para todo lado. Opções de telemetria e configurações de privacidade tratam do que o fornecedor decidiu coletar. Não dizem nada sobre o que o modelo pode improvisar com o material que recebeu. Configurações servem para preferências. Controles determinísticos e minimização de dados servem para privacidade. Se um fornecedor oferece as primeiras como correção para a segunda, questione.

Mito 5: “O fornecedor corrigiu, então posso parar de me preocupar”

Seja justo: aqui a resposta foi rápida, a explicação de engenharia foi franca e a correção atacou a causa raiz, não o sintoma. Mas “corrigido” é uma afirmação sobre um comportamento específico em uma versão específica. A classe do problema, com ferramentas agênticas emitindo material identificador para endpoints arbitrários, é estrutural, e vai se repetir nesta ferramenta ou em outra. Vários usuários apontaram que esta nem foi a primeira vez que a identidade da conta apareceu sem convite no contexto do Claude Code; foi pelo menos a segunda.

Há ainda uma verdade mais difícil por baixo disso: você não consegue verificar totalmente a ausência de vazamento a partir do cliente. Um usuário diligente rodou um proxy man-in-the-middle contra a versão corrigida e confirmou que nada identificador saiu da máquina dele pela ferramenta WebFetch. Bom trabalho, e o instinto certo. Mas, como ele observou, a identificação também poderia acontecer do lado do servidor: seu cliente envia uma requisição anônima para a API do fornecedor, e a infraestrutura do fornecedor repassa para terceiros com seus dados anexados. Nesse ponto, nenhuma quantidade de inspeção local de pacotes vai enxergar isso. Você volta a depender de confiar no fornecedor, que é exatamente a posição desconfortável que o incidente comprovou.

Então a postura durável não é “patch aplicado, caso encerrado”. É tratar toda ferramenta agêntica como um cliente de rede permanentemente suspeito, que você audita periodicamente, da mesma forma que trataria qualquer software de terceiros com permissões amplas no notebook de um engenheiro. O que nos leva à parte prática.

Como auditar o tráfego de rede do seu agente

Nada disso exige uma equipe de segurança. Uma tarde e algumas ferramentas padrão vão dizer mais sobre o comportamento do seu agente do que qualquer política de privacidade.

1. Intercepte o tráfego. Aponte o agente para o mitmproxy e deixe-o rodar uma sessão de trabalho real. CLIs baseadas em Node geralmente respeitam as variáveis de ambiente de proxy depois que confiam na sua CA:

mitmdump --listen-port 8080 -w agent-flows.mitm &
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS=~/.mitmproxy/mitmproxy-ca-cert.pem
# Now run your agent and do normal work.
# Afterwards, search every captured request for your identifiers:
mitmdump -nr agent-flows.mitm \
--flows \
| grep -iE 'you@company\.com|YourName|your-org'

Procure por mais do que seu e-mail: seu nome, seu empregador, o slug da organização no GitHub, hostnames internos, nomes de repositórios. Lembre dos logs dos subagentes. O modelo estava compondo identificadores, não apenas repetindo-os, então pesquise por fragmentos.

2. Verifique os logs da sua própria infraestrutura. Se você opera serviços web, procure nos logs de acesso por strings de User-Agent de agentes. Foi assim que os cabeçalhos compostos do Mito 1 foram descobertos. Isso não custa nada e costuma revelar tráfego de subagentes que a captura local não pega.

3. Restrinja o egress. O controle mais forte é tornar categorias inteiras de vazamento impossíveis. Rode o agente dentro de um container ou VM cuja política de rede permita apenas os endpoints de que ele legitimamente precisa: a API do modelo, seus registries de pacotes, talvez o GitHub. Com Docker, isso significa uma rede customizada mais um firewall de egress; no Mac, Little Snitch ou Lulu oferecem regras por processo. Se o agente não consegue alcançar sites arbitrários a partir do sandbox, também não consegue entregar sua identidade a sites arbitrários. Ele vai precisar pedir que você busque as coisas, o que é atrito, mas o atrito é justamente o objetivo.

4. Minimize o que a ferramenta sabe. Use um e-mail dedicado e de baixo valor para contas de ferramentas, nunca o seu endereço principal de trabalho. Remova detalhes identificadores de arquivos de configuração globais que o agente lê (~/.gitconfig é um comum que agentes puxam). Se a ferramenta permitir, rode-a sob um usuário separado do sistema operacional, com seu próprio diretório home. Subtração vence filtragem, sempre.

5. No nível da organização, passe por um proxy gerenciado. Se sua empresa fornece ferramentas agênticas para engenheiros, force o tráfego delas por um proxy de egress com logging e adicione inspeção de cabeçalhos ao pipeline. Só os logs de consultas DNS teriam pego o padrão de um agente se espalhando por centenas de domínios incomuns. É a mesma postura que você aplicaria a qualquer runner de CI ou máquina de build, e esse é exatamente o enquadramento certo: um agente é infraestrutura de build com opiniões próprias.

O bug do e-mail no User-Agent será esquecido em um mês, absorvido pela rotatividade das notas de versão. A lição não deveria ser. Ferramentas agênticas de código são o software mais privilegiado, mais ativo na rede e menos auditado que a maioria de nós roda, e elas improvisam. Trate-as de acordo: presuma que tudo no contexto delas é público, verifique o que realmente vai para a rede e construa a gaiola antes de precisar dela, não depois que o spam chegar endereçado a você pelo nome.