Telemetria de coding agents: o que é enviado

O que a telemetria de coding agents realmente abrange

A telemetria de coding agents consiste em quatro fluxos de dados diferentes que partilham o mesmo nome, e cada fluxo tem o seu próprio controlo. A inferência do modelo transporta os seus prompts e o seu código para quem fornece o modelo, e nenhuma definição desativa esse fluxo. As análises de utilização do produto e os relatórios de falhas são enviados para o fornecedor e, muitas vezes, para uma empresa de logging contratada pelo fornecedor. A retenção para treino é uma questão contratual, não uma questão de rede. O quarto fluxo é aquele que costuma passar despercebido: cada integração que adiciona pode abrir uma ligação para um host que nunca escolheu.

Uma lista das predefinições atuais dos fornecedores é a parte deste tema que fica desatualizada mais rapidamente. Uma release pode alterar uma predefinição, e uma nova funcionalidade pode adicionar um destino que nenhum switch existente controla. Por isso, a competência duradoura é uma auditoria que possa repetir com qualquer agent: leia o que o fornecedor documenta, confirme qual configuração foi efetivamente aplicada nesta máquina, monitorize o processo a partir da própria máquina e escolha os controlos pelos quais está disposto a pagar. Cada comando abaixo é executado na sua própria máquina, sobre o seu próprio tráfego.

As quatro categorias e por que precisam de controlos diferentes

O tráfego de inferência do modelo é inevitável. O agente envia o seu prompt, os ficheiros que leu, a saída dos comandos que executou e o texto que gerou para um endpoint de modelo. É assim que o produto funciona. A única decisão real é quem o recebe: uma API operada por outra entidade ou um modelo que executa localmente. Uma conta cloud empresarial (Bedrock, Vertex, Foundry) muda o recetor, mas não elimina o fluxo. Nada no restante deste artigo reduz o tráfego de inferência, por isso mantenha-o separado, na sua análise, das outras três categorias.

As análises do produto e os relatórios de falhas são um fluxo diferente para hosts diferentes. Contadores de utilização, valores de latência, consultas de feature flags e stack traces são normalmente enviados para hostnames sem relação com a API do modelo e, muitas vezes, para um sistema de acompanhamento de erros de terceiros. Os fornecedores costumam documentar estes dados como "métricas" e "relatórios de erros" e normalmente disponibilizam uma variável de ambiente por categoria. O volume é reduzido, por isso as contagens de bytes nunca os irão detetar. O objetivo é identificar hostnames, não largura de banda.

A retenção e o treino são questões de política, não de pacotes. O facto de o fornecedor conservar os seus prompts, durante quanto tempo os conserva e se os utiliza para treinar um modelo futuro está definido nos termos associados ao seu plano. Os planos para consumidores e os planos comerciais costumam ser diferentes, e um acordo de retenção zero é normalmente um contrato separado. Não pode verificar nada disto com tcpdump, porque os pacotes têm o mesmo aspeto em qualquer dos casos. Leia os termos e, se isto for relevante para a sua entidade empregadora, obtenha essa garantia por escrito.

As integrações acrescentam discretamente um salto. Um servidor MCP (model context protocol), um marketplace de plugins, uma verificação de atualização automática, uma ferramenta de pesquisa na Web ou uma verificação de segurança que resolve um URL antes de o obter: cada um representa um pedido para um host que não é o endpoint do modelo. É aqui que surgem as surpresas, porque um harness pode encaminhar através do seu próprio serviço um trabalho que presumiu ser local, e uma release pode começar a fazê-lo sem alterar uma única linha da sua configuração. Trate cada ferramenta adicionada como um novo destino até a ter monitorizado na rede.

Etapa 1: o que a documentação do fornecedor informa?

Abra a referência das definições e a página de utilização de dados do seu agente e leia-as com uma lista de termos à mão: métricas, análise, relatórios de erros, falhas, feedback, questionários, verificação de atualizações, verificação de segurança, marketplace. Cada um desses termos costuma corresponder a um interruptor separado. Anote os nomes exatos das variáveis, porque a etapa 2 procura por eles com grep.

Um termo pode induzi-lo em erro. Em vários agentes, "telemetry" na documentação significa uma exportação OpenTelemetry que configura para enviar métricas para um coletor que gere, o que é o oposto de enviar dados para o fornecedor. O Claude Code é um desses casos: definir CLAUDE_CODE_ENABLE_TELEMETRY=1 inicia uma exportação para o endpoint indicado em OTEL_EXPORTER_OTLP_ENDPOINT e não tem relação com a própria análise do fornecedor, que tem uma opção de exclusão diferente. Determine a direção do fluxo de dados antes de definir qualquer opção.

Conte com um interruptor principal, mas também com lacunas na cobertura. Em agosto de 2026, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC do Claude Code desativa em conjunto as métricas, os relatórios de erros, o comando de feedback e os questionários de sessão. A mesma documentação informa que essa opção não abrange a verificação de segurança do domínio do WebFetch, que envia o hostname que está prestes a consultar para a API do fornecedor e tem uma definição separada. Isto não é uma crítica a um produto específico. Este é o padrão do problema em geral: um interruptor principal abrange as categorias que existiam quando a documentação foi escrita.

Conte também com algum custo ao optar pela exclusão. A mesma documentação informa que desativar a telemetria também desativa a avaliação de feature flags de que algumas funcionalidades dependem. Assim, uma opção alterada por motivos de privacidade pode desativar uma funcionalidade que utiliza, sem uma mensagem de erro que relacione os dois factos. Leia a frase junto da opção, não apenas o nome da opção.

Passo 2: qual configuração foi realmente aplicada?

Uma configuração que você escreveu não é necessariamente uma configuração que foi aplicada. Os agentes mesclam configurações de vários arquivos, e um deles fica dentro do repositório que você acabou de clonar de outra pessoa. Comece pelo ambiente do seu próprio shell.

env | grep -Ei 'telemetry|otel|analytics|error_report|do_not_track|proxy'

Em seguida, mostre todos os arquivos de configuração que a ferramenta lê, na ordem indicada pela documentação. No Claude Code, em agosto de 2026, são o arquivo do usuário, os dois arquivos do projeto e um diretório de políticas gerenciadas no Linux.

for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json; do
  echo "== $f"; [ -f "$f" ] && cat "$f"
done
ls -l /etc/claude-code/ 2>/dev/null

Um arquivo de projeto que veio com um git clone contém uma configuração escrita por outra pessoa e pode reativar algo que o seu arquivo de usuário desativou. Se o agente tiver um comando de status que liste as fontes carregadas, essa será a verificação mais confiável: o Claude Code mostra as fontes de configuração carregadas em /status.

A verificação mais consistente consulta o processo em execução, e não um arquivo. Primeiro, atribua ao agente a sua própria conta de usuário Linux. Isso torna todos os comandos desta publicação mais curtos. Depois, leia o ambiente com o qual o processo foi iniciado.

pgrep -u agent -a node
sudo tr '\0' '\n' < /proc/$(pgrep -u agent -n node)/environ | grep -Ei 'telemetry|proxy|otel'

/proc/<pid>/environ mostra as variáveis que o processo tinha no momento da execução. Assim, identifica o caso em que a exportação de .bashrc não chegou a um serviço iniciado pelo systemd. Se uma variável que você definiu não aparecer aqui, ela nunca esteve em vigor, independentemente do que os seus arquivos de configuração do shell indiquem.

Etapa 3: a que hosts se liga?

Comece pelos sockets abertos, filtrados pela conta com que o agente é executado.

sudo ss -tnpe state established

-e adiciona um campo uid: a cada linha, para poder separar as ligações do agente das do seu browser sem analisar os nomes dos processos. Anote os endereços remotos e, em seguida, obtenha os nomes associados. A fonte mais fiável é o handshake TLS (transport layer security), porque cada nova ligação começa com um ClientHello que contém um campo SNI (server name indication), ou seja, o nome de host solicitado pelo cliente.

sudo apt install -y tshark
sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

Obtém uma linha por cada nova ligação. É exatamente o inventário pretendido: a API do modelo, o servidor de atualizações, o host de analytics, o sistema de acompanhamento de erros e tudo o que uma integração tenha adicionado. Uma coluna de nome vazia significa que o cliente utilizou ECH (encrypted client hello). Nesse caso, o nome do host não é visível na rede. Use o endereço IP de destino, uma resolução inversa ou o proxy da etapa 4.

A perspetiva do DNS (domain name system) é uma verificação cruzada útil, porque mostra os nomes que o agente consultou, mesmo para ligações que não concluiu.

sudo tcpdump -ni any -l 'udp port 53'

Cada linha de consulta termina com o tipo de registo e o nome, no formato A? host.example.net. (39). Capture em any em vez da interface externa, porque, com systemd-resolved, a aplicação comunica com um listener stub local em 127.0.0.53 e apenas o stub comunica com o exterior. Se não vir qualquer tráfego DNS enquanto o agente está claramente a trabalhar, esse runtime está a fazer DNS over HTTPS diretamente. Nesse caso, apenas a etapa 4 lhe permitirá obter os nomes.

Faça a captura enquanto o agente executa trabalho real. Inicie uma sessão, faça-o ler um ficheiro, faça-o executar um comando e faça-o falhar numa operação. O tráfego que ocorre apenas uma vez no arranque ou apenas quando é lançada uma exceção nunca aparece numa captura em espera. Uma captura em espera é a forma mais comum de uma auditoria chegar a uma conclusão errada, mas aparentemente confortável.

Passo 4: o que existe dentro dos pedidos?

Os nomes de anfitrião indicam quem. Para ver o quê, coloque um proxy sob o seu controlo à frente do agente e confie na respetiva autoridade de certificação (CA) apenas durante essa execução. mitmproxy é a ferramenta habitual. O projeto recomenda os binários autónomos disponíveis em mitmproxy.org e documenta uv tool install mitmproxy como opção através do pacote Python.

mitmdump -w /tmp/agent-flows.mitm

A primeira execução grava uma CA em ~/.mitmproxy/, onde mitmproxy-ca-cert.pem é o certificado isolado. Na shell a partir da qual vai iniciar o agente, indique ao cliente o proxy e esse certificado.

export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export REQUESTS_CA_BUNDLE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export SSL_CERT_FILE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"

Muitas CLI de agentes são programas Node, e Node lê NODE_EXTRA_CA_CERTS quando o processo é iniciado. Por isso, exporte essa variável antes de iniciar o agente, e não noutra janela de terminal depois disso. Os clientes Python leem REQUESTS_CA_BUNDLE ou SSL_CERT_FILE, e um binário Go que use a biblioteca padrão lê SSL_CERT_FILE no Linux. Confirme que o caminho funciona com curl antes de atribuir a culpa ao agente.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Um proxy funcional apresenta 200, e o pedido aparece na saída do mitmdump. Uma CA não confiável produz curl: (60) SSL certificate problem: self-signed certificate in certificate chain. Num agente Node, o erro equivalente contém o código SELF_SIGNED_CERT_IN_CHAIN. Depois, leia os fluxos guardados com o visualizador de consola. Pode abrir um pedido e ler os respetivos cabeçalhos e corpo.

mitmproxy -r /tmp/agent-flows.mitm

Vale a pena distinguir quatro resultados. Se vir os pedidos, leia-os e decida. Se o agente se recusar a iniciar com um erro de certificado, existe um problema de confiança nesse runtime. Isso não constitui uma conclusão sobre o fornecedor. Se vir apenas a API do modelo, as outras categorias estão desativadas ou são acionadas por um evento que não provocou. Se não vir nada, embora o agente funcione claramente, o cliente ignora as variáveis de ambiente do proxy ou fixa os seus certificados. Nesse caso, nenhuma definição da aplicação pode ser considerada fiável para indicar o que está a acontecer. Este último resultado é o mais importante. Ele remete-o de volta ao passo 3, porque não é possível convencer uma captura de pacotes a ignorar uma ligação.

Controles, do mais fraco ao mais forte

Definições de exclusão. São as mais baratas e as mais fracas, porque dependem de o fornecedor as respeitar e abrangem uma categoria que já existia. Defina-as num local onde persistam depois de um reboot e numa nova sessão de terminal, no ficheiro de definições do utilizador ou no perfil da shell. Adicione também DO_NOT_TRACK=1 enquanto está nesse local: é uma convenção respeitada por muitas ferramentas de linha de comandos, incluindo alguns agentes, e não tem qualquer custo. Depois da atualização seguinte, repita o passo 3, porque é nesse momento que a cobertura muda.

Restrição de saída. Aqui deixa de pedir e passa a aplicar regras. Execute o agente com uma conta própria. Depois, permita a essa conta o acesso ao loopback e ao DNS e bloqueie o restante. Isto adiciona a sua própria tabela, sem alterar as regras de firewall existentes.

table inet agentegress {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ip daddr 127.0.0.0/8 accept
    meta skuid "agent" udp dport 53 accept
    meta skuid "agent" counter log prefix "agent-egress-drop " drop
  }
}

Aplique-a com sudo nft -f /etc/nftables.d/agent.nft, monitorize o contador com sudo nft list table inet agentegress e consulte os bloqueios com sudo journalctl -k -g agent-egress-drop. Um contador de bloqueios crescente associado a um nome de host inesperado é precisamente o objetivo deste procedimento. Há duas limitações importantes. meta skuid corresponde ao utilizador que é proprietário do socket. Por isso, só funciona enquanto essa conta não puder tornar-se noutro utilizador: o uso de sudo sem palavra-passe pelo agente transforma esta regra numa recomendação. Além disso, deixar a porta UDP 53 aberta para qualquer servidor mantém um canal que pode transportar dados para fora através dos nomes das consultas. Se o seu modelo de ameaças exigir essa proteção, feche também esse canal e configure o resolver do agente para utilizar um host sob o seu controlo. As listas de permissões de nomes de host devem ficar num proxy, não no nftables, porque os endpoints das APIs estão atrás de redes de distribuição de conteúdo cujos endereços IP mudam sem aviso. O custo deste controlo é a interrupção de funcionamento e a manutenção: instalações de pacotes, git através de SSH e a própria verificação de atualizações do agente falham até serem permitidas. A partir desse momento, a manutenção dessa lista fica a seu cargo. Se estiver a configurar isto num servidor em vez de num portátil, a mesma conta e a mesma organização da firewall são a base de executar o Claude Code com segurança numa VPS.

Uma máquina descartável. Dê ao agente uma máquina virtual (VM) sem credenciais importantes e destrua-a no fim da tarefa. Isto não reduz o que o agente envia. Reduz aquilo a que o agente tem acesso para enviar, que normalmente é o risco relevante. Combine esta opção com as regras de saída anteriores, porque uma VM nova com acesso irrestrito à Internet continua a alcançar todos os hosts incluídos na sua captura. O método e o estado que tem de reconstruir de cada vez são descritos em executar agentes de programação numa VM descartável, e a questão do dimensionamento em executar um agente de programação numa VPS.

Alojamento próprio do modelo. É o único controlo que elimina o fluxo de inferência, porque o prompt nunca sai do seu hardware. O custo é real: não pode alojar localmente um modelo fechado. Isso significa escolher pesos abertos, aceitar uma diferença de capacidade em tarefas complexas e dispor do hardware necessário para os servir. A compensação é analisada em saber se pode alojar o Claude localmente, e as diferenças de capacidade entre os principais agentes em diferenças entre Claude Code, Cursor, Codex e Copilot.

Nenhum destes quatro controlos altera aquilo que o agente pode ler no disco, e o tráfego de inferência transporta tudo o que ele lê. Se um ficheiro .env estiver no diretório de trabalho, será enviado para o modelo assim que o agente procurar o nome de uma variável com grep. Manter esse material fora do alcance do agente é uma tarefa separada, descrita em manter segredos fora do contexto de um agente de IA.

O que verificar após cada atualização

1. Compare as páginas do fornecedor sobre configurações e utilização de dados com o que registou da última vez. Procure novas opções e novos serviços identificados por nome.
2. Leia novamente o ambiente do processo a partir de /proc/<pid>/environ para confirmar que as suas opções de exclusão continuam aplicadas ao processo em execução.
3. Mostre novamente os ficheiros de configuração do projeto, porque um git pull pode carregar um ficheiro de configuração que um colega alterou.
4. Execute a captura de SNI durante uma sessão completa de trabalho real e compare a lista de nomes de host com a anterior.
5. Verifique o contador de pacotes descartados pela firewall, porque um novo destino costuma aparecer aí antes de ser detetado noutro local.

Isto demora cerca de dez minutos e é a única parte do processo que não fica desatualizada. Uma predefinição que verificou em agosto de 2026 é um facto sobre agosto de 2026. A captura é um facto sobre hoje.

FAQ

Posso impedir que o meu agente de programação envie o meu código para o modelo?

Não, e qualquer configuração que afirme fazê-lo está a descrever outra coisa. O envio do seu prompt, dos ficheiros lidos pelo agente e da saída dos comandos executados para o endpoint do modelo é o funcionamento normal da inferência. A única variável é quem recebe esses dados. Pode alterar o destinatário apontando o agente para uma conta cloud da empresa ou para um modelo alojado por si. Também pode reduzir o que é enviado limitando aquilo que o agente pode ler. Desativar a análise de utilização e os relatórios de erros não altera este fluxo.

Como vejo a que hosts o meu agente de programação se liga?

Execute o agente com o seu próprio utilizador Linux. Em seguida, capture o TLS ClientHello de cada nova ligação enquanto o utiliza: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name. É apresentada uma linha por ligação, com o endereço de destino e o hostname solicitado. Confirme os nomes com sudo tcpdump -ni any 'udp port 53', capturando em any, porque um stub resolver local em 127.0.0.53 processa primeiro a consulta. Faça a captura enquanto o agente executa trabalho real. Os pings de arranque e os relatórios de falhas nunca aparecem numa captura feita quando o agente está inativo.

O meu proxy não mostra tráfego enquanto o agente trabalha. O que aconteceu?

O cliente ignora HTTP_PROXY e HTTPS_PROXY, ou fixa os seus certificados e recusa a sua CA. Teste primeiro o caminho com curl. Se curl chegar à Internet através do proxy e o agente não aparecer na lista de fluxos, o agente não está a utilizar as variáveis de ambiente do proxy. Alguns runtimes precisam que a CA seja fornecida de uma forma específica. O Node, em particular, lê NODE_EXTRA_CA_CERTS apenas no arranque do processo. Por isso, exportá-la depois de iniciar o agente não produz qualquer efeito. Quando o proxy não consegue ver o tráfego, recorra à captura de pacotes. Nenhuma configuração da aplicação pode contornar esse método.

Desativar a telemetria impede que o meu código seja utilizado para treino?

Não. A análise de utilização e os relatórios de falhas são um fluxo diferente da inferência. Desativá-los remove os contadores de utilização e os stack traces, mas deixa todos os prompts a ser enviados para o modelo exatamente como antes. A retenção desses prompts e a sua utilização para treinar um modelo futuro são definidas pelos termos do seu plano. Os planos para consumidores e os planos comerciais normalmente diferem. Esta é uma questão contratual, não algo que possa ser verificado através de uma captura de pacotes. Consulte a página de utilização de dados do seu plano. Quando for necessário, estabeleça um acordo comercial ou de retenção zero antes da primeira sessão.