Elon Musk anuncia o código aberto do Grok Build, permitindo que desenvolvedores o compile localmente; apaga incêndio após a tempestade de vazamentos?

xAI em 15 de julho abriu totalmente o código-fonte do agente de programação para terminais Grok Build no GitHub, permitindo que desenvolvedores compilem e inspecionem o código linha por linha localmente, sem precisar mais confiar em computação em nuvem.
（Contexto: o Grok Build foi vítima de uma “invasão e roubo” em que usuários tiveram “todo o diretório home” carregado para a nuvem; desenvolvedores ficaram assustados: tudo foi vazado）
（Detalhe de fundo: o Elon Musk xAI lançou o “Grok Build” para desafiar o Claude: até 8 agents de IA em paralelo, com janela de contexto de até 2 milhões de tokens）

Sumário

Toggle

• Grok Build  aberto ao código
• Código-fonte espalhado, vazamento que não dá para esconder
• Além do open source, o que ainda falta

Nesta madrugada de hoje (16), Elon Musk compartilhou um post dizendo que a SpaceXAI já disponibilizou o código completo do Grok Build no GitHub, permitindo que desenvolvedores compilem e inspecionem linha por linha em sua própria máquina. Porém, o timing desse “presente” é delicado: apenas nestes dias o Grok Build passou a ser investigado e surgiram revelações de dados vazados, incluindo senhas e chaves de usuários, que foram discretamente empacotadas e enviadas para a nuvem.

Essa abertura do código é uma demonstração de boa-fé, ou um “incêndio sendo apagado”?

Grok Build is now open source https://t.co/LbGepmRB3l

— Elon Musk (@elonmusk) July 15, 2026

Grok Build  aberto ao código

Grok Build é um agente de programação nativo para terminais baseado em IA lançado pela xAI (ou chamada de SpaceXAI) em maio de 2026. A promessa oficial é rodar, ao mesmo tempo, até 8 agents de IA em paralelo, com uma janela de contexto de até 2 milhões de tokens, com o objetivo de desafiar o Claude Code da Anthropic e o Cursor.

Agora, a xAI abriu o código-fonte completo do Grok Build para o projeto xai-org/grok-build no GitHub. Com isso, desenvolvedores podem compilar e ajustar configurações localmente no arquivo config.toml para executar com inferência local, sem precisar enviar dados para a nuvem da xAI.

A empresa posicionou esse passo como uma resposta formal às críticas sobre privacidade e transparência por parte do público. Em teoria, após a publicação do código, qualquer pessoa consegue verificar por conta própria o que a ferramenta realmente faz por trás, sem depender apenas do discurso oficial.

Código-fonte espalhado, vazamento que não dá para esconder

A tempestade recente teve como ponto de partida a versão 0.2.93 do Grok Build. Um pesquisador de segurança em IA descobriu que, sempre que o Grok Build lê e processa um arquivo, ele trata isso como parte de uma solicitação de chamada ao modelo. Dentro da ferramenta, havia ainda um canal independente de upload em segundo plano: não era apenas enviar os arquivos locais parciais necessários para a tarefa, mas empacotar todo o repositório de código do usuário em Git — junto com o código completo do projeto e o histórico de alterações — em um Git bundle e enviá-lo para o espaço de armazenamento do SpaceXAI no Google Cloud, sem qualquer desidentificação dos dados.

Quão grande foi o exagero? Em um teste, a tarefa realmente exigia apenas 192 KB de dados, mas o Grok Build enviou 5,1 GB — 26 mil vezes mais do que o necessário. Junto do pacote, também foram enviados registros de operação, senhas do back-end e chaves de API. As “chaves de privacidade” que a ferramenta dizia que poderia desligar, no teste, não surtiram efeito algum.

O primeiro movimento da xAI não foi pedir desculpas publicamente, mas sim empurrar silenciosamente um reparo no lado do servidor para bloquear uploads anômalos, sem publicar um comunicado de segurança e sem mencionar o assunto nas notas de atualização da nova versão. Só depois de Elon Musk intervir pessoalmente, ele fez um compromisso público de apagar totalmente e permanentemente todos os dados de usuários enviados anteriormente, sem deixar backups; para usuários não corporativos que não ativaram retenção zero de dados, a empresa forneceu um comando único para que os usuários apaguem por conta própria os dados coletados previamente.

Além do open source, o que ainda falta

Ainda há muitas dúvidas. O reparo no lado do servidor, por enquanto, só confirmou funcionar em um único dispositivo e em uma única conta; se já está efetivamente em escala global, a empresa não explicou. Também não há como confirmar, por auditoria independente de terceiros, se os dados realmente foram apagados.

Especialistas acreditam que a solução de verdade deveria ser impedir diretamente, no lado do servidor, o upload de um repositório inteiro de código — e não depender de correções manuais com comandos pelos usuários. A reação da comunidade foi bem direta: é difícil confiar em um assistente de IA que tem a maior permissão sobre o computador. Para empresas e desenvolvedores independentes que entregam todo o ambiente de desenvolvimento a agents de IA, o episódio funciona como um alerta: quanto maior a autorização da ferramenta, mais rígidos precisam ser os mecanismos de auditoria para garantir segurança.