O Musk anunciou a abertura de código do Grok Build, permitindo aos programadores compilarem localmente. Acabou com o incêndio depois da tempestade de vazamentos?

xAI a disponibilizado integralmente, a 15 de julho, o código-fonte do agente de programação para terminal Grok Build, tornando-o open source no GitHub. Assim, os programadores podem compilar e verificar o código linha a linha no seu próprio computador, sem depender de computação em nuvem.
（Contexto: o Grok Build foi acusado de roubar e enviar a «pasta de utilizador inteira» para a nuvem sem autorização; os programadores ficaram em pânico: tudo foi exposto）
（Informação de fundo: a Musk xAI lançou o “Grok Build” para desafiar a Claude: até 8 agentes de IA em paralelo, com uma janela de contexto de 2 milhões de tokens）

Índice

Toggle

• Grok Build open source
• O código desdobrado: vazamento que não se consegue esconder
• Além do open source, o que ainda falta

De madrugada, hoje (16), Musk partilhou uma publicação afirmando que a SpacexAI já disponibilizou na íntegra o código do Grok Build no GitHub, permitindo que os programadores o compiliquem e verifiquem no seu próprio ambiente, linha a linha. No entanto, a “oferta” chegou num momento delicado: só estes dias o Grok Build foi investigado e os dados vazados foram revelados—senhas e chaves dos utilizadores foram empacotadas e enviadas silenciosamente para a nuvem.

Esta abertura do código é sinceridade ou é uma forma de apagar o incêndio?

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

— Elon Musk (@elonmusk) July 15, 2026

Grok Build open source

O Grok Build é um agente de programação nativo de IA para terminal lançado pela xAI (também conhecida como SpaceXAI) em maio de 2026. A oferta oficial destaca até 8 agentes de IA em execução paralela, 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, ao abrir integralmente o código-fonte do Grok Build no projeto xai-org/grok-build do GitHub, a xAI permite que os programadores o compilen localmente, modifiquem o ficheiro de configuração config.toml para usar inferência local e não precisem de enviar dados para a nuvem da xAI.

A oficial enquadrou este passo como uma resposta formal às críticas externas sobre privacidade e transparência. Em teoria, com o código-fonte publicado, qualquer pessoa pode verificar por si própria o que a ferramenta está efetivamente a fazer por trás, sem ter de confiar apenas no que a entidade afirma.

O código desdobrado: vazamento que não se consegue esconder

A tempestade que tem vindo a surgir recentemente tem origem na versão 0.2.93 do Grok Build. Uma investigadora de segurança em IA descobriu que, sempre que o Grok Build lê e processa um ficheiro, o trata como parte de um pedido de chamada ao modelo. A ferramenta esconde ainda uma via de upload independente em “backstage”: não envia apenas os ficheiros locais parciais de que a tarefa precisa, mas sim todo o repositório de código Git do utilizador, juntamente com o código completo do projeto e o histórico de alterações, empacotando-o como um Git bundle e carregando-o para o armazenamento na nuvem do SpaceXAI na Google. Os dados não passam por desidentificação.

Quão exagerado foi? Numa medição real, a tarefa em si só precisava de 192 KB de dados; ainda assim, o Grok Build carregou 5,1 GB—2,6 milhões de vezes o volume necessário. Além disso, foram empacotados e enviados também registos de operações, senhas do “backstage” e chaves de API. As “opções” de privacidade que a ferramenta afirma poder desligar não tiveram qualquer efeito no teste.

O primeiro movimento da xAI não foi publicar um pedido de desculpas. Em vez disso, de forma silenciosa, enviou uma correção do lado do servidor para bloquear uploads anómalos, sem publicar qualquer comunicado de segurança e sem mencionar nada nas notas de atualização da versão nova. Só quando Musk interveio pessoalmente é que a empresa prometeu publicamente eliminar de forma total e permanente todos os dados dos utilizadores previamente enviados, sem deixar cópias; para utilizadores não empresariais que não tenham ativado “zero data retention” (retenção zero de dados), a entidade disponibilizou um comando único, para os utilizadores apagarem por si próprios os dados recolhidos anteriormente.

Além do open source, o que ainda falta

As dúvidas permanecem muitas. As correções do lado do servidor só confirmam que funcionam num único dispositivo e numa única conta; se já terão sido aplicadas globalmente, a entidade não explicou. Além disso, ninguém confirma de forma independente se os dados foram realmente apagados.

Há especialistas que consideram que a solução definitiva deveria ser o servidor bloquear diretamente o upload do repositório de código inteiro, e não depender de o utilizador executar instruções manuais como remediação. A reação da comunidade também foi direta: é difícil confiar num assistente de IA que tem acesso de nível máximo ao computador. Para empresas e programadores independentes que entregam todo o ambiente de desenvolvimento a agentes de IA, este caso é um sinal de alerta: quanto maior a autorização de uma ferramenta, maior deve ser a exigência de mecanismos de auditoria mais rigorosos para garantir o controlo.