Grok Build enviou repositórios inteiros à xAI, aponta análise

A xAI enviou arquivos lidos e repositórios inteiros pelo Grok Build, sua CLI de programação, segundo uma análise de tráfego publicada por @cereblab sobre a versão grok 0.2.93. O teste encontrou um arquivo .env com segredos transmitido sem alteração e um upload de 5,10 GiB por POST /v1/storage. O caso importa para equipes que usam código privado, credenciais ou histórico Git em máquinas ligadas ao serviço.

A análise não descreve uma inferência indireta. O autor capturou endpoint, método HTTP, código de resposta, volume de bytes e host no próprio computador, usando um repositório descartável com segredos falsos. “O segredo aparece em dois canais”, escreveu @cereblab: no turno do modelo, por POST /v1/responses, e em um arquivo session_state enviado por POST /v1/storage, aceito com HTTP 200.

O dossiê registra zero pontos e zero comentários no Hacker News. Portanto, não há lados representados por comentários nem citações de leitores para comparar. O debate disponível se resume ao contraste entre a promessa implícita de uma CLI que trabalha sobre um repositório local e o comportamento observado no fio de rede.

O modelo leu uma parte; o upload levou o repositório

O teste separa duas ações que uma equipe precisa tratar como diferentes. A primeira envia o conteúdo dos arquivos que o agente abriu para o endpoint de respostas. A segunda empacota o workspace e manda o repositório inteiro, com arquivos rastreados e histórico Git, mesmo quando o agente não os lê.

A evidência mais direta veio de um prompt que dizia “reply OK, do not read any files”, ou “responda OK, não leia nenhum arquivo”. Ainda assim, o Grok enviou um git bundle por POST /v1/storage, recebeu HTTP 200 e permitiu recuperar, do pacote capturado, o arquivo src/_probe/never_read_canary.txt com seu marcador único. O pacote também continha o histórico completo do Git.

O teste em um repositório de 12 GB reforçou a distinção. O canal de armazenamento moveu 5.10 GiB, todos com HTTP 200, antes de o teste ser interrompido; o canal do modelo moveu 192 KB. A diferença chegou a aproximadamente 27.800 vezes. “Isso fixa o upload no codebase, não no que foi lido”, afirmou @cereblab.

A análise também relata que nenhum upload de armazenamento falhou. Os únicos códigos diferentes de 200 foram respostas 402 e 429 ligadas à cota de uso do modelo em /v1/responses, além de um 404 sem relação com o limite de armazenamento. Para quem decide liberar a ferramenta, o ponto técnico não é apenas controlar quais arquivos o agente acessa: o pacote do repositório forma um caminho separado.

O destino aparece no binário e a política ainda deixa perguntas

O destino identificado foi o bucket do Google Cloud Storage grok-code-session-traces, e não um bucket AWS S3. O nome aparece no binário e em um metadata.json capturado, com a forma gs://grok-code-session-traces/…. O mecanismo estava ativo por padrão no teste.

@cereblab também escreveu: “Não encontrei esse mecanismo exposto nos materiais de instalação ou quickstart da CLI”. A própria análise limita a afirmação: isso não equivale a uma auditoria completa da documentação. Ainda assim, a diferença entre o que a interface apresenta e o que o cliente envia merece revisão antes de uma adoção em repositórios sensíveis.

Uma atualização datada de 2026-07-14 informa mudanças posteriores ao teste original. A xAI desativou o upload no servidor com disable_codebase_upload: true, adicionou /privacy opt-out e, segundo o autor, Elon Musk se comprometeu a apagar os dados enviados. O teste do opt-out, porém, indicou uma configuração de retenção, não um bloqueio do que a CLI transmite; a conclusão sobre a exclusão completa ainda não estava confirmada.

O caso não resolve sozinho como a xAI opera hoje, porque o teste mira grok 0.2.93 e a própria página registra alterações posteriores. Ele deixa, porém, uma exigência objetiva para quem administra código: inspecionar o tráfego, confirmar o comportamento da versão instalada e separar retenção de envio. Sem essas respostas, a decisão envolve aceitar que arquivos não lidos, histórico Git e possíveis segredos podem sair da máquina.