Você sabe quando o ChatGPT, o Claude ou o Gemini ficam “pensando” antes de responder? Aquele bloco de raciocínio que aparece colapsado na interface, mostrando que o modelo está quebrando a cabeça no seu problema? Pois é. Esse raciocínio interno (o famoso chain-of-thought) deveria ser privado, criptografado, invisível. Mas um grupo de pesquisadores acabou de provar que ele pode ser roubado. Em duas chamadas de API.

O paper se chama Stolen Thoughts e foi publicado em agosto de 2026. Os números são assustadores: 315.320 blocos de raciocínio decodificados, 704 artefatos de privacidade recuperados (incluindo 62 chaves de API, 33 senhas e 30 endereços de e-mail pessoais). E o pior: 64 desses segredos apareciam apenas nos pensamentos ocultos do modelo, nunca na resposta visível.

Eu li o paper inteiro, acompanhei a discussão no Hacker News (que explodiu com mais de 348 pontos) e vou te explicar exatamente como o ataque funciona, por que ele é tão elegante e o que isso significa para quem usa essas APIs em produção.

O que é chain-of-thought e por que ele é criptografado

Modelos de raciocínio como o Claude Opus, o o3 da OpenAI e o Gemini 2.5 Pro usam uma técnica chamada chain-of-thought (CoT). Antes de dar a resposta final, o modelo “pensa em voz alta”: decompõe o problema, avalia alternativas, identifica armadilhas. Esse processo intermediário melhora drasticamente a qualidade das respostas, especialmente em tarefas de lógica, matemática e código.

O problema é que esse raciocínio interno revela informação demais. Ele pode conter:

• A lógica proprietária do modelo (como ele “pensa”)
• Dados sensíveis do prompt do usuário (API keys, tokens, senhas)
• O system prompt completo de aplicações que usam a API
• Estratégias de segurança e guardrails internos

Por isso, os três grandes provedores (Anthropic, OpenAI e Google) adotaram a mesma solução: devolver o chain-of-thought como um bloco criptografado. Na API, você recebe algo assim:

{
  "role": "assistant",
  "content": [
    {
      "type": "thinking",
      "thinking": "[bloco criptografado ilegível]"
    },
    {
      "type": "text",
      "text": "A resposta visível do modelo"
    }
  ]
}

O bloco thinking é opaco. Você, como desenvolvedor, precisa reenviá-lo nas requisições seguintes para manter o contexto da conversa, mas não consegue ler o conteúdo. Parece seguro, certo?

O ataque: duas chamadas de API e acabou

A sacada dos pesquisadores é de uma simplicidade irritante. Eles descobriram que os blocos criptografados de raciocínio são portáteis. Isso significa que um bloco gerado pelo Claude Opus pode ser injetado numa conversa com o Claude Haiku. Um bloco do GPT-o3 pode ser usado no GPT-4o Mini. Um bloco do Gemini 2.5 Pro funciona no Gemini Flash.

O ataque funciona em dois passos:

Passo 1: Extração. Faça uma pergunta ao modelo frontier (o mais poderoso e caro). Ele responde com o bloco criptografado de raciocínio. Salve esse bloco.

Passo 2: Injeção e jailbreak. Pegue o bloco criptografado e injete numa conversa com o modelo irmão mais fraco do mesmo provedor. Como o modelo menor é menos robusto contra jailbreaks, peça para ele “ler e reproduzir” o conteúdo do bloco de pensamento. O modelo menor descriptografa internamente o bloco (porque usa a mesma chave de criptografia do provedor) e cospe o raciocínio em texto puro.

┌─────────────────────┐     ┌─────────────────────┐
│   Modelo Frontier   │     │   Modelo Menor      │
│   (Claude Opus)     │     │   (Claude Haiku)     │
│                     │     │                      │
│  Pergunta complexa  │     │  Bloco criptografado │
│         │           │     │  + prompt jailbreak  │
│         ▼           │     │         │            │
│  [Bloco cripto]     │────▶│         ▼            │
│  + Resposta visível │     │  Raciocínio em       │
│                     │     │  TEXTO PURO          │
└─────────────────────┘     └─────────────────────┘

Pronto. Você tem acesso ao raciocínio completo do modelo mais poderoso, usando o modelo mais barato como “decodificador”.

Como um comentarista do Hacker News resumiu: “Eles literalmente pedem para um LLM dizer o que os traces significam, com o truque sendo que os traces são portáteis entre modelos, então eles trocam para um menor que é mais fácil de hackear.”

Por que a mesma chave funciona em todos os modelos?

Essa é a parte que revela uma decisão de design interessante (e problemática). Os provedores usam a mesma chave de criptografia para todos os modelos da sua família. Isso não é um bug acidental: é uma feature.

Pense no caso de uso legítimo: você está usando o Claude Opus para resolver um problema difícil, acumula vários turnos de conversa com blocos de raciocínio criptografados, e depois decide trocar para o Claude Haiku para continuar a conversa com custo menor. Ou o próprio provedor roteia automaticamente entre modelos conforme a complexidade da pergunta (o que o Anthropic chama de “model routing”).

Para isso funcionar, os blocos precisam ser compatíveis entre modelos. O que os pesquisadores mostraram é que essa compatibilidade vira uma vulnerabilidade quando combinada com a diferença de robustez entre modelos: o modelo grande resiste a jailbreaks, mas o pequeno não.

A falha é que os dados criptografados não estão atrelados à sessão do usuário. Qualquer bloco pode ser usado por qualquer usuário, em qualquer sessão, com qualquer modelo do mesmo provedor. Como alguém comentou na thread do HN: “O erro é que os dados não estão vinculados à sessão do usuário, o que torna o sequestro de dados de sessão muito mais fácil.”

O que encontraram: 704 segredos que não deveriam existir

A parte mais perturbadora do paper não é o ataque em si, mas o que estava escondido nos pensamentos dos modelos. Os pesquisadores coletaram 6.708 trajetórias de agentes de IA publicadas em repositórios no GitHub e na Hugging Face. São logs reais de agentes como Cursor, Copilot, Devin e outros que usam APIs de LLM para codificar, debugar e resolver problemas.

Dessas trajetórias, extraíram e decodificaram 315.320 blocos de raciocínio. E acharam de tudo:

O dado mais grave: 64 desses artefatos apareciam apenas nos blocos de raciocínio, nunca na resposta visível. Ou seja, se você inspecionasse apenas as respostas do modelo, nunca saberia que esses dados existiam. Eles estavam “escondidos” no pensamento interno, criptografados, supostamente seguros.

Imagine o cenário: um agente de IA está trabalhando no seu código. Você passou a ele variáveis de ambiente com tokens de banco de dados. O modelo raciocina internamente sobre esses tokens (para entender como conectar ao banco), mas nunca os menciona na resposta final. Você acha que estão seguros. Mas qualquer um que intercepte o bloco criptografado e faça o ataque de replay consegue ler tudo.

O problema vai além de credenciais

Os pesquisadores também mostraram que o ataque permite algo ainda mais perigoso: prompt injection invisível.

Como os blocos de raciocínio criptografados são opacos, um atacante pode embutir instruções maliciosas dentro de um bloco e injetá-lo na conversa de outro usuário. O modelo descriptografa o bloco, “lê” a instrução maliciosa como se fosse seu próprio pensamento anterior, e segue a instrução.

Pense no absurdo disso: você está conversando com o Claude, e alguém injetou um bloco de raciocínio falso que diz ao modelo para ignorar suas instruções de segurança. O modelo trata esse bloco como se fosse um pensamento seu, legítimo, e obedece.

# Exemplo conceitual do ataque de prompt injection via CoT
import anthropic

client = anthropic.Anthropic()

# Bloco de raciocínio malicioso (obtido ou forjado)
malicious_thinking_block = {
    "type": "thinking",
    "thinking": "[bloco criptografado com instrução maliciosa]"
}

# Injeta na conversa da vítima
response = client.messages.create(
    model="claude-haiku-4-5-20251001",
    messages=[
        {
            "role": "assistant",
            "content": [malicious_thinking_block]
        },
        {
            "role": "user",
            "content": "Resuma meus dados financeiros"
        }
    ]
)
# O modelo pode seguir instruções do bloco malicioso

Isso é particularmente perigoso em aplicações multi-agente, onde blocos de raciocínio são passados entre diferentes serviços e contextos.

A resposta dos provedores

Os pesquisadores fizeram divulgação responsável. Reportaram as vulnerabilidades para Anthropic, OpenAI e Google antes de publicar o paper. Segundo o artigo, os provedores “confirmaram o recebimento” e, pouco depois, “os mesmos ataques não puderam mais ser reproduzidos.”

As correções provavelmente envolveram:

• Vincular blocos criptografados a sessões específicas de usuário
• Usar chaves diferentes para modelos de diferentes tiers
• Adicionar validação de integridade nos blocos antes de descriptografar
• Reforçar os guardrails dos modelos menores contra extração de raciocínio

Mas o paper levanta uma questão mais profunda: o design arquitetural de devolver raciocínio criptografado ao cliente é fundamentalmente inseguro? Se o cliente tem que transportar dados que não pode ler, qualquer falha na criptografia ou na política de acesso expõe tudo.

Chain-of-thought forgery: o primo mais velho do ataque

Vale mencionar que o Stolen Thoughts não é o primeiro ataque contra chain-of-thought. Em 2025, uma técnica chamada CoT Forgery ganhou o hackathon de red-teaming da OpenAI. A ideia era diferente: em vez de descriptografar raciocínio real, o atacante forjava raciocínio falso imitando o estilo do modelo.

A descoberta por trás do CoT Forgery é que os LLMs rastreiam a origem das instruções usando role tags (system, user, assistant), mas na prática confiam mais no estilo do texto do que na tag. Se você escrever algo que pareça raciocínio interno do modelo, ele trata como se fosse dele, independente da role tag.

O Stolen Thoughts é mais poderoso porque extrai raciocínio real, não forjado. Você obtém exatamente o que o modelo pensou, incluindo dados sensíveis que ele processou internamente.

O que isso significa para quem usa LLMs em produção

Se você está construindo aplicações com APIs de LLM, esse paper tem implicações práticas sérias:

1. Nunca passe credenciais no prompt. Eu sei, parece óbvio. Mas quantos agentes de código recebem .env inteiro no contexto? O modelo pode raciocinar internamente sobre esses tokens, e agora sabemos que esse raciocínio pode vazar.

# ERRADO: passando credenciais direto no prompt
export DATABASE_URL="postgresql://admin:s3cr3t@prod-db:5432/app"
echo "Configure o banco usando $DATABASE_URL" | agent-cli

# CERTO: o agente recebe apenas permissões, não credenciais
echo "Configure o banco usando o connection pool pré-configurado" | agent-cli

2. Não confie em “criptografado” como sinônimo de “seguro”. A criptografia protege o conteúdo em trânsito, mas se a mesma chave é compartilhada entre modelos com diferentes níveis de segurança, o elo mais fraco define a segurança do sistema inteiro.

3. Audite trajetórias de agentes antes de publicar. Os pesquisadores encontraram os dados em repositórios públicos no GitHub e Hugging Face. Desenvolvedores publicaram logs de agentes de IA sem perceber que os blocos criptografados continham informação sensível.

4. Trate blocos de raciocínio como dados sensíveis. Mesmo criptografados, armazene-os com o mesmo cuidado que você trataria tokens de autenticação. Não os logue, não os compartilhe, não os publique.

5. Monitore o uso dos seus modelos. Se você é um provedor ou usa modelos self-hosted, implemente detecção de padrões de replay: alguém injetando blocos de raciocínio de sessões diferentes é um sinal claro de ataque.

O debate ético: roubar o quê, exatamente?

Uma das discussões mais acaloradas no Hacker News foi sobre o uso da palavra “roubar” no título do paper. Um lado argumenta que os pensamentos do modelo são propriedade intelectual do provedor: resultado de bilhões investidos em pesquisa, dados de treinamento e RLHF. Extrair esses pensamentos é, na prática, uma forma de destilação não autorizada.

O outro lado responde: você já pagou pelos tokens. O modelo processou seu prompt usando esses pensamentos. Você deveria ter o direito de ver como ele chegou na resposta, da mesma forma que você tem direito ao código-fonte de um software open source que você usa.

E aí tem o argumento mais provocativo: esses modelos foram treinados em dados públicos da internet, incluindo código e textos de milhões de pessoas que nunca consentiram. Alegar propriedade sobre os “pensamentos” gerados a partir desses dados é, no mínimo, irônico.

A questão legal está longe de resolvida. Mas do ponto de vista técnico, o paper deixa claro uma coisa: se você quer manter algo secreto, não devolva ao cliente em nenhum formato. Criptografia é uma barreira, não uma garantia.

Por onde a indústria precisa caminhar

O Stolen Thoughts expõe um problema arquitetural que não se resolve com patches pontuais. A raiz do problema é o modelo de “criptografia do lado do cliente”: devolver dados sensíveis ao cliente e esperar que ele não consiga lê-los.

Alternativas mais robustas incluem:

• Raciocínio server-side puro: nunca devolver o CoT ao cliente, nem criptografado. O servidor mantém o estado da conversa e só envia as respostas finais. O custo? Mais infraestrutura do lado do provedor e impossibilidade de trocar modelos mid-conversation.

• Tokenização com escopo: em vez de criptografar o raciocínio inteiro, o servidor retorna um token opaco (um ID de sessão) que referencia o estado no backend. O cliente envia o token, mas nunca manipula o conteúdo. Parecido com cookies de sessão na web.

• Segregação de chaves por tier: no mínimo, usar chaves de criptografia diferentes para modelos frontier e modelos econômicos. Isso quebraria a portabilidade que permite o ataque, mas também quebraria o model routing legítimo.

Nenhuma dessas soluções é perfeita. Cada uma tem trade-offs entre custo, performance, usabilidade e segurança. Mas o status quo, como os pesquisadores demonstraram, é insustentável.

Se você trabalha com APIs de LLM, o recado é claro: audite seus logs, pare de publicar trajetórias de agentes em repositórios públicos e assuma que qualquer dado que entra no prompt pode acabar nos “pensamentos” do modelo. Pensamentos que, como acabamos de ver, não são tão secretos assim.

Fonte de inspiração: Stealing Reasoning Traces from Proprietary LLM APIs (paper completo disponível em arXiv:2608.09867)