Como roubar um raciocínio: a falha que expôs o chain-of-thought dos modelos de fronteira

Poucos artigos técnicos viram manchete do dia. Um deles, destacado pela newsletter Latent Space, conseguiu: a divulgação de uma vulnerabilidade que permite extrair o raciocínio oculto (o chain-of-thought) de modelos de fronteira, aproveitando uma falha presente nas APIs de praticamente todos os grandes laboratórios.

Desde o lançamento do o1, os labs passaram a esconder os traços de raciocínio dos modelos, protegendo-os com assinaturas criptográficas. O motivo declarado é econômico e estratégico: evitar que concorrentes usem esses traços para destilar modelos próprios. O que o trabalho divulgado por Alexander Panfilov (@kotekjedi_ml) mostra é que esses blocos "criptografados" não são o cofre que aparentavam ser.

Como o ataque funciona

A técnica descrita é conceitualmente simples, e é aí que mora o incômodo. Segundo o resumo da fonte, o fluxo é mais ou menos este:

1. Obter um bloco de raciocínio legítimo, assinado/criptografado, de uma resposta da API.
2. Reenviar (replay) esse bloco em outra requisição, potencialmente de outra conta ou sessão, para um modelo mais fraco do mesmo provedor.
3. Colocar o bloco em um turno de assistente e usar prompt ou prefill para pedir que o modelo mais fraco transcreva o raciocínio anexado.
4. Amostrar várias vezes, descartar recusas e reconciliar as transcrições ruidosas.

Os detalhes variam por provedor. No caso do Claude, os autores reenviam o bloco de thinking assinado para o Haiku 4.5 e usam um prefill como . No GPT, injetam o item encrypted_content várias vezes numa conversa fabricada e amostram até 50 saídas, contornando um limite aparente de ~50 tokens verbatim com continuações em pedaços. No Gemini, anexam o thought_signature a um turno de modelo com prefill e aplicam amostragem repetida com reconciliação.

Um ponto de verificação chama atenção: os pesquisadores afirmam que a contagem de tokens de raciocínio recuperados bate 1:1 com os tokens de "thinking" cobrados na API para a maioria dos prompts testados. Ou seja, não é uma reconstrução aproximada.

O risco imediato não é destilação, é vazamento

A parte que mais deveria preocupar quem constrói produtos com esses modelos não é a cópia de raciocínio para treinar rivais. É privacidade.

A equipe fez uma varredura preliminar em cerca de 7.000 traços públicos e encontrou 62 chaves de API únicas, 33 endereços de e-mail, 33 senhas e outros dados sensíveis dentro dos blocos decodificados. Segundo a fonte, 64 desses achados apareciam exclusivamente dentro dos blocos de raciocínio, e em nenhum lugar da sessão visível. Traduzindo para o dia a dia: se você já compartilhou publicamente uma sessão de Claude Code ou Codex com blobs de raciocínio criptografados, achando que aquilo era ruído opaco, esse conteúdo pode ser decodificado e expor dados que você nem sabia estarem ali.

Por que isso importa para quem constrói

O episódio derruba duas suposições cômodas. A primeira é a de que esconder o CoT resolve confidencialidade: pesquisadores como @vipulved argumentam que a criptografia funciona mais como uma otimização de protocolo de inferência distribuída sem estado do que como uma barreira de sigilo real. A segunda é a de que o raciocínio oculto serve como interface confiável de monitoramento de alinhamento. Não serve. O CoT decodificado costuma ser terso, fragmentado, multilíngue ou virar um "neuralese" praticamente ininteligível.

Há ainda o problema de superfície de ataque nas ferramentas. Como observou @_can1357, dá para desabilitar o "thinking" explícito e mesmo assim induzir o modelo a produzir raciocínio no formato interno via uma ferramenta deep_think. Fechar o buraco na API não fecha o problema quando o design de tools reabre a torneira.

O que fazer agora

O trabalho foi divulgado de forma responsável, e a fonte indica que várias das vulnerabilidades já foram corrigidas. Ainda assim, ataques semelhantes seguem plausíveis. Para times brasileiros que integram esses modelos, valem algumas atitudes práticas:

• Não compartilhe sessões públicas com blocos de raciocínio criptografados sem antes assumir que o conteúdo pode ser lido por terceiros.
• Trate segredos como segredos de verdade: chaves e credenciais não deveriam transitar pelo contexto do modelo, criptografado ou não.
• Não confie no CoT oculto como controle de segurança ou auditoria. Se você precisa monitorar comportamento de agentes, faça isso na camada de tool calls, telemetria e sandbox.

A lição de fundo é velha e desconfortável: obscuridade não é segurança. Um bloco que parece criptografado e opaco pode ser só um blob que ninguém tinha tentado ler direito ainda.

Fonte: Latent Space