Propagação de Blocklist: Desativando Toda a Rede com um Caso Confirmado de Abuso

Existe um momento específico em que a maioria dos programas de combate ao abuso perde valor: o momento depois de você vencer.

Sua camada de tráfego sinaliza uma conta. Um analista investiga. A evidência é sólida, o caso é confirmado, a conta é banida. E então, horas depois, o mesmo operador está de volta em novas contas, porque a única coisa que sua aplicação tocou foi uma linha em uma tabela de usuários.

A Anthropic descreveu exatamente essa dinâmica em seu relatório de fevereiro de 2026 sobre campanhas de destilação — uma rede proxy que “gerenciava mais de 20.000 contas fraudulentas simultaneamente”, substituindo-as à medida que eram removidas. A remoção não era o gargalo. A regeneração era mais barata que a remoção.

A solução é fazer com que a aplicação opere em identificadores em vez de contas. A API de Listas da Didit é construída em torno de uma mecânica que faz isso em uma única chamada.

Principais conclusões

• Colocar na blocklist com reference_session_id faz com que a Didit extraia automaticamente o valor correto da sessão — rosto, documento, telefone, e-mail, IP ou dispositivo — marque o modelo subjacente como blocklistado e vincule a entrada de volta à sessão de origem.
• 12 tipos de entrada: face, document, phone, email, ip_address, device_fingerprint, wallet_address, bank_account, user, business, country, key.
• As blocklists são criadas pelo sistema, uma por tipo de entrada, e imutáveis. Você não pode criá-las, o que torna a aplicação uniforme.
• As entradas entram em vigor imediatamente no momento da verificação. Excluir uma entrada desbloqueia a correspondência.
• ip_address aceita um intervalo CIDR, então você pode colocar infraestrutura na blocklist em vez de um único endereço.
• Allowlists nos mesmos 12 tipos mantêm desenvolvedores confiáveis fora de qualquer caminho de escalonamento.

Os dois tipos de lista que importam

A API possui três tipos de lista, e a distinção entre eles é deliberada.

Blocklists são criadas pelo sistema — uma por tipo de entrada — e imutáveis. Você não pode criá-las, renomeá-las ou excluí-las. Você adiciona e remove entradas. Essa restrição é um recurso: significa que “blocklistado” tem exatamente um significado em sua organização, e não há como acabar com quatro blocklists de rosto concorrentes que diferentes serviços verificam de forma inconsistente.

Allowlists são suas para criar. Dispositivos conhecidos e bons, faixas de endereço, entidades comerciais e usuários vão aqui.

Custom lists são para todo o resto — suas próprias taxonomias, grupos de vigilância, coortes de revisão.

# Encontrar a blocklist de rosto
curl -X GET 'https://verification.didit.me/v3/lists/?list_type=blocklist&entry_type=face' \
  -H 'x-api-key: YOUR_API_KEY'

A mecânica que importa

Aqui está a maneira comum de colocar algo na blocklist, e é a maneira errada em quase todas as situações reais:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "value": "203.0.113.44" }'

Isso coloca um endereço na blocklist. Enquanto isso, a sessão que você estava investigando também continha um rosto, um número de documento, um telefone, um e-mail e uma impressão digital do dispositivo — cada um deles um identificador que o operador precisa substituir antes de retornar.

A melhor chamada:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "reference_session_id": "a7f3...c19" }'

Passe reference_session_id e a Didit extrai automaticamente o valor correto para o tipo de entrada dessa lista da sessão, marca o modelo subjacente como blocklistado e vincula a entrada de volta à sessão para que o console possa mostrar de onde ela veio.

Três coisas decorrem disso, e todas as três importam operacionalmente:

Nenhuma extração manual. Seu analista não lê uma impressão digital do dispositivo em uma tela e a redigita. Erros de transcrição em dados de aplicação são falhas silenciosas — o banimento simplesmente não é acionado, e ninguém descobre.

A proveniência é preservada. Cada entrada se vincula de volta à sessão que a justificou. Quando alguém pergunta em quatro meses por que este dispositivo está bloqueado, a resposta é um clique, não um projeto de arqueologia.

A aplicação é repetível. A mesma chamada contra cada blocklist de tipo de entrada cobre toda a superfície de identificadores da sessão.

Se uma sessão contiver várias instâncias do mesmo tipo, passe value junto com reference_session_id para desambiguar.

Você também pode aplicar de fora de uma sessão de verificação. reference_object_uuid junto com metadata.reference_type — transaction, vendor_user ou vendor_business — coloca na blocklist a partir de uma transação ou de um usuário ou empresa fornecedor, e mantém o mesmo vínculo com a origem.

Os 12 tipos de entrada

Tipo de entrada	Bloqueia	Notas
face	A pessoa	Também carregável diretamente via upload de rosto
document	A credencial
phone	O número	Auto-normalizado para E.164
email	O endereço
ip_address	O endereço ou intervalo	Aceita CIDR, ex: 10.0.0.0/8
device_fingerprint	A máquina	Mínimo de 8 caracteres alfanuméricos
wallet_address	O endereço on-chain
bank_account	A conta
user	O registro do usuário
business	A entidade
country	A jurisdição
key	Uma chave personalizada

Dois são dignos de menção para este problema.

ip_address aceita um intervalo CIDR. Colocar 203.0.113.0/24 na blocklist bloqueia a infraestrutura, não um endereço. Quando uma operação de "farming" (criação em massa de contas) é executada em uma sub-rede alugada, esta é a diferença entre uma aplicação que escala e uma aplicação que joga "whack-a-mole". Use com cuidado — um intervalo também abrange usuários reais, e intervalos muito amplos são como você bane silenciosamente a operadora de celular de um país.

face suporta upload direto. Quando você tem uma imagem, mas nenhuma sessão, carregue-a diretamente:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/face-upload/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "image": "<base64-encoded image>" }'

A Didit extrai o dado biométrico. A partir de então, esse rosto é rastreado em cada verificação.

O que acontece depois que uma entrada é registrada

Adicionar a uma blocklist do sistema bloqueia futuras correspondências imediatamente no momento da verificação. Não há atraso de propagação nem trabalho em lote.

Na próxima verificação, a aplicação aparece como avisos:

• FACE_IN_BLOCKLIST — correspondência definitiva, verificação recusada. POSSIBLE_FACE_IN_BLOCKLIST é uma correspondência limítrofe abaixo do limite rígido e deve ser encaminhada para revisão, não para recusa.
• IP_ADDRESS_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_BLOCKLIST — ocorrências de rede e dispositivo.

Na Pesquisa Facial, uma correspondência na blocklist é a única coisa que define o status para "Declined". Cada correspondência na resposta também contém is_blocklisted, para que uma investigação mostre imediatamente quais partes de um cluster já estão sob aplicação e quais ainda estão ativas.

A remoção é simétrica: excluir uma entrada desbloqueia a entidade correspondente. A aplicação é reversível por design, o que importa porque a aplicação excessivamente ampla é um risco real e você precisa de um caminho limpo para voltar atrás.

curl -X DELETE 'https://verification.didit.me/v3/lists/{list_uuid}/entries/{entry_uuid}/' \
  -H 'x-api-key: YOUR_API_KEY'

Allowlists: protegendo os desenvolvedores que você deseja

A aplicação que apenas escala eventualmente estrangula o produto. Os mesmos 12 tipos de entrada suportam allowlists, e eles são a válvula de pressão.

Coloque na allowlist os intervalos de IP do escritório de um parceiro de design. Coloque na allowlist os dispositivos da equipe de engenharia de um cliente empresarial. Coloque na allowlist uma entidade comercial verificada para que seus usuários nunca cheguem a um caminho de escalonamento. IP_ADDRESS_IN_ALLOWLIST e DEVICE_FINGERPRINT_IN_ALLOWLIST são acionados quando ocorre uma correspondência, para que você possa confirmar que a isenção foi aplicada em vez de presumir que sim.

Este é o mecanismo que torna a aplicação agressiva sustentável. Você pode permitir uma política rigorosa em infraestruturas desconhecidas precisamente porque sua população conhecida e boa é explicitamente excluída.

Erros que valem a pena tratar

• 400 — o valor falhou no validador do tipo de entrada, o list_type está errado para a operação (por exemplo, um upload de rosto contra uma lista que não é de rosto), ou reference_session_id não tem dados do tipo solicitado. Esse último caso é comum e benigno: nem toda sessão captura todos os identificadores.
• 403 — {"detail": "Você não tem permissão para realizar esta ação."}

Observe que um 400 de "sessão não tem dados desse tipo" é esperado quando você percorre uma sessão em todas as blocklists de tipo de entrada. Trate-o como um descarte, não como uma falha.

Um fluxo de aplicação trabalhado

Um analista confirmou abuso na conta acct_8842.

1. Resolva o cluster primeiro. A Pesquisa Facial no rosto da sessão retorna doze contas; a correlação de dispositivo e IP puxa mais uma dúzia. A aplicação antes da resolução bane uma conta e avisa o operador.
2. Coloque na blocklist da sessão confirmada — reference_session_id contra as blocklists de rosto, dispositivo, IP, e-mail, telefone e documento. Seis chamadas, sem extração manual, proveniência completa.
3. Considere o intervalo. Se a evidência de rede aponta para infraestrutura alugada, uma entrada CIDR cobre a sub-rede. Verifique o que mais vive lá primeiro.
4. Aja no cluster de acordo com sua própria política — as contas que você já identificou não se desbanem sozinhas.
5. Verifique a aplicação. Execute novamente a pesquisa facial. As correspondências agora devem conter is_blocklisted: true.
6. Espere pela tentativa de regeneração. A próxima conta criada com aquele rosto, dispositivo ou sub-rede é recusada na verificação em vez de aparecer em seu tráfego três semanas depois.

O passo 6 é o ponto principal. O custo do operador para retornar não é mais "criar um novo endereço de e-mail". É "adquirir novo hardware, nova rede e uma nova pessoa".

Casos de uso

Plataformas de API de IA convertendo um caso confirmado de destilação ou abuso em aplicação em todos os identificadores que o operador tocou.

Abuso de testes e crédito onde o mesmo dispositivo e rosto continuam retornando para uma nova alocação gratuita.

Marketplaces bloqueando vendedores removidos de se registrarem novamente sob um novo negócio.

iGaming aplicando a autoexclusão, onde um jogador excluído que retorna é uma falha regulatória e a aplicação em nível de rosto é o único controle confiável.

Perguntas frequentes

Posso criar minha própria blocklist?

Não. As blocklists são criadas pelo sistema, uma por tipo de entrada, e imutáveis — você adiciona e remove entradas. Você pode criar allowlists e listas personalizadas livremente. A restrição mantém "blocklistado" significando uma coisa em todos os lugares.

Com que rapidez uma entrada entra em vigor?

Imediatamente, na próxima verificação.

E se eu colocar algo na blocklist por engano?

Exclua a entrada e a entidade será desbloqueada. É por isso que a proveniência importa — cada entrada criada a partir de uma sessão se vincula a ela, para que você possa auditar para que uma entrada serviu antes de removê-la.

Colocar um intervalo de IP na blocklist afeta usuários legítimos nesse intervalo?

Sim, e esse é o risco. Uma entrada CIDR bloqueia tudo dentro dela. Use intervalos quando a evidência aponta para infraestrutura dedicada, use endereços únicos caso contrário, e coloque na allowlist intervalos conhecidos e bons primeiro.

Posso colocar na blocklist a partir de algo que não seja uma sessão de verificação?

Sim. reference_object_uuid mais metadata.reference_type (transaction, vendor_user ou vendor_business) abrange transações e usuários ou empresas fornecedores.

Isso impede a extração de modelos?

Não. Isso impede que um ator conhecido específico reentre através dos identificadores que você aplicou, e aumenta o custo de regeneração. Detectar a extração em primeiro lugar é trabalho da sua camada de tráfego, e limitar o que a extração produz é trabalho da sua camada de modelo. Esta é a parte de aplicação de uma defesa de três camadas, não um substituto para as outras duas.

Pronto para começar?

A API de Listas está disponível em todas as contas Didit.

• Leia a documentação — Visão geral da API de Listas e o catálogo de avisos de IP e Dispositivo.
• Veja o produto — Verificação de Usuário.
• Verifique os preços — publicados, pague pelo sucesso, sem mínimos.
• Comece grátis — business.didit.me, 500 verificações KYC por mês sem custo.