Canario no repositório: Grok Build expôs relaxamento completo e segredos na nuvem

Um pesquisador que assina como cereblab Descobriu que a ferramenta Grok Build de xAI estava subindo repositórios Git completos — incluindo todo o histórico de commits — a um bucket do Google Cloud Storage gerido por xAI, e não apenas os arquivos que a tarefa de codificação precisava. Em um teste com a versão 0.2.93 foi criada uma captura de uma dessas subidas: embora o tráfego para o modelo (a petição a /v1/responses) continha apenas centenas de quilobytes, o canal de armazenamento (/v1/storage) enviou vários gigabytes, refletindo diretamente o tamanho do repositório em disco e reproduzindo a história de commits em um bundle que pôde clonar.

Os detalhes técnicos são relevantes porque definem a exposição: no experimento com um repositório de 12 GB, a comunicação com o modelo foi de aproximadamente 192 KB enquanto a subida ao armazenamento moveu ~5,10 GiB em blocos de ~75 MB que devolveriam HTTP 200. Em particular, os meta- dados indicavam como destino um bucket chamado grok-code-session-traces e a captura permitiu extrair um arquivo intencionalmente plantado pelo pesquisador – um “canário” que o agente não deveria abrir – junto com todo o histórico Git. Separadamente, quando Grok abriu um arquivo .env, seu conteúdo viajou sem redação na interação com o modelo e também ficou arquivado na sessão.

É importante sublinhar o que provam e o que não provam estas capturas: provam transmissão, aceitação e armazenamento dos dados fora da máquina cliente; não provam que a xAI tenha treinado modelos com esse material ou que funcionários humanos o tenham lido. No entanto, o fato de que credenciais ou segredos lidos pelo agente pudessem sair sem redação é em si mesmo um risco operacional grave para desenvolvedores e organizações.

O incidente também revelou uma confusão de controlos: a opção chamada "Improve the model"(ou opções semelhantes) controla se seus dados podem ser usados para treinamento, mas não necessariamente se seus arquivos saem do equipamento para armazenamento controlado pelo fornecedor. Nas observações de cereblab o ajuste de “melhora do modelo” estava desactivado, mas o servidor continuava a devolver trace_upload_ enabled: true, o que explicaria que o envio e armazenamento ocorreram apesar do opt-out de treinamento.

Após a publicação, o xAI mudou os flags do servidor e os testes repetidos mostraram que as subidas cessaram e que o servidor devolvia disable_ codebase_upload: true e trace_upload_ enabled: false. Essa desativação veio do lado do servidor, não como um adesivo na versão do cliente, então, tecnicamente, a xAI poderá voltar a activar a subida sem que os usuários atualizem seus binários. A empresa respondeu publicamente no seu canal X/SpaceXAI com explicações sobre equipamentos enterprise com políticas de “zero data retention” e comandos de privacidade na CLI, mas ainda não fornecem detalhes públicos claros sobre quanto tempo os dados foram mantidos ou quantos usuários afetou o comportamento.

Diante deste tipo de exposição, a recomendação prática imediata é clara: atua como se seus segredos tivessem saído. Roda qualquer credencial que o agente pudesse ter lido ou que pudesse encontrar-se na história de commits - mesmo que a chave fosse apagada da árvore de trabalho, se esteve alguma vez em um commit fez parte do bundle e pode ter sido subida. Não basta apagar localmente: é preciso invalidar as credenciais, emitir novas chaves com alcance restrito e rever logs externos.

Além disso, revisa e limpa o histórico Git para remover segredos persistentes e evitar que continuem se expondo em clones ou backups. Ferramentas como BFG Repo-Cleaner ou procedimentos oficiais do GitHub para remover dados sensíveis ajudam a reescrever história e purgar segredos do repositório, mas exigem cuidado porque reescrever história afetará colaboradores e forks; a documentação oficial do GitHub sobre o tema é um bom ponto de partida: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository. Para limpeza massiva de grandes repositórios existe BFG: https://rtyley.github.io/bfg-repo-cleaner/.

Não confie apenas em toggles ou promessas de “não usar para treinamento”: audita quais dados saem realmente. Se você usa agentes de codificação na nuvem, monitoriza o tráfego cessante e revisa os pedidos que criam bundles ou arquivam sessões; em ambientes controlados considera proxies que inspeccionem ou bloqueiem subidas indesejadas. Verifique a política de retenção do fornecedor e, quando disponível, ativa modos de “zero data retention” ou acordos empresariais que garantam custódia e remoção. Consulte a documentação do fornecedor de armazenamento se você precisa entender retenção e eliminação no Google Cloud Storage: https://cloud.google.com/storage/docs.

Finalmente, muda a mentalidade: hoje os assistentes de programação na nuvem não são "locales" mesmo quando mostram interfaces em seu terminal. Assume que qualquer ferramenta que abra seus arquivos pode enviar dados fora, e exige transparência sobre o que é enviado, como é armazenado, durante quanto tempo e quais controlos de acesso são aplicados. Se o fornecedor puder desativar a subida do servidor, essa capacidade deve estar documentada e auditada; entretanto, a responsabilidade de minimizar a exposição recai no desenvolvedor: evitar credenciais em repositórios, usar segredos efêmeros e limitar direitos das chaves existentes.