O upload do histórico Git do ZCode transforma uma conveniência de programação em um problema de confiança

O ZCode supostamente enviou um espaço de trabalho inteiro de um desenvolvedor, com 345 MB, incluindo seu histórico Git, apesar de configurações que pareciam limitar a coleta de dados. O relatado upload do histórico Git pelo ZCode não se restringiu a arquivos selecionados para um prompt de IA. Ele incluiu objetos do repositório, reflogs e arquivos grandes em cache que podem preservar anos de trabalho privado de engenharia.

Uma investigação técnica publicada em 18 de setembro rastreou o comportamento no aplicativo desktop fechado do ZCode. Segundo a análise, o cliente criou checkpoints criptografados do espaço de trabalho e os transferiu para o Alibaba Cloud Object Storage Service enquanto o usuário estava conectado.

A descoberta continua sendo uma alegação de engenharia reversa de terceiros, e não uma divulgação auditada de forma independente da Z.ai. No momento da publicação, os materiais oficiais disponíveis não explicavam claramente o escopo relatado do upload, a retenção dos checkpoints ou como os usuários poderiam evitá-lo.

Essa lacuna de verificação faz parte da história. O ZCode promove modelos GLM com um agente projetado para compreender um espaço de trabalho, executar comandos e recuperar tarefas de longa duração. Contudo, um modelo de pesos abertos não torna transparente o aplicativo desktop que o cerca.

Portanto, o conflito central não é ZCode contra outro assistente de programação. Trata-se dos controles de privacidade visíveis do produto versus o comportamento atribuído ao seu sistema oculto de checkpoints.

O que encontrou o relatório sobre o upload do histórico Git do ZCode

A investigação afirma que o ZCode capturou um arquivo do repositório, e não apenas o código necessário para uma solicitação de modelo.

O pesquisador examinou um espaço de trabalho comercial privado contendo 42.411 arquivos. O diretório original ocupava cerca de 345 MB, enquanto o checkpoint criptografado do ZCode tinha aproximadamente 313 MB.

O conteúdo relatado foi especialmente revelador. Cerca de 196,1 MB vieram do diretório .git/lfs, onde o Git Large File Storage pode armazenar em cache grandes ativos do projeto. Outros 102,2 MB vieram de .git/objects, o banco de dados subjacente do Git com conteúdos de arquivos, árvores de diretórios e commits.

Os reflogs adicionaram aproximadamente 0,6 MB. Arquivos-fonte atuais, configuração e documentação representaram cerca de 46,2 MB, ou 13,4% do material medido.

Nesse snapshot individual, o diretório .git respondeu por 86,6% dos dados arquivados. Isso não estabelece uma média para todas as instalações do ZCode. Mas mostra por que chamar o evento de um upload rotineiro de código minimiza o escopo relatado.

O relato original afirma que o ZCode criou o checkpoint nos dados locais de seu aplicativo e deixou um manifesto em texto simples ao lado do arquivo criptografado. Esse manifesto teria exposto o caminho absoluto do espaço de trabalho afetado.

Segundo a engenharia reversa, o ZCode solicitou credenciais de upload a um serviço da Z.ai. A resposta incluía uma chave de objeto, um formulário de upload assinado, um limite de tamanho e uma chave pública RSA.

O cliente teria compactado o espaço de trabalho, criptografado-o com AES-256-CTR e encapsulado a chave simétrica usando RSA-OAEP-SHA256. Em seguida, publicou o objeto criptografado diretamente em um endpoint de armazenamento da Aliyun.

Um callback teria informado o backend da Z.ai após a conclusão da transferência. Se essa reconstrução estiver correta, o upload era um fluxo projetado do aplicativo, e não uma solicitação acidental ao modelo contendo contexto demais.

A criptografia não resolve o problema de divulgação. Ela protege os dados de observadores entre o computador e o serviço de armazenamento, supondo que a implementação esteja correta. Não impede que o operador de serviço pretendido acesse as informações.

O relatório diz que a chave privada RSA correspondente permaneceu sob controle do servidor. Consequentemente, o usuário que forneceu o repositório não conseguia descriptografar e inspecionar o checkpoint armazenado no mesmo computador.

Essa distinção importa. “Criptografado” pode soar como “indisponível para o fornecedor”, mas essas afirmações não são equivalentes. A criptografia protege dados conforme quem controla as chaves relevantes.

O relatório também afirma que duas configurações visíveis de privacidade não impediram a criação nem a transferência dos checkpoints. Essa alegação não foi confirmada por uma auditoria independente do produto, e um participante do Hacker News relatou não ter encontrado um diretório de checkpoint correspondente.

A diferença pode refletir versões do produto, sistemas operacionais, estados de conta, implantação gradual ou uso de recursos específicos. Também pode indicar que o caso original não se aplica a todos os usuários.

A Z.ai precisa esclarecer essas condições. Até lá, a descrição mais segura é que pesquisadores documentaram o comportamento em pelo menos um ambiente testado, enquanto sua prevalência total continua desconhecida.

Por que um diretório .git completo é mais sensível do que o código atual

Um repositório Git contém a memória de um projeto, incluindo informações que já não aparecem em seus arquivos atuais.

Os desenvolvedores frequentemente descrevem .git como “histórico”, mas ele contém mais do que a saída de git log. Ele armazena objetos, referências, informações de ramificações, configuração, reflogs e outros metadados do repositório.

O Git é, fundamentalmente, um banco de dados endereçável por conteúdo. Seus objetos blob preservam conteúdo de arquivos, objetos tree descrevem estados de diretórios e objetos commit conectam snapshots em um histórico.

O modelo de objetos do Git oficial explica como esses elementos permanecem dentro de .git/objects. Um aplicativo que copia esse diretório pode receber muito mais do que os arquivos visíveis na árvore de trabalho.

Considere um desenvolvedor que envia por engano uma credencial de API em um commit na segunda-feira e a remove na terça-feira. O arquivo atual já não exibe a credencial, mas o objeto anterior pode continuar acessível pelo histórico do repositório.

Excluir a cópia mais recente não é suficiente. As orientações do GitHub sobre remoção de dados confidenciais instruem os desenvolvedores a revogar primeiro as credenciais expostas e, em seguida, considerar uma reescrita coordenada do histórico.

O mesmo problema se aplica a certificados privados, nomes de host internos, identificadores de clientes, arquivos de ambiente e credenciais incorporadas em fixtures de teste. Um repositório também pode reter arquitetura abandonada, correções de segurança, produtos não lançados e material de licenciamento.

Os reflogs ampliam o risco. Eles registram como referências locais foram movidas e podem preservar caminhos de acesso a commits que já não são visíveis em uma ramificação compartilhada.

Ramificações locais podem revelar iniciativas que nunca foram enviadas. Mensagens de commit podem nomear clientes, vulnerabilidades, funcionários ou incidentes internos. A configuração do repositório pode identificar remotos privados e domínios de infraestrutura.

O Git LFS introduz outra categoria. Seu cache pode conter arquivos de design, conjuntos de dados, mídia, modelos empacotados ou outros binários que os desenvolvedores razoavelmente acreditam estar fora do contexto imediato de um assistente.

Portanto, o componente LFS relatado de 196,1 MB não era um volume irrelevante. Ele poderia representar parte do material menos textual e mais comercialmente sensível do projeto.

Um agente de programação pode precisar legitimamente de amplo acesso local. Ele não consegue refatorar uma aplicação complexa sem ler módulos relacionados, executar testes ou compreender dependências.

Essa permissão local não implica automaticamente permissão para criar uma cópia duradoura na nuvem de tudo que está acessível ao processo. Ler um arquivo para uma tarefa solicitada, enviar contexto selecionado para inferência e arquivar o repositório inteiro são operações distintas.

É por isso que a alegação sobre o upload do histórico Git do ZCode é mais séria do que a observação de que assistentes de programação em nuvem processam código. A disputa envolve escopo, persistência, controle e divulgação.

Um desenvolvedor pode aprovar conscientemente uma solicitação ao modelo contendo uma função e suas dependências. Esse mesmo desenvolvedor poderia rejeitar o upload de um cache LFS, credenciais excluídas, ramificações inativas e anos de objetos de commit.

Usuários corporativos enfrentam preocupações adicionais. Um repositório pode conter material regido por contratos com clientes, termos de escrow de código-fonte, controles de exportação, regras de residência de dados ou políticas de acesso de funcionários.

A questão relevante não é simplesmente se foi usada criptografia. As equipes de segurança precisam saber o que foi coletado, onde foi armazenado, quem detinha as chaves, por quanto tempo permaneceu e como funcionava a exclusão.

Os controles de privacidade e os checkpoints parecem contar histórias diferentes

A preocupação mais aguda é a lacuna relatada entre o que os usuários podiam controlar e o que o aplicativo supostamente fazia.

A documentação oficial do ZCode descreve um agente que compreende o estado do espaço de trabalho, referências a arquivos, tarefas e o contexto de ramificações Git. Sua documentação de agentes também apresenta a recuperação de estado como parte do suporte a tarefas de desenvolvimento mais longas.

O uso de checkpoints pode servir a uma finalidade legítima. Um agente que edita dezenas de arquivos precisa de uma forma de se recuperar após uma alteração malsucedida, comparar estados ou restaurar um trabalho interrompido por uma falha.

Essa função não exige que os checkpoints sejam invisíveis. Tampouco estabelece que todas as partes de .git precisem ser incluídas em um arquivo remoto.

Um design que preserve a privacidade poderia excluir, por padrão, objetos Git e caches LFS. Poderia publicar o manifesto exato do arquivo antes da transferência, manter checkpoints locais ou solicitar aprovação explícita antes da sincronização em nuvem.

Também poderia fornecer uma política organizacional que bloqueie snapshots remotos. Administradores poderiam aplicar exclusões no nível do repositório e confirmar seu efeito por meio de um log de auditoria.

Em vez disso, a investigação alega que o processo de arquivamento do ZCode operava fora do ciclo de ferramentas visível do agente. As ferramentas listadas do agente supostamente não continham nenhuma ação de snapshot ou upload que os usuários pudessem aprovar.

Essa arquitetura explicaria por que as permissões de comandos não conseguiram impedir a transferência. Um componente auxiliar no nível do host pode ser executado independentemente das ferramentas do modelo, mesmo quando o usuário restringe a execução de shell ou a modificação de arquivos.

Ela também expõe um ponto cego nas interfaces atuais de agentes. Os prompts de permissão normalmente se concentram em ações evidentes, como executar um comando, editar um arquivo ou abrir um endereço de rede.

Os serviços em segundo plano recebem menos atenção. Eles podem indexar pastas, coletar diagnósticos, sincronizar sessões ou criar artefatos de recuperação sem aparecer na conversa.

A distinção entre inferência e sincronização torna-se importante aqui. Enviar código selecionado a um modelo de nuvem é suficientemente visível para que a maioria dos usuários espere isso de um assistente baseado em nuvem.

Copiar o banco de dados subjacente do repositório para reversão ou indexação é um segundo fluxo de dados. Ele precisa de sua própria explicação, controles de escopo, regras de retenção e interface de exclusão.

A atual política de privacidade do ZCode afirma que dados pessoais podem ser retidos conforme necessário para prestar serviços, cumprir obrigações, proteger interesses comerciais legítimos e melhorar segurança ou estabilidade. Ela também afirma que a retenção varia conforme o tipo, a sensibilidade, a finalidade dos dados e os requisitos legais.

Essas declarações gerais não respondem às perguntas levantadas pelo relatório. A política precisa identificar se checkpoints de espaços de trabalho são considerados entrada do usuário, dados técnicos ou outra categoria.

Ela também deve explicar qual região de armazenamento se aplica, se subcontratados processam os arquivos e se a exclusão de uma conta remove todos os checkpoints. Os usuários precisam de períodos concretos de retenção ou critérios claros vinculados ao recurso relevante.

Mais importante ainda, a Z.ai deveria documentar se os controles de privacidade afetam os uploads de checkpoints. Um controle relacionado à coleta de dados pode criar uma falsa sensação de segurança se regular análises, mas não a sincronização do workspace.

A linguagem e o posicionamento de um controle importam tanto quanto sua implementação interna. Desenvolvedores não podem tomar decisões informadas quando fluxos de dados materialmente diferentes são agrupados sob termos vagos.

A resposta mais sólida possível da Z.ai seria técnica, não retórica. Ela listaria versões afetadas, condições de ativação, exclusões de arquivos, endpoints, funções de criptografia, períodos de retenção e procedimentos de exclusão.

Também explicaria se o comportamento mudou após a reportagem. Sem esse detalhe, os usuários não podem determinar se uma atualização corrigiu o problema ou apenas removeu evidências locais.

Pesos Abertos Não Tornam Local um Agente de Programação Fechado

O incidente separa o modelo do software que decide o que o modelo pode ver e o que sai da máquina.

Os modelos GLM são centrais para a estratégia de desenvolvedores da Z.ai, e algumas versões foram distribuídas com pesos abertos. Desenvolvedores podem inspecionar esses arquivos de modelo, executar versões compatíveis em sua própria infraestrutura e evitar um endpoint de inferência hospedado.

ZCode é uma camada diferente. É a estrutura que escolhe o contexto, invoca ferramentas, armazena sessões, gerencia checkpoints, conecta-se a serviços em nuvem e se atualiza.

A estrutura pode determinar os resultados de privacidade mesmo quando o modelo subjacente é executado localmente. Um modelo local não impede que um aplicativo ao redor envie telemetria, índices, histórico de sessões ou snapshots de recuperação para outros lugares.

Da mesma forma, um modelo aberto não pode revelar o que um aplicativo Electron fechado faz em um processo em segundo plano. Pesquisadores precisam observar o tráfego de rede, inspecionar pacotes do aplicativo e reconstruir o comportamento após o lançamento.

Este é o principal conflito de confiança. A experiência de produto do ZCode enfatiza o entendimento local do workspace, enquanto a reportagem descreve um mecanismo de captura em nuvem mais amplo do que os desenvolvedores esperavam.

Concorrentes também processam dados de desenvolvedores, portanto a comparação correta não é “o ZCode envia código enquanto todos os outros agentes permanecem locais”. Isso seria impreciso.

Claude Code, GitHub Copilot, Codex, Cursor e outras ferramentas conectadas à nuvem enviam algumas entradas de usuários e contexto de código para serviços remotos. Índices de repositórios, sessões de agentes e ambientes de tarefas em nuvem podem criar cópias adicionais.

As diferenças aparecem na divulgação e no controle. O GitHub, por exemplo, documenta políticas de exclusão de conteúdo e explica que algumas superfícies do Copilot não oferecem suporte a essas exclusões.

O GitHub também documenta quando a indexação semântica de repositórios fora do GitHub envia dados e afirma que administradores corporativos precisam habilitar esse recurso. Esses controles ainda têm limitações, mas os usuários podem identificar o fluxo de dados e avaliá-lo.

Esse é o padrão que a Z.ai agora enfrenta. Um fornecedor não precisa prometer que nenhum código jamais sairá de um computador se o produto depende de inferência em nuvem.

Ele precisa descrever cada transferência com precisão. Deve distinguir o contexto temporário de um prompt de um snapshot persistente de repositório e dar aos administradores controle efetivo.

Estruturas de código aberto oferecem uma resposta. Seu código pode revelar exclusões de arquivos, endpoints de rede e comportamento de atualização, enquanto revisores independentes podem testar se as configurações documentadas correspondem à implementação.

Código aberto não é uma garantia completa de segurança. Poucos usuários inspecionam cada dependência, binários assinados podem diferir do código publicado e atualizações comprometidas ainda podem causar danos.

Ferramentas de código fechado também não são automaticamente maliciosas. Elas podem passar por avaliações independentes, fornecer mapas detalhados de dados, aplicar controles por tenant e publicar comportamento de rede verificável.

No entanto, a opacidade aumenta o custo da verificação. Quando um aplicativo tem permissões amplas de sistema de arquivos e execução autônoma, esse custo se torna uma consideração de segurança relevante.

A discussão no Hacker News refletiu os dois lados. Vários comentaristas consideraram qualquer estrutura fechada de programação um risco inaceitável, enquanto outros observaram que agentes em nuvem recebem inerentemente o contexto do projeto.

Um usuário disse que não conseguiu reproduzir o diretório de checkpoints relatado apesar de usar o ZCode. Outros argumentaram que um sandbox deveria restringir todas as ferramentas proprietárias de desenvolvimento, independentemente do fornecedor ou país.

Essas reações identificam duas responsabilidades distintas. Fornecedores devem divulgar seus fluxos de dados, e equipes de desenvolvimento devem limitar o que um agente pode alcançar.

Nenhuma responsabilidade anula a outra. Sandboxing não é consentimento, e um controle de privacidade não é contenção eficaz.

O Risco Imediato Depende do Conteúdo do Repositório e da Versão do Produto

As evidências sustentam uma revisão urgente, mas não provam que todos os usuários do ZCode tiveram os mesmos dados enviados.

O exemplo documentado envolvia um workspace e uma configuração observada do aplicativo. Reportagens públicas não estabeleceram quantas instalações criaram checkpoints, quando o comportamento começou ou se todos os sistemas operacionais seguiram o mesmo caminho.

Também não está claro se os usuários precisavam habilitar algum recurso específico de recuperação ou indexação. O estado de autenticação pode importar porque a reportagem associa as transferências ao fato de o usuário estar conectado.

O histórico de versões também importa. Uma versão posterior pode alterar o diretório, o endpoint, as exclusões ou o comportamento de agendamento sem invalidar a observação anterior.

Essa incerteza deve limitar as alegações, não suprimir a investigação. Equipes que usaram o ZCode com repositórios privados têm evidências suficientes para realizar uma revisão de incidente.

Elas devem começar pelo escopo. Identifiquem quais desenvolvedores instalaram o ZCode, quais versões executaram, quando fizeram login e quais repositórios estavam acessíveis nesses períodos.

Em seguida, inspecionem logs de endpoint, proxy, DNS, firewall e detecção de endpoint em busca de comunicações com serviços da Z.ai e da Aliyun. Arquivos locais de checkpoint podem ajudar, mas sua ausência não estabelece conclusivamente que nenhuma transferência ocorreu.

Organizações devem preservar evidências antes de desinstalar ou atualizar o aplicativo. Uma atualização pode modificar logs, caminhos de armazenamento ou binários que, de outro modo, ajudariam investigadores a reconstruir a atividade.

As equipes de segurança devem presumir que qualquer credencial registrada no histórico de um repositório exposto precisa ser revisada. O GitHub recomenda rotacionar uma credencial vazada porque removê-la dos arquivos mais recentes não a neutraliza.

Essa resposta deve permanecer proporcional. Não rotacione todas as credenciais corporativas apenas porque um desenvolvedor instalou o ZCode. Primeiro mapeie os repositórios; depois, pesquise seus históricos e valide quais segredos permaneceram ativos.

Proprietários de repositórios também devem examinar material sensível que não seja secreto. Commits antigos podem conter dados de clientes, detalhes de vulnerabilidades, endpoints internos, ativos licenciados ou negociações que exigem revisão jurídica.

Se o repositório continha dados regulamentados ou contratualmente restritos, equipes jurídicas e de conformidade devem avaliar obrigações de notificação. A resposta depende da jurisdição, da linguagem contratual, de evidências confirmadas de transferência e dos dados envolvidos.

Desenvolvedores que continuarem testando o ZCode devem isolá-lo. Uma máquina virtual ou contêiner dedicado pode limitar o sistema de arquivos visível, embora a rede e os diretórios montados ainda exijam configuração cuidadosa.

Use um repositório descartável que não contenha credenciais reais nem histórico comercial. Evite montar um diretório inicial, pasta SSH, configuração de nuvem, credenciais de pacotes ou árvores de código-fonte não relacionadas.

Restrições de sistema de arquivos podem bloquear diretórios de checkpoint, mas são uma defesa frágil. Caminhos e processos podem mudar entre atualizações, e negar gravações pode desabilitar o comportamento de recuperação ou interromper o aplicativo.

Controles de rede oferecem outra camada. Equipes podem restringir destinos de saída e registrar tentativas de conexão, embora bloquear serviços necessários possa tornar o produto inutilizável.

Um modelo de longo prazo mais seguro utiliza listas de permissões explícitas. O agente recebe um checkout restrito do projeto, credenciais temporárias e apenas os serviços necessários para a tarefa.

Essa abordagem é útil em todos os fluxos de trabalho de engenharia, não apenas com o ZCode. Qualquer assistente autônomo com acesso ao sistema de arquivos e ao shell deve ser tratado como uma dependência privilegiada de desenvolvimento.

O objetivo não é provar intenção maliciosa com base em evidências incompletas. É reduzir a consequência de comportamentos não documentados.

Três Sinais Mostrarão se a Z.ai Resolveu a Lacuna de Confiança

O próximo teste é saber se a Z.ai transforma um fluxo de dados não documentado em um recurso de produto restrito, visível e verificável.

O primeiro sinal é uma resposta pública detalhada. A Z.ai deve confirmar ou contestar o upload relatado do histórico Git do ZCode, identificar as versões afetadas e explicar qual estado do produto o acionou.

Uma declaração útil abordaria diretamente o conteúdo medido do arquivo. Ela deveria dizer se .git/objects, .git/lfs, reflogs, arquivos ignorados e configuração global foram incluídos.

Se a Z.ai publicar apenas uma garantia geral de que os dados são criptografados, a preocupação central permanecerá. A empresa supostamente controlava a chave de descriptografia, portanto a criptografia em trânsito não responde às perguntas sobre acesso ou retenção.

O segundo sinal é um controle de checkpoint aplicável. O ZCode precisa de uma configuração que interrompa snapshots remotos, possa ser gerenciada por uma organização e seja independente de preferências de análises ou treinamento de modelos.

Os usuários devem poder verificar a configuração por meio de logs ou de um evento de rede documentado. O aplicativo deve mostrar o que pretende enviar antes da primeira transferência.

As exclusões padrão devem remover .git, caches LFS, arquivos ignorados, credenciais e locais comuns de segredos. Usuários poderiam optar por incluir histórico adicional quando uma tarefa realmente exigir isso.

Uma opção de recuperação somente local resolveria grande parte da tensão. Checkpoints podem oferecer suporte à reversão sem se tornarem arquivos em nuvem, especialmente quando o agente e o modelo são executados na mesma máquina.

O terceiro sinal é a reprodução independente. Pesquisadores precisam testar uma versão atual em sistemas operacionais compatíveis, contas novas e existentes e diferentes configurações de privacidade.

Esse trabalho deve responder se o comportamento original era universal, condicional ou já foi alterado. Também deve verificar se excluir checkpoints pelo produto remove todas as cópias no lado do servidor.

Uma avaliação de terceiros fortaleceria a resposta da Z.ai, especialmente se o avaliador publicar o escopo e os métodos. Capturas de pacotes reproduzíveis e manifestos de arquivos seriam mais valiosos do que uma linguagem ampla de certificação.

Para equipes de desenvolvimento, a lição vai além de um aplicativo. Inventariem agentes de programação como componentes da cadeia de suprimentos de software, documentem seus endpoints e revisem seus fluxos de dados antes de conceder acesso a repositórios privados.

Faça cinco perguntas diretas: O que o agente pode ler? O que ele transmite? O que persiste remotamente? Quem detém as chaves? Qual controle interrompe cada transferência?

Se um fornecedor não puder responder a essas perguntas, restrinja o agente a ambientes descartáveis até que possa. Se uma resposta depender apenas de “criptografado”, pergunte quem pode descriptografá-lo.

O upload relatado do histórico Git do ZCode ainda não estabeleceu a exposição de todos os usuários nem comprovou o uso indevido de qualquer arquivo. Ele estabeleceu uma divergência crível que exige uma resposta precisa.

A Z.ai pode reduzir essa lacuna publicando o mecanismo, corrigindo os padrões, oferecendo um verdadeiro interruptor de desativação e apoiando a verificação independente. Até lá, desenvolvedores devem tratar o workspace visível do ZCode como o limite mínimo possível de coleta, e não o máximo.