Grok Build vazou repositórios inteiros para a nuvem — o que aconteceu e o que fazer se você usou

Em 12 de julho de 2026, um pesquisador de segurança publicando sob o handle cereblab revelou que o Grok Build — o agente de código da SpaceXAI, concorrente direto do Claude Code — estava enviando repositórios Git inteiros dos desenvolvedores, incluindo histórico completo, chaves de API e senhas commitadas, para um bucket do Google Cloud Storage controlado pela SpaceXAI. Sem consentimento. Sem aviso. O botão que deveria proteger o usuário não fazia nada. Este artigo é a explicação técnica completa do que aconteceu, o que a xAI disse, o que a xAI fez de fato, e o que qualquer desenvolvedor que usou o Grok Build precisa fazer agora.

O que o Grok Build fazia — e por que era pior do que parecia

Todo agente de código precisa enviar alguma coisa para um modelo remoto rodar. O Claude Code envia os arquivos que a tarefa precisa, sob demanda, com controles claros de escopo. O Codex CLI da OpenAI faz parecido. O Gemini idem. O que o Grok Build fazia era diferente: em vez de enviar só o que precisava, ele empacotava o repositório inteiro como um Git bundle e mandava para o servidor da xAI — ao entrar em modo idle, mesmo antes de qualquer prompt do usuário.

O Git bundle inclui o histórico completo do repositório. Isso é decisivo: significa que arquivos removidos do working tree ainda existem no bundle. Uma chave de API que você commitou por engano, se deu conta 10 minutos depois e apagou — ela estava lá. Senha de banco de dados que ficou em um commit antigo e depois foi rotacionada, mas nunca reescrita da história — estava lá também.

Cereblab documentou o padrão com prova experimental: colocou um valor "canary" único (API_KEY=CANARY7F3A9-SECRET-should-not-leave) em um repositório de teste, executou o Grok Build, interceptou a comunicação com mitmproxy, e recuperou o Git bundle enviado. O canary estava lá. E mais: um arquivo que o agente foi explicitamente instruído a não abrir também apareceu.

O botão que não fazia nada

O CLI do Grok Build tinha um toggle chamado "Improve the model". Qualquer desenvolvedor razoável leria isso como: "se eu desligar, meus dados não vão para o modelo". A investigação de cereblab mostrou que com esse botão desligado, o upload continuava. A resposta do próprio servidor /v1/settings ainda retornava trace_upload_enabled: true.

Ou seja, existia uma confusão intencional ou negligente entre dois controles distintos:

• Toggle A: "seus dados são usados para treinar o modelo?" (o que estava exposto ao usuário)
• Toggle B: "seus dados são enviados para nosso servidor?" (o que NÃO estava exposto ao usuário)

O usuário achava que controlava B ao desligar A. Não controlava. Só depois de o caso viralizar no Hacker News em 14/07, a SpaceXAI introduziu um comando /privacy específico. Mesmo assim, o pesquisador confirmou que a correção real veio de uma flag global no servidor (disable_codebase_upload: true), não de mudança no CLI.

Comparação direta com Claude Code, Codex e Gemini

Um detalhe crucial da investigação: cereblab testou os concorrentes lado a lado. Rodou Claude Code, Codex CLI (OpenAI) e Gemini nos mesmos cenários de teste. Resultado: nenhum dos três enviou repositórios completos em cenários de teste em modo idle. A diferença arquitetural é clara — os concorrentes enviam apenas o que a tarefa precisa. O Grok Build tratava seu código como material de coleta por padrão.

A resposta da SpaceXAI — o que foi dito e o que foi feito

A empresa não emitiu comunicado formal de segurança. Toda a resposta veio por posts no X. Elon Musk escreveu em 13/07:

"Como medida de precaução, todos os dados de usuário que foram enviados para a SpaceXAI antes de agora serão completa e totalmente deletados. Zero coisa alguma permanecerá."

Em post separado, Musk pediu que os usuários continuassem enviando dados, dizendo que "alguma retenção ajuda com debugging". A contradição foi criticada por analistas de segurança.

Em 14/07, a conta oficial @SpaceXAI declarou que times enterprise em Zero Data Retention (ZDR) nunca tiveram código armazenado; que uso por API respeita ZDR; e que consumidores individuais podem rodar /privacy para desabilitar retenção e apagar dados sincronizados.

Em 16/07, a SpaceXAI abriu o código do Grok Build sob Apache 2.0, provavelmente para tentar reconstruir a confiança pela transparência. Um passo positivo — mas que também expõe: o código do upload de repositórios inteiros continua presente no binário atual, apenas dormente sob a flag do servidor.

Por que Zero Data Retention não protegeu todo mundo

Aqui está o ponto que a maior parte das reportagens deixou passar: o ZDR (Zero Data Retention) cobre times enterprise e uso via API key. Não cobre os usuários mais comuns do Grok Build: assinantes individuais do SuperGrok ou X Premium Plus — que são justamente a maior parte da base de desenvolvedores solo. Para esses, o único controle self-service é o comando /privacy, que foi introduzido depois de o problema virar público.

O que qualquer desenvolvedor que usou o Grok Build precisa fazer

Se você rodou o Grok Build antes de 12 de julho de 2026, siga esta lista independentemente do que os seus settings diziam:

1. Rotacione TODAS as credenciais que já estiveram em qualquer repositório em que você rodou o Grok Build. Isso inclui chaves de API, tokens de acesso, senhas de banco, tokens de cloud (AWS, GCP, Azure), tokens do GitHub, senhas SMTP, chaves de assinatura.
2. Não confie no working tree. O que importa é o que já existiu no histórico. Se você deu commit de uma chave e removeu depois, ela continua existindo no .git — e foi enviada.
3. Verifique o histórico com scanners: ferramentas como truffleHog, gitleaks, detect-secrets escaneiam o histórico completo procurando padrões de credencial. Rode em cada repositório que passou pelo Grok Build.
4. Habilite MFA em todas as contas relacionadas. Se uma credencial de acesso vazou, MFA é a última defesa antes do dano.
5. Revise logs de acesso. AWS CloudTrail, GitHub audit log, Google Cloud audit — qualquer atividade fora do padrão nas semanas anteriores merece investigação.
6. Considere trocar chaves de assinatura de código, se tinha alguma no repositório. Isso é caro (exige reassinar releases), mas é imprescindível.

Como escolher agente de código com segurança daqui pra frente

Este caso é o alerta que todo desenvolvedor precisava. Para escolher agente de código com segurança:

• Prefira agentes que enviam sob demanda, não que sincronizam por padrão. O Claude Code, por exemplo, é explícito sobre isso.
• Leia a documentação sobre retenção de dados antes de rodar em código real. Se a documentação é ambígua, considere isso um sinal vermelho.
• Rode primeiro em repositório de teste com canaries — valores identificáveis que não deveriam sair da sua máquina. Se saírem, você descobre antes de rodar em código real.
• Prefira controles com granularidade separada: um toggle para "usar meu código para treino" e outro para "enviar meu código ao servidor" precisam ser separados. Se são um só, você não tem controle real.
• Se possível, use Zero Data Retention. Se o produto não oferece, e você trabalha com código sensível, é motivo para reconsiderar o produto.

O contexto maior

Esse não é o primeiro problema de privacidade do Grok. Em 2025, a xAI usou dados de usuários do X para treinar o Grok sem consentimento — o que reguladores europeus classificaram como "muito provavelmente" violação da lei da UE. Um quarto das empresas europeias baniu o Grok em resposta. O escândalo do Grok Build acontece nesse histórico. Não é um evento isolado — é padrão. E entende-se: uma empresa que definiu "igualar o Claude" como missão interna (contexto explicado no artigo sobre a crise de identidade da SpaceXAI) tende a valorizar velocidade sobre governança de dados. O incidente do Grok Build é sintoma dessa cultura.

Resumo em uma linha