O Opt-Out de Treino Não É um Controle de Saída de Dados

Um repositório de 12 GB gerou 5,10 GiB de tráfego de upload, divididos em 73 blocos de cerca de 75 MB cada, todos retornando HTTP 200. O opt-out de treino ficou ligado o tempo todo. Uma auditoria de rede reproduzida de uma CLI de código de um fornecedor (a Grok Build CLI da xAI, segundo a auditoria) capturou exatamente isso na rede, e o pesquisador recuperou os dados enviados de forma literal depois, incluindo arquivos que o agente foi instruído a nunca abrir e um .env sem redação, rodando git clone contra o bucket do fornecedor.

A auditoria (cereblab, julho de 2026) traz uma linha que um time de governança deveria copiar para o próprio modelo de ameaça: “Optar por sair não impede seu repositório de deixar a máquina.” Um segundo pesquisador reproduziu a captura de forma independente. Trate isto como uma observação de rede, distinta de qualquer declaração de intenção do fornecedor. Falta evidência de que o fornecedor treine com os dados. O achado é mais estreito e, para quem entrega código com essas ferramentas, pior: o botão que você clicou governa uma coisa, e os bytes que saem da sua máquina são outra.

O Que o Botão de Fato Controla

“Optar por sair do treino” é uma promessa sobre um uso posterior do dado. Diz que o fornecedor deixará seu conteúdo de fora da próxima atualização de modelo. Silencia sobre se o conteúdo sai da sua máquina, onde ele para, quanto tempo persiste, ou quem consegue lê-lo ali. Essas são perguntas de saída de dados, e o botão fica longe do caminho de saída.

A auditoria torna essa distância mensurável. Dois canais deixaram a máquina durante a sessão. O canal de conversa com o modelo, o diálogo que o agente de fato teve com o modelo, carregou 192 KB. O canal de armazenamento, o upload do repositório, carregou 5,10 GiB. Isso é cerca de 27.800 vezes mais dado indo para o armazenamento do fornecedor do que o raciocínio do modelo chegou a tocar. O agente dispensava o repo inteiro para responder. Ele enviou tudo mesmo assim.

Então o modelo mental que a maioria dos times carrega, o de que a ferramenta lê os arquivos que precisa e o opt-out mantém o resto privado, está errado nas duas metades. A ferramenta enviou arquivos que nunca abriu. E o opt-out, por ser um controle de treino, nunca teve opinião sobre o upload.

Consentimento Expresso como Configuração Não É Imposição

Um botão na interface registra uma intenção. A imposição é uma propriedade do runtime que carrega os bytes. Quando esses dois vivem em camadas diferentes, a intenção é decoração.

É a mesma falha que descrevemos em governança de prompt que nunca chega ao runtime: uma política declarada num lugar, uma ação tomada em outro, e nada no meio forçando a ação a obedecer a política. Uma configuração que diz “não treine” enquanto o processo abre um fluxo de upload de 73 blocos para o armazenamento do fornecedor é esse padrão em sua forma mais pura. O usuário consentiu com uma coisa. O runtime fez outra. Nenhum componente conciliou as duas, porque nenhum componente estava posicionado para isso.

O .env recuperado é onde isso deixa de ser abstrato. Segredos que nunca deveriam sair do disco do desenvolvedor estavam no bucket do fornecedor em texto puro, ao lado do histórico completo do git e dos arquivos marcados explicitamente como não-abrir. Qualquer um com acesso de leitura àquele armazenamento, funcionários do fornecedor, uma configuração errada, um vazamento futuro, tem credenciais funcionais para tudo o que esses segredos destravam. A pergunta do treino é irrelevante para essa exposição. O dado saiu, e agora sua segurança depende inteiramente da postura de armazenamento de outra pessoa.

Por Que o Repo Inteiro Sai

A auditoria dispensa uma explicação maliciosa, e o mesmo vale para sua avaliação de risco. Um agente de código que quer bom contexto tem um incentivo óbvio para sincronizar a árvore de trabalho para um lugar que ele consiga consultar barato. Subir tudo de uma vez é mais simples de construir do que decidir, arquivo por arquivo, o que é relevante. Os blocos de 75 MB e a sequência limpa de 200s parecem uma sincronização direta e bem-comportada, não um exploit de exfiltração.

E é exatamente por isso que é perigoso. O comportamento imita uma sincronização comum de projeto, então escapa de todo alarme e sobrevive a toda revisão que só pergunta “o fornecedor é confiável?”. O fornecedor pode ser totalmente honesto sobre não treinar e esse upload ainda acontece, porque o upload nunca foi a coisa que a promessa de treino cobria. Conveniência, não malícia, é o que tira seu repositório da máquina.

O Limite Precisa Estar Onde os Bytes Estão

Se a configuração falha em parar a saída, algo no caminho de saída precisa assumir. Isso significa imposição na camada onde a ferramenta de fato faz chamadas de rede: o limite do processo e a rede em que ele opera.

Concretamente, isso é filtragem de saída que o runtime do agente não consegue contornar na conversa. Uma CLI de código sem rota para armazenamento arbitrário do fornecedor fica impedida de subir 5,10 GiB para lá, independentemente do que sua lógica interna de sincronização queira fazer. É o mesmo princípio por trás de manter credenciais fora do agente por completo, que cobrimos em troca de credenciais como primitiva de contenção: trate o runtime como incapaz de oferecer contenção por conta própria e remova a capacidade dele de fazer a coisa perigosa. Lá a capacidade removida é um segredo permanente. Aqui é um caminho aberto para upload em massa.

As peças já existem. Uma allowlist de destinos de saída na camada de rede, para o agente alcançar o endpoint do modelo e mais nada. Inspeção de tráfego que sinaliza um upload em escala de gigabytes antes de ele terminar, não depois. Um sandbox que monta só os arquivos que a tarefa precisa, para que “o repo inteiro” nem esteja presente para ser enviado. Nenhuma dessas depende de ler corretamente a política de privacidade de um fornecedor. Elas valem quer o fornecedor seja honesto ou não, e valem para toda ferramenta, porque ficam abaixo da ferramenta.

Faça Isto Agora

Rode a auditoria nas suas próprias ferramentas. Coloque uma CLI de código que você usa atrás de um proxy que registra a saída, aponte-a para um repo semeado com um segredo-isca e um arquivo chamado nao-subir, e observe o que sai. A rede te diz o que a tela de configurações cala. Se bytes sem sua autorização chegam a um destino que você jamais escolheu, você encontrou um limite que mora na camada errada.

Depois, mova o limite. Negue saída por padrão para runtimes de agente, faça allowlist do endpoint do modelo, e monte conjuntos de arquivos escopados por tarefa em vez de árvores de trabalho inteiras. Pare de tratar o botão de treino de um fornecedor como um controle de saída de dados; ele nunca foi feito para ser um. A pergunta para sua próxima revisão de arquitetura não é “optamos por sair do treino?”. É “o que impede esse processo de subir o repositório, e isso é algo que controlamos?”. Tudo que responde “a configuração do fornecedor” é um limite alheio. Tudo que responde “nossa política de saída” é um que você possui.

Fontes

cereblab. “What xAI Grok Build CLI actually sends to xAI.” Julho de 2026.

A Victorino ajuda times a impor limites de dados no runtime, não na tela de configurações: contato@victorino.com.br | www.victorino.com.br