O ponto cego que ninguém precificou
Em 18 de setembro, um desenvolvedor conhecido como ferstar notou algo estranho no uso do disco dele. O culpado era um único arquivo criptografado, de cerca de 313 MB, gerado pelo ZCode, um agente de codificação da empresa chinesa de IA Zhipu. Dentro do pacote: cerca de 42.000 arquivos, sendo 86,6% deles o histórico completo de revisões dos projetos dele. A chave de descriptografia não estava na máquina dele. Ela estava nos servidores da Zhipu.
A indústria tratou isso como um escândalo de privacidade. É algo pior: uma falha estrutural. Todos os grandes frameworks de segurança de IA construídos no último ano — para alinhamento de modelos, injeção de prompts, atacantes externos — compartilham uma mesma premissa: o fornecedor está do lado do usuário. A ameaça vem de fora. O ZCode quebrou essa premissa, e nenhuma regra existente sequer a sinalizou.
Upload por design, não por bug
A cadeia forense importa, então vamos detalhá-la. A engenharia reversa de Ferstar descobriu que o ZCode empacota e envia um snapshot do projeto em dois momentos: logo antes de o usuário enviar cada prompt para a IA, e de novo quando uma tarefa termina. Em um dia ativo, ele contou até 62 snapshots.
Será que o usuário podia desativar isso? Não realmente. As configurações do ZCode oferecem dois interruptores relevantes. Ao compará-los com o código, um controla se os dados são usados para treinamento de modelos; o outro controla se o servidor constrói um índice de busca a partir dos dados recebidos. Desligando ambos, o empacotamento e o upload locais continuam inalterados.
Três detalhes aguçam o quadro. Primeiro, o diretório de histórico estava isento de todos os filtros de segurança no pipeline de empacotamento — os filtros para arquivos de chaves e certificados, e o limite de 1 MB por tamanho, simplesmente nunca se aplicavam ao seu conteúdo. Senhas que você havia feito commit e depois apagado ainda sairiam da sua máquina. Segundo, quando ferstar apagou manualmente o pacote de 313 MB, o ZCode o regenerou em meia hora e continuou tentando reenviar; o arquivo já havia falhado em 564 tentativas de upload. Terceiro, um desenvolvedor independente, Feng Ruohang, reproduziu a análise forense no próprio Mac dele e encontrou pelo menos um snapshot cujo arquivo de estado carregava um marcador de confirmação do servidor — que, pela lógica do código, só é gravado depois que o servidor confirma o recebimento. Em pelo menos uma máquina, os dados realmente saíram do prédio.
Havia também uma evidência apagada. O changelog do ZCode v3.12.2, datado de 16 de setembro — dois dias antes da revelação —, incluía a linha “otimizar uso de memória do upload de snapshot do repositório”. Times de engenharia não ajustam memória de um comportamento acidental. O upload era um recurso interno mantido. E apagar o changelog em seguida é, em si, um problema separado do original.
A resposta e a pergunta
A Zhipu pediu desculpas rapidamente: o problema vinha de um recurso de “indexação de repositório” ativado por padrão; a função Repo Wiki podia disparar uploads; os dados foram “destruídos imediatamente, nunca armazenados”; o código-fonte seria aberto com revisão de terceiros. Rápido, responsivo e fora de contexto.
A declaração diz que a indexação “ajuda os usuários a gerar [o índice] localmente”. Se é local, por que enviar o projeto inteiro para a nuvem? Indexação local, snapshot e rollback são todos viáveis sem que um único byte saia da máquina — várias ferramentas fazem exatamente isso. A declaração funde “índice local” e “upload para a nuvem” em uma mesma frase, como se o segundo decorasse naturalmente do primeiro. O elo faltante é precisamente o que ninguém explicou.
“Destruídos imediatamente” responde por quanto tempo os dados são retidos. Não responde se eles saíram do seu computador, quem podia acessá-los no servidor, ou quem tinha a chave de descriptografia. O esquema de criptografia — uma chave pública tranca a caixa, a chave privada fica no servidor do fornecedor — prova apenas que terceiros não poderiam interceptar a transferência. Não diz nada sobre se a própria Zhipu podia ler o conteúdo. E a política de privacidade da Zhipu cobre dados que os usuários enviam “por meio de conversa”. Um processo em segundo plano que empacota o seu projeto inteiro não é conversa.
O que realmente é escasso
Por que a comunidade se recusou a comprar a explicação do “gerador de documentação”? Porque a composição do upload corresponde quase perfeitamente aos três tipos de dados mais escassos no treinamento de modelos de código.
Um: cadeias causais de mudança. Histórico de revisões não são snapshots; é “o código estava assim, por este motivo, e virou aquilo” — exatamente o sinal de supervisão necessário para ensinar a um modelo qual edição fazer dado uma intenção. Dois: trajetórias com rótulos de resultado. Fotografar o workspace antes de cada prompt, combinado com um recurso de rollback, registra automaticamente “prompt + estado anterior + estado posterior + se o usuário ficou satisfeito (desfez ou não)”. Esses dados normalmente exigem anotação humana paga. Três: projetos privados reais que nenhum modelo jamais viu. Benchmarks públicos foram memorizados até virar inúteis; bases de código privadas intocadas são o material de avaliação mais valioso que resta.
A imparcialidade corta para o outro lado também. Se o objetivo fosse coleta sistemática de dados de treinamento, o design racional extrairia apenas prompts e diffs — não carregaria centenas de megabytes de caches de arquivos e logs de operação. A desorganização parece mais uma decisão agressiva de ativado-por-padrão empilhada sobre preguiça de engenharia: uma rotina genérica de empacotamento reutilizada por inteiro. Decisões agressivas de produto mais engenharia preguiçosa explicam as evidências melhor que espionagem deliberada. Mas a desorganização não neutraliza o dano. Arquivos de chaves ainda saíram das máquinas dos usuários.
A armadilha da confiança unilateral
O ZCode não estava sozinho este ano. Em julho, o pesquisador de segurança cereblab mostrou, via captura de pacotes, que o Grok Build da xAI enviava projetos inteiros para o Google Cloud Storage — incluindo arquivos que os usuários disseram explicitamente à IA para não ler, e senhas sem redação. Em um projeto de teste de 12 GB, mais de 5 GB já haviam sido transferidos antes de ele interromper. Desativar “melhorar o modelo” não mudava nada. Também em março, descobriu-se que o Claude Code consultava configuração remota a cada hora, com configurações que podiam forçar o encerramento do programa e ignorar pedidos de permissão; ele também lia as configurações de proxy e o fuso horário dos usuários e sinalizava esses dados de volta. Engenheiros da Anthropic depois confirmaram que a sinalização do ambiente era um experimento deliberado contra abusos.
Note como cada caso foi descoberto: um erro de configuração, a captura de pacotes de um pesquisador, a vigilância de um blogger quanto ao espaço em disco. Nenhum veio do próprio debugging de um fornecedor, de uma auditoria da indústria ou de um regulador.
Chame isso de armadilha da confiança unilateral. Agentes de codificação agora detêm uma combinação de permissões que nenhum software de consumidor jamais teve: acesso completo de leitura ao seu projeto, capacidade de executar comandos, uma conexão persistente com o fornecedor e aceitação de mudanças remotas de configuração em segundo plano. Enquanto isso, o estabelecimento de regras do último ano — a lista top dez de IA agêntica da OWASP no fim de 2025, o framework de governança de agentes de Cingapura em janeiro de 2026 exigindo identidade verificável de agentes, a iniciativa de padrões para agentes do NIST em fevereiro, as obrigações de alto risco do AI Act da UE em agosto — defende tudo contra o uso indevido da ferramenta por terceiros. O canal de exfiltração do próprio fornecedor fica fora de todos os checklists: não consta no inventário de capacidades de IA, não passa por aprovação de permissões, é invisível ao próprio loop de segurança do agente. Rode qualquer framework existente contra o comportamento do ZCode e nada será acionado.
Há uma ironia extra. O ZCode foi lançado em julho, comercializado em concorrência direta com o Claude Code semanas depois da controvérsia de telemetria do Claude Code, apresentado como a opção que liberta você do controle remoto do fornecedor. Três meses depois, o mesmo tipo de problema apareceu no próprio ZCode, com uma pegada de dados ainda maior.
O que fazer de fato
A correção instintiva — auditar agentes como empresas de capital aberto — tem a forma certa, mas três lacunas. Nenhuma lei exige que fornecedores mantenham registros de quais dados saíram das máquinas dos usuários, então a base de evidências já está faltando antes de você começar. Os clientes atualizam semanalmente ou se reconfiguram a cada hora, então um relatório anual chega obsoleto. Auditorias financeiras carregam responsabilidade legal; auditorias de agentes não carregam nada.
Open source ajuda, mas tem limites rígidos: ilumina o cliente, nunca o servidor; lançar apenas a versão corrigida não prova nada sobre o comportamento passado; e binários distribuídos pelas lojas podem não corresponder ao código-fonte público.
Três medidas práticas superam ambas. Exigir que fornecedores publiquem uma declaração de egresso — quais servidores o agente contata, quais categorias de dados ele envia — para que ferramentas independentes possam comparar o tráfego real com ela. (cereblab usou captura de pacotes padrão; uma declaração publicada teria reduzido drasticamente o trabalho dele.) Mandatar um log de upload legível e exportável na própria máquina do usuário, registrando tamanho, destino e classe de dados de cada transferência — dissolvendo diretamente o aspecto mais ofensivo do design aqui: um pacote criptografado gerado no seu computador cujo conteúdo você não pode inspecionar. E usar seguro de responsabilidade em vez de órgãos de certificação para avaliar o comportamento de dados dos fornecedores; seguradoras perdem dinheiro quando julgam errado, o que as torna o único mecanismo que transforma revisão cuidadosa em interesse financeiro.
Nada disso é tecnicamente difícil. O que falta é motivação: hoje apenas revisões de procurement corporativo e exposições ocasionais da comunidade a fornecem, e a primeira cobre apenas edições empresariais.
O problema mais profundo é estrutural. Tanto no caso do ZCode quanto no do Grok Build, quem clica em “concordar” é um desenvolvedor individual; as partes que sofrem as consequências do vazamento são seu empregador e seus clientes. Essas partes não aparecem em nenhum fluxo de consentimento e não têm como saber que seu código foi empacotado. A parte que consente e a parte que assume o risco são pessoas diferentes, então o consentimento informado individual não resolve isso — não importa quão claro o diálogo ou quão proeminente o interruptor.
Espere um mercado dividido. Grandes empresas incluirão cláusulas de comportamento de dados e direitos de auditoria em contratos de procurement, e o custo aparecerá nos preços. As versões para consumidor permanecerão sem auditoria e sem prestação de contas — que é precisamente onde a maioria das pessoas escreve código, e precisamente onde elas são mais tentadas a abrir um projeto de trabalho com uma conta pessoal. Antes de clicar no próximo “concordar”, vale perguntar de quem é a assinatura que esse botão acabou de falsificar.
Fontes: análise de engenharia reversa do ZCode por ferstar; reprodução forense independente de Feng Ruohang; análise de captura de pacotes do Grok Build por cereblab; resposta oficial da Zhipu; conforme sintetizado na cobertura da 36Kr sobre o incidente do ZCode.
