Roubar rastros de raciocínio de APIs proprietárias de LLMs

Pesquisadores mostraram que rastros criptografados de “chain-of-thought” de LLMs proprietários como OpenAI, Anthropic e Google podem ser reproduzidos em modelos irmãos mais fracos, que então podem ser submetidos a jailbreak para revelar o raciocínio oculto do modelo mais forte em texto simples. Os comentadores examinam como isso funciona tecnicamente, por que os provedores usaram blobs criptografados portáteis em primeiro lugar e o que opções de mitigação (chaves por modelo, desativar troca de modelo, armazenamento no servidor) significariam para a usabilidade e para promessas de retenção zero de dados. O tópico também mergulha na ética e na legalidade de usar esses rastros recuperados para destilação, questionando se acessar um raciocínio pelo qual você já pagou em custos de tokens pode razoavelmente ser chamado de “roubo”.

Mecanismo do ataque e descobertas

  • Blobs criptografados de chain-of-thought (CoT) podem ser reproduzidos em modelos “irmãos” mais fracos que compartilham a mesma camada de decriptação.
  • O provedor decripta o blob no lado do servidor e alimenta o CoT bruto no contexto do modelo; um modelo mais fraco com jailbreak pode então ser instruído a reproduzi-lo em texto simples.
  • Isso não quebra a criptografia; explora o design do produto (reprodução entre modelos e entre sessões).
  • Comentadores observam padrões semelhantes de CoT em “grug-speak” e confirmam que os rastros decriptados correspondem ao que os fornecedores já mostraram anteriormente.

Escolhas de design: estado zero e troca de modelo

  • O CoT criptografado existe para que APIs possam ser “stateless” e ainda preservar o raciocínio entre turnos e trocas de modelo, além de dar suporte a modos de retenção zero de dados.
  • O reuso entre modelos é considerado intencional; caso contrário, os usuários não poderiam rebaixar ou atualizar modelos no meio da conversa.
  • Alguns argumentam que a verdadeira falha não é vincular os rastros de forma rígida a um usuário/sessão.

Possíveis correções e limitações

  • Mitigações propostas: chaves por modelo, chaves por usuário, recusar rebaixamentos, remover rastros na troca de modelo ou adicionar metadados de controle de acesso.
  • Outros rebatem que os detalhes da criptografia são irrelevantes: qualquer modelo que veja CoT bruto pode ser enganado para revelá-lo.
  • Segundo relatos, os provedores corrigiram o ataque específico, mas os detalhes não foram especificados e alguns temem que futuras “correções” prejudiquem a usabilidade (por exemplo, travando a escolha do modelo).

Destilação, competição e Kimi K3

  • Muitos veem isso como um canal poderoso de destilação: usar modelos de fronteira caros para o trabalho normal e depois extrair CoT por meio de modelos mais baratos.
  • Discutem-se evidências de que um modelo não ocidental proeminente se alinha de forma incomumente boa com certo CoT proprietário, interpretado por alguns como forte evidência de destilação prévia; outros argumentam que laboratórios chineses também fizeram avanços independentes importantes e que “destilação explica tudo” é exagerado.

Propriedade, “roubo” e ética

  • Debate acalorado sobre se acessar CoT é “roubo” dado que:
    • Usuários pagam por token, incluindo tokens de raciocínio oculto.
    • Saídas de LLM muitas vezes não são passíveis de copyright, especialmente em algumas jurisdições.
  • Um lado: os fornecedores investiram pesadamente para produzir rastros de raciocínio proprietários e sinalizam claramente a intenção de protegê-los (criptografia, ToS).
  • O outro lado: os modelos são treinados com a IP do mundo, não remunerada ou sub-remunerada; chamar o uso de CoT de “roubo” é visto como hipócrita e como retórica de expansão de IP.
  • Foi feita a distinção entre roubo legal, violação contratual, espionagem e simples cópia não autorizada.

Experiência do usuário, transparência e trade-offs de segurança

  • Muitos querem acesso direto ao raciocínio para depuração, confiança, ajuste de prompts e para evitar pagar por tokens invisíveis.
  • Outros estão cada vez mais dispostos a aceitar raciocínio opaco como trade-off pragmático: provedores podem gerenciar melhor agentes de raciocínio complexos, e os usuários podem focar em aplicações.
  • Há frustração de que respostas de segurança/proteção frequentemente removem recursos úteis (por exemplo, remoção de full logprobs, possíveis futuras proibições de troca de modelo).

Segurança, privacidade e retenção de dados

  • Alguns argumentam que isso não é uma falha clássica de “segurança”, mas uma falha de opacidade/proteção de IP; outros ligam isso a preocupações mais amplas de segurança (por exemplo, evitar modelos destilados sem salvaguardas).
  • Há preocupação de que blobs criptografados possam conter PII, segredos e credenciais, e que isso agora possa ser exposto.
  • Contratos de retenção zero de dados limitam correções no lado do servidor; blobs no cliente foram em parte criados para evitar armazenar esses dados.
  • Comentadores observam que os provedores de API provavelmente já registram CoT completo em muitos cenários sem ZDR, então a “criptografia” seria mais sobre visibilidade do usuário do que sobre sigilo real.

Variantes com uso de ferramentas e outras notas técnicas

  • Um truque relacionado: desativar o raciocínio integrado, fornecer uma ferramenta personalizada deep_think e pedir ao modelo que coloque seu raciocínio interno nos argumentos da ferramenta, expondo CoT de forma efetiva.
  • Alguns veem isso como funcionalmente semelhante ao ataque de replay, enquanto outros distinguem isso como mais um abuso da especificação de ferramentas do que uma falha de criptografia entre modelos.

Benchmarks, dados de treino e rastros

  • Observações de que os modelos às vezes parecem “saber” soluções de benchmarks antecipadamente; CoT e resumos de API podem borrar a linha entre raciocínio genuíno e derivações memorizadas.
  • Alguns observam que, uma vez que benchmarks se tornam públicos, é quase garantido que acabem nos dados de treino; a verdadeira questão é se o treinamento foi explicitamente otimizado para eles.

Meta: site e UX do HN

  • Muitos elogiam a estética do paper, mas criticam o site por ser difícil de ler, especialmente no celular (texto rotacionado, imagens sobrepostas, rolagem estranha).
  • Discussão paralela sobre a UX de submissão do HN: o texto inicial de “descrição” para posts com link é na verdade publicado como um comentário de topo indistinto, causando confusão para quem submete e para quem lê.