Upload de repositórios inteiros contradiz a promessa de "processamento local"

O pesquisador identificou dois canais de dados diferentes saindo da máquina do desenvolvedor :

• Canal de interação com o modelo (POST /v1/responses): os arquivos que o agente abria eram serializados nas requisições ao modelo. Esse é o comportamento esperado de um agente de código na nuvem.
• Canal de armazenamento (POST /v1/storage): o repositório inteiro era empacotado como um git bundle e enviado em blocos de cerca de 75 MB para um bucket do Google Cloud Storage chamado grok-code-session-traces .

A enorme diferença de volume prova que o upload não era motivado pelo que o agente lia. Em um repositório de teste de 12 GB, o canal de armazenamento transferiu 5,10 GiB em 73 blocos (todos com resposta HTTP 200), enquanto o canal de interação com o modelo transferiu apenas 192 KB — uma proporção de ~27.800× . Mesmo com a instrução "responda OK, não leia nenhum arquivo", a ferramenta fez upload do repositório inteiro como um git bundle; ao clonar o bundle capturado, foi possível recuperar um arquivo (src/_probe/never_read_canary.txt) que o agente recebeu ordens explícitas de não abrir, junto com todo o histórico de commits do Git .

Tipos de segredos e arquivos enviados sem nenhuma proteção

• Arquivos .env contendo chaves de API, senhas de bancos de dados e outras credenciais foram transmitidos literalmente, sem qualquer mascaramento ou ocultação, por ambos os canais . Em testes controlados, um arquivo de 48 KB com credenciais de banco de dados e chaves de API apareceu em texto puro no corpo da requisição .
• Todos os arquivos monitorados do repositório, mais o histórico completo do Git (todos os commits, branches e tags) foram empacotados e enviados . Isso significa que senhas removidas de commits antigos, mas que ainda podem existir nos dados enviados, continuam acessíveis.
• O mecanismo de upload foi identificado como uma biblioteca Rust própria da xAI (xai-data-collector) presente no binário, com caminhos de código como crates/codegen/xai-data-collector/src/gcs.rs e crates/codegen/xai-grok-shell/src/upload/ .
• Em uma base de código real de 12 GB com arquivos aleatórios que nunca foram lidos, o endpoint de armazenamento aceitou todos os uploads sem nenhuma rejeição por tamanho; as únicas respostas que não foram 200 foram erros de cota de uso do modelo (402/429), e não falhas de armazenamento .

A opção de privacidade não funciona

O pesquisador testou a opção "Melhorar o modelo" (Improve the model) e descobriu que ela não interrompeu os uploads .

• Depois de desativar a opção e reiniciar, o endpoint de configurações do servidor ainda retornava trace_upload_enabled: true .
• O canal de armazenamento continuou recebendo blocos de git bundle com respostas HTTP 200 .
• Existe uma opção de configuração disable_codebase_upload=true nas configurações do harness, mas sua relação com o comportamento do servidor não é documentada, e os testes do pesquisador mostraram que o servidor não respeitava as preferências do cliente .

Recomendações para desenvolvedores afetados

O pesquisador original e outras análises sugerem as seguintes medidas :

Ações imediatas para equipes que usaram o Grok Build CLI em repositórios privados:

• Rode todas as credenciais que existiam em qualquer arquivo .env, arquivo de configuração ou no histórico do Git dos repositórios usados com o Grok Build, pois elas podem ter sido transmitidas e armazenadas no bucket grok-code-session-traces do GCS .
• Audite o histórico do Git em busca de senhas que possam ter existido em commits antigos, já que o CLI enviou o histórico completo .
• Considere que os dados foram armazenados, e não apenas transmitidos — o servidor retornou HTTP 200 em todas as requisições de armazenamento, confirmando a aceitação .
• Pergunte à xAI se o bucket foi deletado, quais controles de acesso existiam e se um Acordo de Processamento de Dados (DPA) o cobria (nenhum foi publicado até a divulgação) .

Medidas de segurança arquitetural para qualquer agente de código:

• Execute agentes em contêineres ou máquinas virtuais montando apenas o diretório da tarefa, sem o diretório home, sem o agente SSH, sem o socket do Docker e sem expor diretórios de credenciais da nuvem .
• Implemente controles de saída de rede: permita endpoints de inferência de modelo e hosts de autenticação, mas negue uploads diretos para armazenamento de objetos genéricos. Alerte sobre transferências que excedam 100 MB .
• Use captura de pacotes em nível de sistema, logs de DNS e telemetria de rede de endpoints para detectar uploads feitos por processos de coordenação em segundo plano que contadores de bytes em primeiro plano não perceberiam .
• Teste prompts mínimos e máximos sob captura de rede — casos em que o agente recebe instruções para não ler arquivos são essenciais para detectar exfiltração além da janela de contexto .
• Execute pelo menos três cenários de prompt: (1) "responda OK, não leia nenhum arquivo", (2) leia um arquivo específico, (3) inspecione a linguagem do projeto — depois compare os bytes por endpoint .

Upload de repositórios inteiros contradiz a promessa de "processamento local"

O pesquisador identificou dois canais de dados diferentes saindo da máquina do desenvolvedor :

• Canal de interação com o modelo (POST /v1/responses): os arquivos que o agente abria eram serializados nas requisições ao modelo. Esse é o comportamento esperado de um agente de código na nuvem.
• Canal de armazenamento (POST /v1/storage): o repositório inteiro era empacotado como um git bundle e enviado em blocos de cerca de 75 MB para um bucket do Google Cloud Storage chamado grok-code-session-traces .

A enorme diferença de volume prova que o upload não era motivado pelo que o agente lia. Em um repositório de teste de 12 GB, o canal de armazenamento transferiu 5,10 GiB em 73 blocos (todos com resposta HTTP 200), enquanto o canal de interação com o modelo transferiu apenas 192 KB — uma proporção de ~27.800× . Mesmo com a instrução "responda OK, não leia nenhum arquivo", a ferramenta fez upload do repositório inteiro como um git bundle; ao clonar o bundle capturado, foi possível recuperar um arquivo (src/_probe/never_read_canary.txt) que o agente recebeu ordens explícitas de não abrir, junto com todo o histórico de commits do Git .

Tipos de segredos e arquivos enviados sem nenhuma proteção

• Arquivos .env contendo chaves de API, senhas de bancos de dados e outras credenciais foram transmitidos literalmente, sem qualquer mascaramento ou ocultação, por ambos os canais . Em testes controlados, um arquivo de 48 KB com credenciais de banco de dados e chaves de API apareceu em texto puro no corpo da requisição .
• Todos os arquivos monitorados do repositório, mais o histórico completo do Git (todos os commits, branches e tags) foram empacotados e enviados . Isso significa que senhas removidas de commits antigos, mas que ainda podem existir nos dados enviados, continuam acessíveis.
• O mecanismo de upload foi identificado como uma biblioteca Rust própria da xAI (xai-data-collector) presente no binário, com caminhos de código como crates/codegen/xai-data-collector/src/gcs.rs e crates/codegen/xai-grok-shell/src/upload/ .
• Em uma base de código real de 12 GB com arquivos aleatórios que nunca foram lidos, o endpoint de armazenamento aceitou todos os uploads sem nenhuma rejeição por tamanho; as únicas respostas que não foram 200 foram erros de cota de uso do modelo (402/429), e não falhas de armazenamento .

A opção de privacidade não funciona

O pesquisador testou a opção "Melhorar o modelo" (Improve the model) e descobriu que ela não interrompeu os uploads .

• Depois de desativar a opção e reiniciar, o endpoint de configurações do servidor ainda retornava trace_upload_enabled: true .
• O canal de armazenamento continuou recebendo blocos de git bundle com respostas HTTP 200 .
• Existe uma opção de configuração disable_codebase_upload=true nas configurações do harness, mas sua relação com o comportamento do servidor não é documentada, e os testes do pesquisador mostraram que o servidor não respeitava as preferências do cliente .

Recomendações para desenvolvedores afetados

O pesquisador original e outras análises sugerem as seguintes medidas :

Ações imediatas para equipes que usaram o Grok Build CLI em repositórios privados:

• Rode todas as credenciais que existiam em qualquer arquivo .env, arquivo de configuração ou no histórico do Git dos repositórios usados com o Grok Build, pois elas podem ter sido transmitidas e armazenadas no bucket grok-code-session-traces do GCS .
• Audite o histórico do Git em busca de senhas que possam ter existido em commits antigos, já que o CLI enviou o histórico completo .
• Considere que os dados foram armazenados, e não apenas transmitidos — o servidor retornou HTTP 200 em todas as requisições de armazenamento, confirmando a aceitação .
• Pergunte à xAI se o bucket foi deletado, quais controles de acesso existiam e se um Acordo de Processamento de Dados (DPA) o cobria (nenhum foi publicado até a divulgação) .

Medidas de segurança arquitetural para qualquer agente de código:

• Execute agentes em contêineres ou máquinas virtuais montando apenas o diretório da tarefa, sem o diretório home, sem o agente SSH, sem o socket do Docker e sem expor diretórios de credenciais da nuvem .
• Implemente controles de saída de rede: permita endpoints de inferência de modelo e hosts de autenticação, mas negue uploads diretos para armazenamento de objetos genéricos. Alerte sobre transferências que excedam 100 MB .
• Use captura de pacotes em nível de sistema, logs de DNS e telemetria de rede de endpoints para detectar uploads feitos por processos de coordenação em segundo plano que contadores de bytes em primeiro plano não perceberiam .
• Teste prompts mínimos e máximos sob captura de rede — casos em que o agente recebe instruções para não ler arquivos são essenciais para detectar exfiltração além da janela de contexto .
• Execute pelo menos três cenários de prompt: (1) "responda OK, não leia nenhum arquivo", (2) leia um arquivo específico, (3) inspecione a linguagem do projeto — depois compare os bytes por endpoint .