Grok Build enviava repositórios INTEIROS para Google Cloud — e o /privacy não impedia

O Grok Build, ferramenta de IA para programação da SpaceXAI (antiga xAI), enviava repositórios Git completos de desenvolvedores (histórico, credenciais e tudo) para o Google Cloud sem consentimento explícito. Um pesquisador descobriu que o toggle de privacidade “zero data retention” e o comando /privacy não impediam o upload. Elon Musk prometeu deletar os dados, mas especialistas questionam a transparência da empresa.

Se você usa Grok Build para programar, seus repositórios podem ter ido parar no Google Cloud sem você saber. Uma investigação conduzida pelo pesquisador de segurança Cereblab, publicada em 12 de julho pelo The Register, revelou que a CLI da ferramenta enviava o código-fonte completo dos usuários (histórico do Git, secrets e arquivos .env) para um bucket do Google Cloud Storage. O volume de dados enviados era aproximadamente 27.800 vezes maior do que o necessário para a tarefa de codificação.

O que o Grok Build enviava exatamente?

A análise em nível de rede mostrou que o Grok Build, versão 0.2.93, empacotava o repositório inteiro do desenvolvedor e o transferia para um servidor no Google Cloud: mesmo quando a tarefa exigia apenas alguns arquivos. Isso significa que todo o histórico de commits, branches, credenciais de acesso e variáveis de ambiente trafegavam para a nuvem.

Os dados expostos incluem:

• Código fonte proprietário — a base inteira, não só o arquivo sendo editado
• Vulnerabilidades de segurança — falhas não corrigidas no código
• Credenciais e secrets — tokens, senhas, chaves SSH em .env e config
• Histórico completo do Git — quem fez o quê e quando, incluindo revisões antigas com dados sensíveis

O Dr. Lukasz Olejnik, pesquisador de segurança e privacidade do King’s College London, classificou a retenção como “excessiva”. O especialista já assessorou o Conselho da Europa em privacidade digital e seu parecer dá peso à gravidade do caso.

O toggle de privacidade que não fazia nada

O Grok Build tem uma opção chamada “zero data retention” (ZDR) e um comando /privacy que, segundo a documentação, impediria a retenção de dados. A investigação mostrou que esses controles não impediam o upload do repositório. O toggle controlava apenas a retenção da sessão de chat — os dados do código continuavam subindo.

A própria xAI confirmou ao pesquisador que o /privacy era um “per-session retention toggle, not the switch that fixed this”. Ou seja: um controle de retenção por sessão, não a chave que resolveria o problema.

O upload foi desabilitado depois via uma flag no servidor: sem changelog, sem security advisory, sem comunicado oficial. A versão mais recente (0.2.98, de 12 de julho) não menciona o comportamento de upload em lugar nenhum.

A resposta de Elon Musk

Elon Musk afirmou que “privacy settings are always respected”, mas simultaneamente pediu que usuários mantivessem seus dados na plataforma para debugging. Em 14 de julho, depois que a história atingiu a front page do Hacker News, Musk prometeu a exclusão de todos os dados enviados anteriormente.

Sam Altman, CEO da OpenAI, chamou o caso de “concerning” (preocupante), um comentário raro vindo de um CEO de IA concorrente.

O problema: até agora, não há auditoria pública independente que confirme a exclusão dos dados. A promessa de Musk, sem evidência verificável, deixa os desenvolvedores no escuro.

O que isso significa para devs brasileiros

Cada vez mais, devs brasileiros adotam assistentes de IA para acelerar entregas e prazos apertados. O problema é que a confiança cega nessas ferramentas pode expor código fonte de startups, clientes e projetos pessoais. Quando uma CLI como o Grok Build sobe o repositório inteiro sem aviso, não é só o código do desenvolvedor que vaza — é o código dos clientes dele também.

O Brasil tem a LGPD, que exige transparência no tratamento de dados pessoais. Código fonte não é “dado pessoal” nos termos da lei, mas credenciais e informações de infraestrutura podem se enquadrar como dados sensíveis. Para empresas brasileiras que usam IA no desenvolvimento, o caso reforça a necessidade de auditar o que cada ferramenta envia para a nuvem.

Vale lembrar que a Microsoft está usando IA para reforçar a segurança no Windows — um exemplo de uso positivo da tecnologia. O caso Grok Build mostra o outro lado: a mesma IA que pode proteger também pode expor.

Análise: um padrão preocupante

O caso não é um deslize isolado. Ele revela uma decisão arquitetural. Enviar 27.800 vezes mais dados do que o necessário não é acidental; é a ausência de qualquer filtragem no que sobe para a nuvem.

A diferença entre “enviar o arquivo que estou editando” e “enviar o repositório inteiro com histórico” é grande demais para ser um bug. É uma escolha de design que prioriza a conveniência da empresa (debugging, treinamento de modelo) sobre a privacidade do usuário.

Para desenvolvedores, a lição é direta: ferramentas de IA não são caixas-pretas confiáveis. Antes de adotar qualquer CLI, vale monitorar o tráfego de rede, entender a política de dados e, sempre que possível, usar soluções locais para código sensível.