Incidente do instantâneo Git do ZCode: o que os agentes de programação com IA podem ver, carregar e recordar

O incidente de carregamento de repositórios do ZCode é maior do que uma única ferramenta de programação. Expõe uma questão de segurança à qual os programadores precisam cada vez mais de responder antes de dar a um agente de IA acesso a um projeto: “acesso ao repositório” significa o ficheiro atual, a árvore de trabalho ou anos de histórico do Git?

Essa distinção é importante porque o .git pode conter informações que já não são visíveis na base de código atual, incluindo segredos eliminados, versões antigas do código-fonte, reflogs, recursos LFS e histórico local de branches. O ZCode afirma que o comportamento de carregamento afetado foi corrigido, mas o incidente deixa uma lição duradoura: os agentes de programação de IA precisam de limites de dados explícitos, não apenas de autorização para “aceder ao repositório”.

O Que Aconteceu Realmente com o ZCode?

Em 18 de setembro de 2026, o programador ferstar publicou uma investigação de engenharia reversa do ZCode 3.12.3, depois de notar ficheiros inesperadamente grandes no diretório de dados local da aplicação.

De acordo com a investigação original, o cliente criava instantâneos encriptados do espaço de trabalho que podiam incluir ficheiros de código-fonte, bem como .git, objetos Git LFS, reflogs e metadados do repositório. O cliente também continha um fluxo para obter credenciais de carregamento e enviar arquivos encriptados para o Alibaba Cloud OSS.

O ZCode reconheceu posteriormente os carregamentos de dados de repositórios associados à indexação da base de código e ao Repo Wiki, pediu desculpa, afirmou que o comportamento tinha sido corrigido e anunciou planos para uma revisão de código aberto e por terceiros. A cobertura contemporânea reproduziu os principais pontos da resposta do ZCode.

Esta é a primeira lacuna de informação importante a esclarecer: o incidente foi real, mas alguns resumos virais exageraram o que foi efetivamente transferido.

O Repositório Privado de 313 MB Chegou Mesmo a Ser Carregado?

Não.

O instantâneo do projeto comercial continha aproximadamente 42 000 ficheiros e produziu um arquivo encriptado de cerca de 313 MB. De acordo com a atualização do investigador de 19 de setembro, permanecia num pendente estado após 564 tentativas falhadas, porque excedeu o limite de carregamento. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Um repositório público separado e mais pequeno chegou efetivamente ao serviço. Continha 538 ficheiros e produziu um payload encriptado muito mais pequeno.

A conclusão correta não é, portanto, “todos os repositórios ZCode foram carregados”. É que o cliente antigo continha um mecanismo funcional de carregamento de repositórios, cujo sucesso efetivo dependia do snapshot.

Porque É Que o Diretório `.git` É a Parte Mais Importante Deste Incidente

No grande snapshot do investigador, a maior parte do payload não era código-fonte atual.

Isto significa que aproximadamente 86.6% do snapshot provinha de .git. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Isto altera completamente a interpretação de segurança.

Um agente de IA que leia a árvore de código-fonte atual pode ver aquilo que o programador decide manter atualmente. Aceder ao histórico do Git pode revelar aquilo que o programador pensava já ter removido.

A possível exposição histórica inclui:

• ficheiros de código-fonte eliminados
• chaves de API ou tokens antigos
• endpoints internos anteriores
• funcionalidades abandonadas
• configuração histórica
• atividade de branches locais
• estados existentes apenas no reflog
• ativos LFS históricos de grandes dimensões

A documentação do reflog do Git explica que os reflogs registam valores anteriores das referências locais. Esses registos podem existir localmente mesmo quando o histórico correspondente nunca foi enviado para um repositório remoto.

Isto dá-nos uma regra de segurança útil:

“Ler o meu projeto” e “ler o meu histórico do Git” devem ser permissões separadas.

Porque É Que os Segredos Eliminados Podem Continuar a Existir Depois de os Remover do Código

Eliminar uma credencial do ficheiro mais recente não significa necessariamente eliminá-la do Git.

Um programador pode submeter acidentalmente uma chave de API, removê-la na submissão seguinte e ver um ficheiro atual completamente limpo. O blob anterior pode continuar acessível através do histórico do repositório.

A orientação do GitHub sobre a remoção de dados sensíveis recomenda explicitamente revogar ou alterar as credenciais expostas antes de reescrever o histórico.

Essa ordem é importante:

1. Invalide a credencial.
2. Remova o histórico sensível, quando apropriado.
3. Impeça que o segredo volte a ser submetido.

Para agentes de programação de IA, isto significa que uma funcionalidade ciente do histórico pode aceder a dados que uma vista normal do editor já não expõe.

Isto também explica por que razão um agente só de leitura não apresenta automaticamente um risco reduzido. O acesso só de leitura ainda pode divulgar informações valiosas se o âmbito do seu sistema de ficheiros for demasiado amplo ou se o conteúdo obtido for enviado para um modelo remoto.

O contexto do modelo, a telemetria, o treino e os carregamentos do repositório não são a mesma coisa

Outra lição importante é que um único seletor de “privacidade” não pode representar todos os tipos de fluxo de dados que uma ferramenta de programação com IA pode ter.

A versão afetada do ZCode é importante porque o investigador afirmou que desativar a opção de otimização/treino não desativava o pipeline de snapshots separado. O relatório também alegou que, nessa versão, o seletor de indexação de snapshots do repositório não impedia as tentativas de empacotamento e carregamento. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Isto conduz a uma regra que se aplica muito para além do ZCode:

“Não treinar com os meus dados” não significa “não transmitir os meus dados”.

Um modelo na cloud continua a precisar de contexto para a inferência. A telemetria pode passar por outro endpoint. A sincronização pode manter outra cópia. A indexação do repositório pode ter o seu próprio fluxo de dados.

A mesma distinção aplica-se quando um agente de IA local utiliza ferramentas na cloud: a privacidade depende dos dados exatos que atravessam a fronteira, não simplesmente do local onde é executado o processo principal do agente.

A encriptação não responde à pergunta mais importante sobre privacidade

O snapshot do ZCode afetado foi encriptado antes do carregamento.

O relatório de engenharia reversa descreve encriptação AES-256-CTR para o arquivo e encapsulamento RSA-OAEP-SHA256 para a chave simétrica. A chave pública RSA foi fornecida pelo serviço, enquanto a chave privada correspondente não foi armazenada localmente. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Isso protege os dados de forma diferente da encriptação de ponta a ponta controlada pelo utilizador.

Por isso, dizer que “o repositório foi encriptado” é incompleto.

A pergunta mais importante é:

quem pode desencriptá-lo?

Este mesmo princípio aplica-se a RAG privado, cópias de segurança na nuvem, memória de IA e qualquer sistema que alegue que os dados estão protegidos por estarem encriptados.

De que acesso ao repositório precisa realmente um agente de programação?

Os agentes de programação precisam legitimamente de mais contexto do que o preenchimento automático tradicional. Uma refatorização de todo o repositório pode exigir muitos ficheiros. Um agente de depuração pode precisar de testes, metadados de dependências, estado do Git e saída da compilação.

Mas “o agente pode precisar de um contexto amplo” não implica que “todas as funcionalidades devam receber todos os bytes do repositório”.

Esta é uma versão de acesso aos dados do mesmo princípio utilizado num limite de confiança na execução de ferramentas: a capacidade do modelo para solicitar algo não deve conceder automaticamente autoridade para aceder ou exportar tudo o que esteja nas proximidades.

Para agentes de programação, precisamos de dois limites independentes:

• Limite das ações: o que pode o agente alterar ou executar?
• Limite dos dados: o que pode o agente ler ou enviar?

Um agente sem permissão de escrita ainda pode criar uma exposição grave da privacidade se as respetivas permissões de leitura e de rede forem irrestritas.

O que mudou no ZCode após o incidente?

O incidente não deve ser descrito como se o mesmo comportamento existisse nas versões atuais do ZCode.

Numa inspeção posterior do ZCode 3.14.0, o investigador comunicou que o ficheiro auxiliar de carregamento anterior tinha sido removido e que o antigo endpoint de credenciais devolvia 404. O caminho inspecionado mantinha a funcionalidade de pontos de verificação locais sem o mecanismo anterior de carregamento remoto. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

A atual documentação da Wiki do repositório também descreve um limite de dados muito mais restrito.

Indica que o contexto da Wiki exclui:

• .git
• diretórios de dependências
• saída da compilação
• caches
• estado local de execução
• suportado .gitignore exclusões
• ficheiros de configuração suspeitos de conter dados sensíveis
• destinos de ligações simbólicas

A saída da Wiki do repositório é documentada como dados locais da aplicação, e não como conteúdo escrito de volta no repositório.

Isto é materialmente diferente do comportamento de instantâneo comunicado na versão 3.12.3.

O código aberto é suficiente para tornar privado um agente de programação?

Não.

O código aberto pode facilitar a auditoria de um cliente, mas uma aplicação de código aberto ainda pode enviar código-fonte para modelos na nuvem, carregar telemetria, sincronizar o estado ou depender de armazenamento controlado pelo fornecedor.

A lista de verificação mais útil é:

É por isso que uma arquitetura de IA privada é definida mais pelo seu fluxo de dados do que pelo facto de a licença do software ser, por acaso, de código aberto.

Como devem os programadores auditar um novo agente de programação com IA?

Os programadores não precisam de fazer engenharia reversa de todas as aplicações, mas um agente novo não deve receber um repositório comercial sensível como primeiro ambiente de teste.

1. Leia a documentação sobre o tratamento de dados. Separe inferência, telemetria, treino, indexação, sincronização e cópia de segurança.
2. Verifique as regras de exclusão. Procure especificamente .git, .env, ficheiros ignorados, dependências, credenciais e ligações simbólicas.
3. Comece com um repositório descartável. Utilize primeiro código não sensível.
4. Inspecione o armazenamento local da aplicação. Caches ou instantâneos inesperadamente grandes podem revelar um âmbito de dados oculto.
5. Observe o tráfego de saída. As firewalls, os registos de DNS, os proxies ou os routers podem identificar serviços remotos.
6. Utilize ficheiros canário inofensivos. Teste se ficheiros não relacionados entram no contexto do modelo ou do carregamento.
7. Conceda primeiro as permissões mais restritas. Amplie-as apenas quando uma tarefa específica o exigir.

É também aqui que o design de agentes com privilégios mínimos é útil, desde que “só de leitura” seja combinado com caminhos restritos e dados de saída controlados, em vez de uma visibilidade ilimitada do repositório.

O que um agente de programação local por predefinição deve fazer de forma diferente

Local por predefinição não significa que todas as tarefas tenham de ser executadas offline.

Significa que os dados locais permanecem, por predefinição, dentro do limite de confiança local, e que a transmissão externa é deliberada, e não incidental.

Este princípio é mais abrangente do que a programação. Um fluxo de trabalho de IA verdadeiramente local tem de manter o seu percurso de dados crítico local de ponta a ponta; instalar um modelo localmente não é suficiente se os embeddings, a indexação, a autenticação ou o processamento de ficheiros dependerem silenciosamente de um serviço remoto.

Nos sistemas híbridos, o padrão mais seguro consiste em manter os ficheiros privados atrás de um serviço local e expor apenas o contexto mínimo necessário às ferramentas remotas aprovadas. É a mesma abordagem utilizada ao conceber um agente que utiliza serviços na nuvem sem expor todo o sistema de ficheiros local.

A lição mais importante: o acesso ao repositório é uma permissão de segurança

A lição duradoura da ZCode não é “nunca utilize agentes de programação na nuvem”. É que o acesso ao repositório se tornou, por si só, uma permissão de segurança.

Um agente de programação moderno pode combinar:

• leitura do projeto completo
• integração com o Git
• execução no terminal
• acesso ao navegador
• modelos remotos
• tarefas em segundo plano
• memória de longo prazo
• edição autónoma de ficheiros

Isso significa que os programadores precisam de rever mais do que os comandos que um agente pode executar.

Também precisam de perguntar:

• Que ficheiros consegue observar?
• Até que ponto do histórico consegue recuar?
• Quais desses dados saem da máquina?
• Que serviço os recebe?
• Durante quanto tempo são retidos?
• Quem pode desencriptá-los?

Para os agentes de programação com IA, a privacidade já não se resume a saber se o modelo treina com o seu código. Trata-se de saber se o limite de dados do agente corresponde à tarefa que realmente lhe pediu para executar.