O que seu assistente de IA envia para fora: auditoria de tráfego com mitmproxy

```html

Em 11 de agosto de 2026, uma análise que vale a pena ser lida por todos que utilizam um assistente de IA em sua IDE de trabalho se espalhou pelo Hacker News: um pesquisador colocou o VS Code com o GitHub Copilot atrás de um proxy interceptador e observou o que exatamente estava sendo enviado para os servidores. Descobriu-se que a solicitação incluía significativamente mais do que a linha que você está digitando — incluindo o conteúdo do arquivo .env em texto claro.

A boa notícia: qualquer um pode verificar isso, e não apenas no Copilot. Abaixo está um guia prático sobre como, em 20 a 30 minutos, você pode auditar o tráfego do seu assistente, o que procurar nas solicitações interceptadas e quais são as limitações dos mecanismos padrão de exclusão de arquivos.

Por que fazer isso por conta própria

A documentação do fornecedor descreve a política, não o comportamento real do cliente. Entre "não usamos seu código para treinamento" e "o cliente não envia seu código para o servidor" — há um abismo: para gerar uma sugestão, o modelo precisa receber contexto, e a questão é quão amplamente o cliente coleta esse contexto.

A auditoria é necessária se você:

• trabalha sob um NDA ou com dados pessoais de clientes e precisa saber o que está saindo do perímetro;
• mantém segredos, configurações de ambientes, endereços internos e tokens em seu repositório;
• é responsável pela conformidade na equipe e precisa de um log real de solicitações, não apenas de uma captura de tela das configurações;
• simplesmente quer entender por que o assistente de repente "sabe" sobre um arquivo que você não abriu.

O que foi encontrado no tráfego do Copilot

A análise em questão baseou-se no clássico mitmproxy: o VS Code foi direcionado para um proxy local na porta 8080 e a verificação rigorosa do certificado foi desativada. Principais descobertas:

• O contexto é mais amplo do que um único arquivo. Durante as sugestões inline, o cliente coleta até 20 arquivos, 8 resumos das últimas edições e 3 linhas de contexto em torno de cada alteração, além do texto completo do arquivo atual e arquivos recentemente editados em forma de diffs.
• Segredos não são mascarados. No corpo da solicitação, o campo prompt continha uma string do tipo TEST_ENV_VAR_SECRET="mysecretenvvar" — ou seja, variáveis de ambiente de um arquivo aberto estavam sendo enviadas como texto comum.
• A base de dados local também está aberta. O arquivo session-store.db armazena user_message e assistant_response sem criptografia ou edição: nele estavam armazenados tokens, chaves de provedores de nuvem e senhas de strings de conexão que você já havia inserido no chat.
• Chamadas de serviço. Além das sugestões propriamente ditas, o cliente faz chamadas para /models, /agents/swe/models, /models/session/intent e endpoints OAuth do GitHub — por meio deles, é possível ver claramente como o assistente classifica sua solicitação antes mesmo de gerar uma resposta.

É importante lembrar: o cliente envia para o servidor a URL do repositório atual para obter a política de exclusões aplicável. Esse fato, por si só, é inofensivo, mas significa que a composição da sua árvore de trabalho também é um sinal.

Passo a passo: como configurar a interceptação

1. Instale o mitmproxy e inicie-o. O suficiente é a interface web: mitmweb. Por padrão, o proxy escuta a porta 8080, e o console é aberto no navegador. Para CI e sessões longas, é mais conveniente usar mitmdump.
2. Instale o certificado raiz. Na primeira execução, o mitmproxy cria um CA no diretório ~/.mitmproxy (arquivo mitmproxy-ca-cert.cer). Ele precisa ser adicionado aos confiáveis — caso contrário, o cliente interromperá a conexão TLS. Durante a auditoria, é suficiente ter confiança em nível de usuário; depois, remova o certificado, não deixe um CA desconhecido no sistema "só por precaução".
3. Escolha o modo de interceptação. Existem três modos, e a escolha correta economiza uma hora de trabalho:
   • regular — proxy comum, o cliente é configurado explicitamente. A opção mais previsível.
   • local — interceptação transparente de aplicativos na mesma máquina, sem modificar as configurações do programa: mitmproxy --mode local:Code capturará apenas o processo do VS Code, --mode local:42 — o processo com o PID especificado, --mode local:!curl — tudo, exceto curl. Esta é a melhor maneira de escutar um assistente que não tem configuração de proxy.
   • upstream — uma cadeia, onde atrás do mitmproxy está seu próprio proxy: mitmdump --mode upstream:http://host:8081, e o login e a senha são definidos pela opção --set upstream_auth=user:pass.
4. Direcione a IDE para o proxy (para o modo regular). No VS Code em settings.json:
   • "http.proxy": "http://127.0.0.1:8080"
   • "http.proxySupport": "override"
   • "http.proxyStrictSSL": false — apenas durante a auditoria. Esta flag desativa completamente a verificação de certificados, e não deve ser deixada na configuração de trabalho.
5. Resolva o problema do certificado de forma adequada. A extensão Copilot funciona no Node, portanto, o caminho correto é não desativar a verificação, mas coletar o PEM com os CAs raiz mais o certificado do mitmproxy e especificá-lo através da variável de ambiente NODE_EXTRA_CA_CERTS. A IDE precisa ser reiniciada: a variável é lida no início do processo.
6. Escreva o fluxo em um arquivo. Olhar em tempo real é inútil — há dezenas de solicitações por minuto. Ative --set save_stream_file=flows.dump, e para não coletar tudo, limite a amostragem através de --set save_stream_filter=.... Depois, o arquivo pode ser analisado offline.
7. Busque no corpo da solicitação, não na URL. Uma técnica prática: coloque em um repositório de teste um arquivo canário com uma string única (por exemplo, CANARY_9f3c_DO_NOT_SEND), abra-o no editor, trabalhe em um arquivo ao lado — e busque o canário nos corpos interceptados. Assim, você verá não o raio teórico de coleta de contexto, mas o raio real da sua versão do cliente.

Armadilhas

A licença pode bloquear a interceptação. Em planos corporativos, o Copilot retorna um erro do tipo "Sua licença atual do Copilot não suporta conexões proxy com certificados autoassinados". Isso não é um bug do proxy — o cliente intencionalmente se recusa a funcionar através de um CA autoassinado. A solução é um certificado confiável em nível de sistema ou a construção de um PEM para o Node; se a política da organização proíbe isso, a auditoria precisará ser aprovada pelo administrador, e não contornada.

Pinning e QUIC. Parte dos clientes utiliza HTTP/3 sobre QUIC, que um proxy comum não verá. Se, após ativar a interceptação, o aplicativo "funciona, mas o log está vazio" — quase sempre a razão é esta: bloqueie UDP/443 para o processo de teste, e o cliente reverterá para HTTP/2.

Telemetria e carga útil seguem caminhos diferentes. Não tire conclusões de "nada está saindo" com base em um único endpoint: observe toda a lista de hosts que o processo acessa, e não apenas aquele mencionado na documentação.

Quadro jurídico. É permitido interceptar tráfego em sua própria máquina e em sua própria conta. Escutar o laptop de trabalho de outra pessoa sem o conhecimento do proprietário — isso já é outra história, e nenhuma "segurança" a justifica.

O que fazer com os resultados

Se a auditoria mostrou que arquivos desnecessários estão sendo incluídos nas solicitações, os meios padrão se apresentam assim — e cada um tem uma limitação significativa.

• Exclusão de conteúdo. Mecanismo oficial do GitHub que proíbe o Copilot de usar os caminhos especificados. Disponível apenas em planos Business e Enterprise, configurado pelo administrador nas configurações do Copilot, suportado no VS Code, Visual Studio e JetBrains; no Xcode, Eclipse e Vim/Neovim — apenas para sugestões inline.
• A principal falha — modo agente. A documentação afirma claramente que as exclusões não são suportadas nos modos Edit e Agent no Copilot Chat, bem como no Copilot CLI. Ou seja, exatamente onde o assistente navega pelos arquivos, lê as configurações e executa comandos, a filtragem da plataforma não é aplicada. Se você conta com a exclusão de conteúdo como a única barreira — no modo agente, não há barreira.
• .gitignore não protege. Um equívoco comum: a exclusão do índice do Git não significa exclusão do contexto do assistente.
• Mínimo organizacional. Segredos — no gerenciador de segredos, e não em .env ao lado do código; o chat do assistente não é o lugar para inserir strings de conexão; a base de dados local de histórico deve ser limpa assim como você limpa o histórico do shell.

Onde está o proxy e por que você precisa dele

A interceptação tem uma continuação prática. Primeiro, o modo upstream permite que todo o tráfego do assistente passe por um nó de saída controlado: você vê simultaneamente as solicitações e controla de qual endereço elas estão saindo. Isso é necessário quando a API do assistente não está disponível em sua região ou quando a política corporativa exige um IP de saída fixo — para esse cenário, proxies de datacenter estáveis com endereço fixo são adequados.

Em segundo lugar, o mesmo ambiente será útil para depuração de automação: quando o agente de IA navega por sites, a interceptação mostra quais cabeçalhos ele realmente envia e como as proteções o capturam. Analisamos essa conexão em um material sobre proxies para agentes de IA no Playwright e MCP — lá falamos sobre a escolha do tipo de endereço para cenários de agentes, onde é necessário um IP residencial, e não um servidor.

Se você nunca configurou o mitmproxy, comece com a configuração básica de interceptação HTTPS — ela está detalhadamente descrita em nosso guia de interceptação de tráfego através do mitmproxy, e a partir dela você pode adicionar os modos local e upstream.

Conclusão

A auditoria do tráfego do assistente de IA não é paranoia, mas uma higiene de engenharia normal que leva uma noite e é feita uma vez. A análise do Copilot mostrou um quadro claro: o cliente coleta contexto amplamente, segredos entram nesse contexto junto com o código, o histórico local é armazenado em texto claro, e as exclusões padrão não funcionam exatamente no modo mais perigoso — o modo agente.

Verifique não a documentação, mas o tráfego. Inicie o mitmproxy no modo local, coloque um canário no repositório, colete o fluxo em um arquivo e veja com seus próprios olhos o que está saindo da sua máquina. A partir daí, a decisão é simples: ou você aceita conscientemente esse volume de transmissão, ou retira os segredos do seu diretório de trabalho antes que um servidor desconhecido os veja.