Grok Build enviou repositórios inteiros à xAI, aponta análise

A análise examinou o tráfego de uma máquina própria, usando um repositório descartável com segredos falsos. O Grok enviou arquivos lidos para POST /v1/responses, o canal da interação com o modelo. Também criou um Git bundle do workspace e o mandou para POST /v1/storage, que encaminhava os dados ao bucket grok-code-session-traces, no Google Cloud Storage. O armazenamento recebeu o conteúdo dos arquivos rastreados e o histórico Git.

O upload ignorou o que o agente recebeu ordem de ler

O teste mais direto usou o comando “responda OK, não leia nenhum arquivo”. Mesmo assim, o Grok enviou o repositório completo para /v1/storage e recebeu resposta HTTP 200. Ao clonar o bundle capturado, @cereblab recuperou src/_probe/never_read_canary.txt, um arquivo que o agente não deveria abrir, com seu marcador exclusivo intacto.

O comportamento também apareceu em um repositório de 12 GB com arquivos aleatórios que o agente nunca leu. O armazenamento transferiu 5.10 GiB, com todas as respostas HTTP 200, enquanto o canal de interação moveu apenas 192 KB. A proporção de aproximadamente 27.800 vezes indica que o volume veio do codebase inteiro, não do conteúdo usado pelo modelo durante a conversa.

A análise encontrou um segundo problema nos arquivos acessados pelo agente. O Grok transmitiu o conteúdo de um arquivo .env à xAI, sem mascarar os dados, em dois lugares: na chamada ao modelo e em um arquivo session_state aceito pelo endpoint de armazenamento. O teste não expôs credenciais reais, mas mostrou que o programa tratava o arquivo como conteúdo comum.

A página também registra o que os testes não provaram. Eles não mostraram uso de credenciais verdadeiras, nem que a xAI tenha usado o código para treinar modelos. Os erros observados foram uma cota de uso do modelo, com respostas 402 e 429, e um 404 sem relação com o limite do armazenamento. Nenhum upload de armazenamento falhou.

O debate discute ganho de contexto e risco de confiança

O caso alcançou 539 pontos e 229 comentários no Hacker News. freakynit reagiu ao envio amplo: “Ele envia o repositório inteiro — o conteúdo de cada arquivo rastreado mais o histórico do git — independentemente do que o agente lê. Meu Deus! [...] Isso é extremamente preocupante.” A crítica trata o upload como risco próprio, mesmo quando o modelo não consulta os arquivos.

jstanley ofereceu a principal justificativa técnica: “Uma razão para querer enviar toda a base de código é permitir que o modelo inspecione o codebase durante o ‘thinking’ sem voltar ao cliente para executar chamadas de ferramenta reais.” Ele também contestou o benefício: “Não é uma razão realmente ótima, porque qual é a desvantagem de voltar ao cliente?” O debate, portanto, não nega que o desenho possa reduzir chamadas de ferramenta; questiona se essa redução exige copiar o repositório inteiro.

Os participantes concordaram sobre a dificuldade de auditar agentes nativos proprietários. gitgud escreveu que “runners nativos proprietários de agentes de código, como claude-code, codex e grok-build, são muito perigosos para a privacidade”, porque o usuário não sabe qual “secret sauce” uma atualização acrescentará. A alternativa citada foi usar opencode com modelos acessados por API, com a ressalva de que o desempenho pode cair.

A xAI desativou o upload no servidor após a publicação, segundo a atualização de 2026-07-14. A empresa adicionou /privacy opt-out, mas o teste descrito classificou a opção como controle de retenção, não como bloqueio do envio. Elon Musk prometeu apagar os dados enviados antes, mas a conclusão dessa exclusão ainda não tinha confirmação.

Para uma equipe técnica, a pergunta em aberto não é apenas se o agente funciona. É preciso confirmar quais arquivos saem, quando saem, onde ficam e se uma atualização pode mudar esse fluxo. O caso não prova que o envio integral seja necessário para obter melhor desempenho. Prova que essa decisão exige confiança verificável no executor, no modelo e no provedor.