O CLI de programação Grok Build, da xAI, estava enviando repositórios Git inteiros, com todo o histórico de commits, para um bucket do Google Cloud Storage operado pela própria xAI, e não apenas os arquivos necessários para a tarefa de codificação.
Um pesquisador que publica como cereblab, ao testar a versão 0.2.93, capturou uma dessas transferências, clonou o bundle do Git a partir da requisição interceptada e recuperou um arquivo que o agente havia sido instruído explicitamente a não abrir.
O envio ocorria por um canal separado do modelo em si, e a diferença de volume é difícil de contestar.
Em um repositório de 12 GB de arquivos que o modelo nunca leu, o tráfego de interação com o modelo para /v1/responses ficou em cerca de 192 KB, enquanto o canal de armazenamento para /v1/storage movimentou 5,10 GiB, uma diferença de aproximadamente 27.800 vezes entre o que o modelo precisava e o que saiu da máquina.
Essa transferência para armazenamento foi feita em 73 blocos de cerca de 75 MB cada, todos com retorno HTTP 200.
Nos testes de variação de tamanho feitos pelo pesquisador, o volume acompanhou o tamanho total do repositório.
O bucket de destino, grok-code-session-traces, aparece nomeado no binário e também em um metadata.json preparado, cujos caminhos por arquivo apontam para gs://grok-code-session-traces/.
O arquivo que não deveria ser lido era src/_probe/never_read_canary.txt, inserido com um marcador único.
Ao clonar o bundle capturado, o conteúdo foi recuperado integralmente, junto com todo o histórico de commits do repositório, e o mesmo teste foi repetido com sucesso em outro repositório, sem relação com o primeiro.
O que as capturas comprovam é transmissão, recebimento e armazenamento, não treinamento.
A análise não afirma que a xAI treinou o modelo com o código, que funcionários leram o conteúdo ou que arquivos ignorados pelo Git são sempre coletados.
O que aparece no tráfego é apenas arquivos rastreados e o histórico.
O caminho dos segredos é separado e mais simples.
Quando o Grok lê um arquivo, o conteúdo vai para a interação com o modelo, e um arquivo .env rastreado seguiu assim, sem redação, com valores de API_KEY e DB_PASSWORD-canary, inclusive.
O mesmo conteúdo também foi parar em um arquivo session_state destinado ao armazenamento.
Os segredos plantados eram falsos, então nada real vazou no teste.
Ainda assim, o comportamento é o problema: um arquivo de credenciais que o agente leu durante uma tarefa foi enviado e armazenado sem qualquer redação.
A configuração que a maioria dos desenvolvedores tentaria usar não resolveu nada.
Com a opção “Improve the model” desativada, o Grok ainda assim fez upload do repositório, e a resposta do próprio servidor em /v1/settings continuou retornando trace_upload_enabled: true.
Esse ajuste controla se seus dados serão usados para treinar o modelo.
Ele não controla se o seu código sai da máquina.
São dois controles diferentes, e apenas um deles estava visível para o usuário.
Todo agente de codificação em cloud precisa enviar parte do código-fonte para um modelo remoto funcionar, então o primeiro canal é esperado.
Já enviar o repositório rastreado inteiro e seu histórico representa um limite muito mais amplo do que enviar apenas os arquivos necessários para a tarefa.
Um repositório pode conter código proprietário, URLs internas, dados de clientes e credenciais que foram removidas da árvore de trabalho, mas continuam no histórico de commits.
Na comparação feita pelo próprio cereblab com outras ferramentas, Claude Code e Codex não enviaram nenhum bundle de repositório.
O Gemini não enviou nada em um teste ocioso, embora sua execução em uma tarefa real tenha sido bloqueada por cota antes de terminar.
O Grok Build foi a exceção.
Ainda assim, são ferramentas em cloud que enviam os arquivos que abrem, portanto a ideia de “somente local” é incorreta para qualquer uma delas.
Mas a coleta integral do espaço de trabalho foi algo específico do Grok Build.
Resposta da xAI
Em 13 de julho, o mesmo binário 0.2.93 deixou de fazer requisições de armazenamento.
O cereblab testou novamente seis vezes e não viu nenhum upload para /v1/storage, e o servidor passou a retornar disable_codebase_upload: true e trace_upload_enabled: false.
O desenvolvedor Peter Dedene relatou o mesmo retorno de flag para a sua conta, o que indica que a desativação não foi apenas uma observação isolada em uma única máquina do pesquisador.
O cliente testado continuou na versão 0.2.93 enquanto as configurações do servidor mudavam, o que mostra que se tratou de uma alteração do lado do servidor, e não de uma correção enviada em uma atualização.
A xAI não confirmou se a mudança vale para todas as contas nem se é permanente.
Até agora, a xAI tratou o caso no X, e não por meio de um comunicado de segurança ou de uma nota de changelog.
A conta @SpaceXAI afirmou que equipes corporativas com retenção zero de dados nunca têm código ou dados de trace armazenados, que o uso de chave de API respeita a ZDR, e que consumidores que ainda não ativaram isso podem executar /privacy no CLI para desativar a retenção e apagar dados já sincronizados.
Elon Musk foi além e afirmou que todos os dados de usuários enviados até agora seriam “completamente e totalmente apagados”, sem qualquer resíduo.
A ZDR cobre equipes corporativas e uso de API, portanto, para assinantes individuais, o comando /privacy é o controle disponível.
Para quem já usou a ferramenta, a medida não é esperar pela xAI.
O ideal é trocar imediatamente qualquer credencial que o Grok possa ter enviado: tudo o que ele leu, qualquer item em arquivo rastreado e também tudo o que estava no histórico de Git que o bundle carregou, inclusive segredos que você tenha commitado e depois removido.
Um arquivo que estava ignorado pelo Git e nunca chegou a ser commitado ficou fora do bundle.
Um arquivo commitado seguiu no histórico, e apagá-lo depois não o traz de volta.
Uma análise separada da versão 0.2.99 mostrou que o código de upload ainda estava no binário, apenas bloqueado pela flag do servidor, o que significa que a xAI pode reativá-lo sem lançar uma atualização.
A empresa ainda não explicou por que repositórios inteiros eram enviados por padrão, por quanto tempo eles eram mantidos nem quantos usuários foram afetados.
Desativar o treinamento não é garantia de que o seu código ficará na máquina, e vale conferir por conta própria o que saiu dela.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...