O Problema da Conta Hydra: Porquê a Defesa contra a Destilação Começa com a Resolução de Identidade (PT-PT)
A Anthropic registou 16 milhões de intercâmbios através de cerca de 24.000 contas fraudulentas e uma rede proxy a operar mais de 20.000 contas em simultâneo. A destilação não é um problema de "prompt"; é um problema de acesso.

A 23 de fevereiro de 2026, a Anthropic publicou números medidos sobre algo que a indústria da IA tinha discutido principalmente em abstrato até então. Em campanhas de destilação identificadas, a empresa relatou que os laboratórios "geraram mais de 16 milhões de intercâmbios com o Claude através de aproximadamente 24.000 contas fraudulentas". Um detalhe nesse relatório reformula todo o problema: "uma única rede proxy geriu mais de 20.000 contas fraudulentas em simultâneo".
Vinte mil contas. Um ator.
Essa é a forma da ameaça. A destilação adversarial — usar as saídas de um modelo de fronteira para treinar uma cópia mais barata do mesmo — não é executada por uma conta suspeita a fazer um pedido suspeito. É executada por uma organização que distribui uma única campanha de extração por milhares de contas, instrumentos de pagamento, dispositivos e caminhos de rede, de modo que cada conta individual parece inofensiva. Analisadas uma a uma, nenhuma delas aciona alarmes. Analisadas como um grafo, são uma única máquina.
É por isso que a defesa não pode residir apenas no modelo ou apenas no tráfego. Também tem de responder a uma questão que essas camadas não conseguem: quem está realmente por trás destas contas?
Principais conclusões
- A Anthropic relatou mais de 16 milhões de intercâmbios gerados através de aproximadamente 24.000 contas fraudulentas em campanhas de destilação identificadas, com uma única rede proxy a operar mais de 20.000 contas em simultâneo.
- A destilação é um problema de acesso coordenado, não um problema de pedido único. A revisão por conta é estruturalmente cega a este facto.
- O documento de fevereiro de 2026 do Frontier Model Forum define a destilação adversarial e os seus métodos. Por design, está focado na ameaça em vez de nos controlos, por isso não faz recomendações sobre verificação de contas, identidade, limitação de taxas ou controlo de acesso.
- As mitigações listadas pela própria Anthropic incluem "verificação reforçada para contas educacionais e de startups", juntamente com classificadores de deteção e impressão digital comportamental.
- Uma camada de acesso verificado faz três coisas que os controlos de modelo não conseguem: reduz o anonimato, liga contas que partilham uma pessoa, dispositivo ou rede, e faz com que uma conta regenerada morra à chegada.
- A verificação de identidade por si só não impede a extração do modelo. É uma de três camadas, e não substitui as outras duas.
O que realmente aconteceu
O relatório da Anthropic vale a pena ser lido na íntegra, mas três descobertas são as mais importantes para quem projeta controlos de acesso.
O volume estava concentrado em poucos atores. A Anthropic atribuiu "mais de 13 milhões" de intercâmbios à MiniMax, "mais de 3,4 milhões" à Moonshot AI, e "mais de 150.000" à DeepSeek. Estas não são extrações oportunistas. São programas industriais sustentados.
As contas eram coordenadas, e a coordenação era visível nos metadados. A Anthropic descreveu "padrões idênticos, métodos de pagamento partilhados e tempo coordenado" que "sugeriam 'balanceamento de carga'" entre contas. A atribuição veio de "metadados de pedido e indicadores de infraestrutura" — num caso, metadados de pedido que "correspondiam aos perfis públicos de funcionários seniores da Moonshot".
Os prompts repetiram-se em escala absurda. A Anthropic notou variações de prompt a chegar "dezenas de milhares de vezes em centenas de contas coordenadas".
Leia esses três pontos em conjunto e um padrão emerge. Quase todos os sinais que expuseram estas campanhas eram sinais relacionais — algo partilhado entre contas. Métodos de pagamento partilhados. Tempo partilhado. Infraestrutura partilhada. Modelos de prompt partilhados. Nenhum deles é visível se a sua unidade de análise for uma única conta.
Porquê a revisão por conta falha
A maioria das ferramentas de abuso é construída em torno de um veredicto por conta. Uma conta é registada, é pontuada, recebe uma faixa de risco e é tomada uma decisão. Esse modelo funciona bem para o abuso para o qual foi projetado — um fraudador a usar um cartão roubado, um spammer a bombardear um canal.
Falha contra a destilação por uma razão estrutural específica: o atacante controla quanto da campanha cada conta individual transporta.
Se o seu limiar de revisão for "uma conta a fazer 50.000 pedidos incomuns", o atacante usa 20.000 contas a fazer 800 pedidos cada. Se o seu limiar baixar, eles adicionam contas. A economia favorece-os porque as contas são o input mais barato do sistema. Uma chamada à API de um modelo de fronteira tem um custo marginal real; um endereço de e-mail não.
Assim, o problema de otimização do atacante é simples: manter o comportamento por conta abaixo de qualquer que seja o limiar por conta, e escalar horizontalmente. E funciona, porque a defesa está a medir o objeto errado. Está a medir contas quando o adversário é um ator.
Esta é a propriedade da hydra. Corte uma conta e outras duas aparecem, porque o que gera as contas nunca foi tocado. Uma rede proxy a operar mais de 20.000 contas em simultâneo, como a Anthropic relatou, é a expressão pura disso — a essa escala, remover contas uma a uma não é uma defesa, é uma tarefa de manutenção.
Para vencer uma hydra, é preciso parar de cortar cabeças e começar a encontrar o corpo.
As três camadas de uma defesa contra a destilação
Uma defesa séria tem três camadas, e são geridas de forma diferente.
| Camada | Gerido por | Função |
|---|---|---|
| Controlos do modelo | O fornecedor do modelo | Limitar traços de raciocínio sensíveis, moldar saídas, proteger o comportamento do modelo |
| Deteção de tráfego | O fornecedor do modelo, ou uma pilha de pesquisa/fornecedor | Detetar padrões de extração repetitivos, semanticamente concentrados ou coordenados |
| Acesso verificado | Infraestrutura de identidade | Resolver quem está por trás de uma conta, ligar identificadores partilhados, impor políticas em tudo o que está ligado a um abusador confirmado |
As duas primeiras camadas são bem compreendidas e ativamente pesquisadas. No lado do tráfego, o trabalho académico recente é genuinamente encorajador: Liu, Guo e Dong (arXiv 2606.05725, junho de 2026) enquadram a monitorização da extração como um teste de distribuição de janelas de tráfego calibrado benignamente, usando a máxima discrepância média no espaço semântico calibrado apenas em tráfego benigno. Em catorze pares de consultas atacante-normal de quatro cenários de extração, eles relatam uma taxa de deteção de 100% para casos de atacante puro com uma taxa de falsos positivos de 0,3% em consultas benignas.
Esse é um resultado forte, e é importante ser claro sobre o que significa: a deteção de tráfego funciona, e não é a camada sobre a qual a Didit está a falar. A análise semântica das distribuições de prompts é trabalho do fornecedor do modelo, e deve permanecer lá.
A terceira camada é aquela com menos orientação de design publicada — inclusive no próprio documento canónico da indústria sobre a ameaça.
O que o documento canónico abrange
O Frontier Model Forum publicou o seu documento sobre destilação adversarial no mesmo dia do relatório da Anthropic. É um bom documento. Define a destilação adversarial como o acesso secreto às saídas de um modelo — tipicamente em violação dos termos de serviço — para treinar um modelo secundário que replica as capacidades do professor enquanto ignora o seu treino de segurança. Cataloga os métodos: exfiltração de cadeia de pensamento, crítica de cadeia de pensamento, autoavaliação de cadeia de pensamento, geração de prompts para aprendizagem por reforço e geração de dados sintéticos. Nomeia as capacidades alvo: raciocínio matemático e científico, codificação agêntica, processamento multimodal, raciocínio geral.
Também reconhece a verdadeira tensão neste espaço — "abordar estas preocupações de segurança sem impedir a pesquisa legítima".
O que não contém é qualquer recomendação sobre verificação de contas, resolução de identidade, limitação de taxas ou controlo de acesso.
Essa é uma escolha de âmbito, e uma sensata: o documento propõe-se a definir a ameaça e os seus métodos, não a prescrever controlos. O design da camada de acesso é simplesmente um documento diferente.
É um documento que a indústria ainda não escreveu, no entanto — enquanto o laboratório que mediu a ameaça listou "verificação reforçada para contas educacionais e de startups" entre as mitigações em que investe, juntamente com classificadores de deteção e impressão digital comportamental. A camada de acesso está a fazer um trabalho real na prática e tem muito pouca orientação de design publicada por trás dela. É sobre isso que trata o resto desta publicação.
O que a camada de acesso verificado realmente faz
Seja preciso sobre a afirmação aqui, porque exagerar é como toda esta categoria perde credibilidade.
A verificação de identidade não deteta a destilação. Não consegue ver a semântica dos prompts, não sabe qual a capacidade que está a ser visada, e nunca lhe dirá que um fluxo de pedidos parece uma exfiltração de cadeia de pensamento. Isso é trabalho da camada de tráfego.
O que a identidade faz é mudar a estrutura de custos do atacante de quatro maneiras específicas.
Reduz o anonimato. Uma conta ligada a uma pessoa verificada ou a uma empresa registada é uma conta com um proprietário atribuível. Isso não impede o abuso, mas muda o custo e o risco do abuso.
Liga contas que partilham algo físico. Duas contas registadas com a mesma face, o mesmo dispositivo ou a mesma rede estão relacionadas, quer o seu comportamento pareça relacionado ou não. Este é o sinal que a revisão por conta não consegue produzir, e é exatamente a classe de sinal — método de pagamento partilhado, tempo partilhado, infraestrutura partilhada — que revelou as campanhas descritas pela Anthropic.
Torna a regeneração cara. A propriedade da hydra depende de novas contas serem baratas e desconectadas das antigas. Quando um caso de abuso confirmado se propaga a todos os identificadores que tocou — face, documento, telefone, e-mail, IP e dispositivo — a próxima conta criada na mesma infraestrutura falha à entrada em vez de ser detetada 800 pedidos depois.
Mantém a fricção longe de programadores legítimos. Esta é a restrição que torna tudo viável. A verificação aplicada a todos é um imposto sobre o crescimento. A verificação aplicada de forma adaptativa — por nível de acesso, quota, volume de crédito, geografia ou um alerta comportamental da camada de tráfego — coloca a fricção no risco e deixa o caminho do programador confiável rápido.
Quatro coisas. Nenhuma delas é "impede a extração". Todas as quatro são reais.
Onde a Didit se encaixa
A Didit é uma infraestrutura para identidade e fraude, e as primitivas que compõem uma camada de acesso verificado são as que já oferecemos e publicamos preços:
- Verificação de identidade — documento de identificação, prova de vida passiva, correspondência facial e análise de IP, num pacote de $0.33 por verificação, com 500 verificações KYC gratuitas por mês.
- Pesquisa Facial 1:N — pesquisa biométrica entre os utilizadores verificados que a sua própria aplicação registou, gratuita com verificação. Esta é a primitiva que liga duas contas a uma pessoa.
- Análise de IP e Dispositivo — $0.03, e incluída no pacote de $0.33. Emite
DUPLICATED_IP_ADDRESS,DUPLICATED_DEVICE_FINGERPRINT,DEVICE_RECOVERED_HIGH_CONFIDENCE,AUTOMATION_FRAMEWORK_DETECTEDe códigos relacionados. - API de Listas — listas de bloqueio em 12 tipos de entrada, onde o bloqueio de uma sessão confirmada extrai automaticamente os identificadores que essa sessão capturou — face, documento, telefone, e-mail, IP e dispositivo.
- Autenticação Biométrica — $0.10 para reverificação sem palavra-passe, para ligar uma ação privilegiada ao humano que fez o registo em vez de a um token de portador.
- Verificação de Empresas — a partir de $2.00 por empresa: pesquisa de registo, beneficiários efetivos e administradores, com triagem de entidades a $0.20 e qualquer verificação de identidade ligada para um beneficiário efetivo faturada às taxas padrão de Verificação de Utilizador. Para acesso a nível de organização e de pesquisa.
Compõe essas primitivas na política que a sua plataforma necessita. A composição é a sua arquitetura; as primitivas são as partes. Cada uma é entregue através da API unificada /v3/ com um preço publicado e sem mínimo — algumas como o seu próprio endpoint, como POST /v3/face-search/, e algumas através de um fluxo de trabalho de sessão, como a autenticação biométrica, que não tem um endpoint autónomo próprio.
Casos de uso
Fornecedores de modelos de fronteira. Associar acesso de alta quota, alto crédito e nível de pesquisa a uma pessoa ou empresa verificada, deixando os níveis gratuitos e de baixo volume sem atrito.
Plataformas de API de IA e fornecedores de inferência. Revendedores e agregadores herdam o abuso sem herdar a pilha de deteção. Uma camada de acesso é muitas vezes o único controlo que realisticamente possuem.
Produtos de codificação e agente de IA. O abuso de testes e a criação de créditos usam os mesmos mecanismos de multiplicação de contas que a destilação. As mesmas primitivas de ligação abordam ambos.
Plataformas de IA na nuvem e mercados. A verificação ao nível da organização responde a "esta é uma empresa real com beneficiários efetivos reais" antes que uma quota empresarial seja concedida.
Perguntas frequentes
A verificação de identidade impede a destilação de modelos?
Não. A extração é impedida — na medida do possível — por controlos de saída ao nível do modelo e por deteção de tráfego semântica. A identidade reduz o anonimato, liga contas numa campanha e faz com que as contas regeneradas falhem precocemente. É uma de três camadas.
A verificação não afastará programadores legítimos?
Apenas se a aplicar a todos. O design que funciona é adaptativo: verifique por risco, nível, quota, volume de crédito, geografia ou um alerta comportamental. A maioria dos programadores nunca deverá ver um passo de verificação. O KYC reutilizável da Didit é gratuito, por isso um programador já verificado noutra parte da rede pode passar uma verificação sem a refazer.
A Didit pode dizer-me que um fluxo de pedidos parece destilação?
Não. A Didit não vê os seus prompts e não analisa a semântica dos pedidos. Esse sinal vem da sua própria camada de tráfego. O que a Didit fornece é a resolução de identidade para ligar esse alerta a um ator, e as primitivas de aplicação para agir em todas as contas ligadas a eles.
Quanto custa isto à escala de uma plataforma de IA?
A verificação é cobrada por verificação bem-sucedida, sem mínimos: $0.33 para o pacote de identidade completo, $0.03 para análise de IP e dispositivo por si só, gratuito para Pesquisa Facial 1:N, $0.10 para reautenticação biométrica e a partir de $2.00 para verificação de empresas. Como a política é adaptativa, paga apenas pela fração de acesso que realmente justifica uma verificação. As primeiras 500 verificações KYC por mês são gratuitas.
Já temos um fornecedor de fraude. Porquê que este é diferente?
A maioria das ferramentas de fraude retorna um veredicto por conta. O problema da destilação é um problema por ator, e as primitivas que ligam as contas a um ator — pesquisa biométrica 1:N entre os seus próprios utilizadores, correlação de dispositivos e IP, e propagação de listas de bloqueio em todos os identificadores de um único caso confirmado — são as coisas específicas que a pontuação por conta não faz.
Pronto para começar?
Comece com a primitiva que produz o sinal de ligação que lhe falta hoje.
- Leia a documentação — Pesquisa Facial 1:N, avisos de Análise de IP e Dispositivo, e a API de Listas.
- Veja o produto — Verificação de Utilizador e Verificação de Empresas.
- Verifique os preços — cada módulo tem preços públicos, pago por sucesso, sem mínimos.
- Comece gratuitamente — crie uma conta em business.didit.me e execute as suas primeiras 500 verificações KYC por mês sem custo.
Artigos relacionados
- Verificação Empresarial para Acesso à API de IA: Quem Controla Realmente Esta Conta? (PT-PT)
- Acesso Verificado à API para Fornecedores de Modelos de IA: Uma Arquitetura por Níveis de Risco (PT-PT)
- Reconhecimento Facial 1:N: Encontrar Todas as Contas Controladas por uma Pessoa (PT-PT)
- Verificação Biométrica para Acesso a APIs de IA: Associar Privilégios a uma Pessoa (PT-PT)
- Redes de Contas Hydra: Como 20.000 Contas Se Tornam Um Único Ator (PT-PT)
- Propagação de Listas Negras: Como um Caso de Abuso Confirmado Pode Neutralizar Toda a Rede (PT-PT)