Aviso do programador: Grok Build enviou toda a pasta pessoal para a xAI, deixando todas as chaves SSH e bases de dados de passwords totalmente expostas

Em 13 de julho, o developer A Green Being publicou no X uma captura de ecrã dos logs de unified.json, acusando a ferramenta de desenvolvimento Grok Build, da xAI do empresário Elon Musk, de ter empacotado e enviado todo o diretório pessoal (home) dele para os servidores da xAI; o conteúdo vazado inclui a chave SSH pessoal dele, base de dados do gestor de passwords, documentos pessoais, fotos e vídeos — «absolutamente tudo foi exposto».

Evidência: captura de ecrã dos logs de A Green Being

(Fonte: A Green Being)

Com base na captura de ecrã unificada dos logs unified.json partilhada por A Green Being no X, o sistema efetivamente acionou um elevado número de pedidos repo_state.upload.start, e o caminho de envio apontava diretamente para o diretório pessoal daquele utilizador (/home/usuario); isto significa que o Grok Build, sem qualquer filtragem e exclusões explícitas de ficheiros, transmitiu todos os documentos locais — incluindo informação extremamente sensível (chaves SSH, base de dados do gestor de passwords, fotos, vídeos) — para o endpoint na nuvem da xAI.

A Green Being afirma que esta tragédia de privacidade aconteceu porque executou, por engano, a ferramenta Grok Build dentro do diretório pessoal (Home Directory). CyberSatoshi respondeu: «Tu estás ainda pior do que eu — tu correste o Grok diretamente no teu diretório pessoal.»

Recomendações de cibersegurança: evitar absolutamente executar no diretório pessoal; usar Sandbox e comandos de monitorização de logs

De acordo com as recomendações de especialistas em cibersegurança, para os developers que já usaram ou estão a considerar usar ferramentas auxiliares de desenvolvimento de IA como o Grok Build, devem ser adotadas as seguintes medidas de proteção:

· Evitar absolutamente executar este tipo de ferramentas no diretório pessoal ou no diretório raiz

· Usar um ambiente isolado: executar num ambiente virtual independente (Sandbox), em contentores Docker, ou criando uma conta de utilizador dedicada e limitada

· Monitorizar ativamente os logs: através de comandos no terminal (cat ~/.grok/logs/unified.json | grep repo_state.upload) para verificar se existe um comportamento anormal de envio de dados

· Verificar imediatamente os logs históricos: se já usou o Grok Build, deve consultar imediatamente os ficheiros de logs do Grok no próprio equipamento, para confirmar se houve vazamento de dados

Perguntas frequentes

Porque é que o Grok Build envia o diretório pessoal inteiro, e não apenas o código do projeto?

Segundo a informação divulgada, ao executar em segundo plano a operação de envio, o Grok Build não dispõe do mecanismo de exclusão de ficheiros adequado (por exemplo, ignorar automaticamente .gitignore ou ficheiros ocultos do sistema); quando o utilizador executa a ferramenta no diretório pessoal, a conceção de base da ferramenta trata o diretório pessoal como o ambiente de «contexto» inteiro e envia-o na totalidade, e não apenas os ficheiros de código. Trata-se de uma dupla falha: um defeito de conceção da ferramenta e um uso indevido por parte do utilizador.

Que riscos foram especificamente indicados no aviso anterior da CyberSatoshi?

Segundo a informação divulgada, no aviso anterior da CyberSatoshi (@XBToshi), o Grok Build envia em silêncio, em segundo plano, para a plataforma de nuvem Google (GCP) todo o repositório (Repository), o histórico de Git, e ficheiros ocultos como o .env contendo informações confidenciais como chaves de API; e referiu que isso é altamente provável de ser usado para treinos de modelos subsequentes; na altura, tinha apelado para que os developers verificassem imediatamente os ficheiros de logs do Grok no próprio equipamento.

Como posso verificar imediatamente se o meu computador já tem dados enviados pelo Grok Build?

Segundo a informação divulgada, é possível consultar os logs através dos seguintes comandos no terminal: cat ~/.grok/logs/unified.json | grep repo_state.upload; se no registo aparecerem muitas entradas de repo_state.upload.start e se o caminho de envio apontar para o diretório pessoal ou para o diretório raiz, isso indica que os dados foram enviados para a nuvem; recomenda-se parar imediatamente a utilização do Grok Build fora de um ambiente isolado e avaliar se as informações sensíveis relevantes (chaves SSH, chaves de API) precisam de ser alteradas de imediato.