O que aconteceu e o que é o ZCode

Um relato técnico publicado no blog Ferstar descreve um comportamento atribuído ao ZCode, um agente de programação baseado em GLM. Segundo o artigo, o software pode criar snapshots do histórico Git do workspace e enviar esse material para a nuvem. A discussão ganhou visibilidade por meio do Hacker News, mas o ponto principal para uma equipe de segurança não é assumir que toda instalação tem o mesmo comportamento. O ponto é tratar qualquer agente que lê um repositório como um componente com acesso privilegiado a propriedade intelectual, credenciais acidentais e dados pessoais.

Um snapshot do Git não é apenas a versão atual dos arquivos. Ele pode conter commits antigos, branches locais, mensagens de commit, diffs, nomes de autores e arquivos que foram removidos da árvore atual. Se um segredo foi cometido no passado e depois apagado, ele ainda poderá estar acessível com comandos como git log, git show ou git fsck, dependendo da retenção local. Por isso, a coleta de um repositório inteiro tem impacto maior que o envio de um único arquivo aberto no editor.

Como funciona

O fluxo descrito envolve identificar que o diretório de trabalho é um repositório, reunir dados do histórico e enviar um pacote para um serviço remoto. A implementação exata deve ser confirmada no código e na documentação da ferramenta antes de qualquer conclusão definitiva. Ainda assim, os controles defensivos são conhecidos: observar processos filhos, chamadas de rede, arquivos temporários, tamanho dos uploads e destinos DNS ou HTTPS usados pelo agente.

O risco cresce quando o agente é executado com o diretório pessoal completo, com acesso ao socket do Docker, com tokens disponíveis em variáveis de ambiente ou com permissão para ler a pasta .git. Um projeto pode parecer limpo na branch atual e continuar expondo chaves presentes em commits antigos. Também é possível que o snapshot inclua submódulos, worktrees e objetos não referenciados, se a ferramenta executar comandos Git com escopo amplo.

Quem foi afetado e para que serve

O cenário afeta principalmente desenvolvedores que usam agentes de código em repositórios proprietários, equipes que trabalham com monorepos e organizações que permitem ferramentas de IA em máquinas corporativas sem uma política de saída de dados. O agente pode ser útil para analisar código, sugerir mudanças, navegar por dependências e automatizar tarefas. Essas funções exigem contexto, mas não exigem automaticamente o histórico completo nem o acesso irrestrito à máquina.

Projetos com código-fonte fechado, dados de clientes, integrações internas, scripts de deploy e arquivos de infraestrutura merecem atenção especial. Uma exposição não precisa conter uma senha válida para causar prejuízo. Arquitetura, nomes de serviços, endpoints internos e mensagens de incidentes podem facilitar engenharia social e novos ataques.

Como identificar e fazer a detecção

Comece pelo inventário. Liste quais agentes estão instalados, quais versões são usadas, quais extensões têm acesso ao editor e quais processos podem sair para a internet. Em seguida, execute o agente em um repositório de teste com um histórico sintético e monitore a máquina com uma captura de DNS e HTTPS. O objetivo é descobrir comportamento observável sem colocar dados reais em risco.

No endpoint, procure processos filhos que executem git log, git rev-list, git bundle, git archive ou cópias recursivas de .git. Audite conexões feitas durante a abertura de um projeto e compare o volume enviado com a tarefa solicitada. No proxy corporativo, registre domínio de destino, identidade do usuário, processo quando disponível, horário e quantidade de dados. Um alerta útil combina leitura de .git com upload externo em uma janela curta.

Também vale pesquisar nos repositórios por tokens e chaves que já tenham sido revogados. Ferramentas como gitleaks e detect-secrets podem ajudar na triagem, mas não substituem a rotação de credenciais. O histórico deve ser tratado como fonte de evidência e não como uma área confiável apenas porque o arquivo não aparece no HEAD.

Como se proteger e mitigar

Adote o princípio do menor privilégio. Execute agentes em um ambiente isolado, com um checkout sanitizado, sem credenciais de produção, sem acesso desnecessário ao diretório pessoal e com egress de rede limitado a destinos aprovados. Quando o agente só precisa da árvore atual, forneça uma cópia exportada sem a pasta .git. Quando o histórico é indispensável, use um repositório de teste com dados removidos.

Remova segredos do Git com um processo apropriado, revogue os valores expostos e gere novos tokens. Não confie apenas em apagar o arquivo e fazer um novo commit. Proteja branches e configure hooks ou verificações no CI para bloquear credenciais antes do push. No ambiente corporativo, documente quais dados podem ser enviados para cada fornecedor e ofereça uma configuração para desativar telemetria ou sincronização de workspace.

Controles de rede completam a defesa. Um firewall de saída, um proxy com autenticação e uma política de DNS ajudam a reduzir uploads não autorizados. Em notebooks, o EDR deve registrar a cadeia de processos e permitir investigar qual aplicação iniciou a conexão. Para tarefas sensíveis, prefira execução offline ou em uma rede sem acesso a dados de produção.

Comparação com casos e alternativas anteriores

O problema é semelhante ao de extensões de editor que enviam contexto para serviços de completions, ferramentas de diagnóstico que coletam arquivos e sistemas de backup que incluem diretórios ocultos por padrão. A diferença relevante é o alcance do histórico Git e a expectativa do usuário. Uma sugestão baseada no arquivo aberto pode ser previsível. A criação e transmissão de snapshots antigos exige uma explicação clara, consentimento e controles proporcionais.

Alternativas mais seguras incluem limitar o contexto a arquivos explicitamente selecionados, usar um modelo hospedado dentro da organização, fornecer uma API de análise com filtragem de segredos ou executar o agente em um container efêmero. Nenhuma alternativa é automaticamente segura. O contrato técnico deve informar retenção, treinamento, subcontratados, localização dos dados, exclusão e auditoria.

Análise técnica

O artigo original é uma fonte de relato e não substitui uma auditoria independente de cada versão do ZCode. Uma investigação responsável deve reproduzir o comportamento em laboratório, com uma conta sem privilégios e um repositório criado para o teste. Registre os comandos executados, os arquivos acessados e o tráfego gerado. Evite publicar tokens de teste que possam ser confundidos com credenciais reais.

O indicador mais importante é a combinação de operações locais e exfiltração. A leitura de .git, por si só, pode fazer parte de uma função de análise. O upload, a ausência de aviso e a retenção remota mudam o risco. Use allowlists de processos, regras de detecção no EDR e inspeção de proxy para confirmar o caminho dos dados. Se houver dúvida sobre a coleta, suspenda o uso em repositórios confidenciais até obter uma resposta verificável do fornecedor.

Impacto e consequências

O impacto potencial inclui perda de confidencialidade, exposição de propriedade intelectual, vazamento de dados pessoais e comprometimento de credenciais históricas. A consequência operacional pode aparecer meses depois, quando alguém encontra um token antigo em um commit e tenta reutilizá-lo contra um serviço que ainda não foi revisado. A investigação também pode exigir preservar logs, analisar contas e comunicar clientes ou autoridades conforme o caso concreto.

Além do aspecto técnico, existe uma questão de governança. O uso de um agente em código de clientes precisa estar coberto por políticas internas, avaliação de fornecedor e contratos adequados. Transparência sobre coleta e retenção ajuda a equipe a decidir quando a produtividade compensa o risco e quando uma tarefa deve permanecer em ambiente controlado.

Dicas práticas e boas práticas

Faça uma revisão rápida antes de abrir um repositório em um agente. Confirme que a branch não contém segredos, remova credenciais do ambiente, desative montagens desnecessárias, limite a rede e verifique o destino das requisições. Use um usuário sem privilégios administrativos e mantenha o sistema e o agente atualizados. Depois da sessão, revogue tokens temporários, apague o workspace efêmero e revise os logs.

Para equipes, crie uma matriz simples de classificação: público, interno, confidencial e regulado. Defina quais agentes podem ser usados em cada nível, quais domínios são permitidos e qual retenção é aceitável. Faça testes periódicos com repositórios canário que contenham marcadores não sensíveis. Se um agente tentar enviar o marcador fora da política, o controle deve bloquear a conexão e abrir um alerta.

Conclusão: o que fazer agora

O relato sobre o ZCode é um lembrete de que ferramentas de desenvolvimento podem ter acesso ao ativo mais valioso de uma empresa: o contexto completo do código. Não é necessário concluir que toda instalação é maliciosa para agir. Trate o agente como software de terceiros, reduza privilégios, limite dados e monitore a saída.

Como próximo passo, selecione um repositório de laboratório, reproduza o fluxo com dados sintéticos e documente quais arquivos e conexões aparecem. Depois, revise a política para repositórios reais, faça rotação de segredos que possam ter sido expostos e habilite alertas de leitura do histórico seguida de upload. A segurança melhora quando a equipe consegue medir o comportamento e interromper a coleta antes que um projeto confidencial seja enviado.