Propagação de Listas Negras: Como um Caso de Abuso Confirmado Pode Neutralizar Toda a Rede (PT-PT)

Há um momento específico em que a maioria dos programas de combate ao abuso perde valor: o momento depois de ganhar.

A 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 com novas contas, porque a única coisa que a sua aplicação tocou foi uma linha numa tabela de utilizadores.

A Anthropic descreveu exatamente esta dinâmica no seu relatório de fevereiro de 2026 sobre campanhas de destilação — uma rede proxy que “geriu 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 do 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 um mecanismo que faz isso numa única chamada.

Principais conclusões

• A inclusão em lista negra 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 incluído em lista negra e ligue 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 listas negras são criadas pelo sistema, uma por tipo de entrada, e imutáveis. Não pode criá-las, o que torna a aplicação uniforme.
• As entradas entram em vigor imediatamente no momento da verificação. Eliminar uma entrada desbloqueia a correspondência.
• ip_address aceita um intervalo CIDR, para que possa incluir em lista negra a infraestrutura em vez de um único endereço.
• As listas brancas para os mesmos 12 tipos mantêm os desenvolvedores confiáveis fora de qualquer caminho de escalonamento.

Os dois tipos de lista que importam

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

As listas negras são criadas pelo sistema — uma por tipo de entrada — e imutáveis. Não pode criá-las, renomeá-las ou eliminá-las. Apenas adiciona e remove entradas. Esta restrição é uma característica: significa que “incluído em lista negra” tem exatamente um significado em toda a sua organização, e não há como acabar com quatro listas negras de rosto concorrentes que diferentes serviços verificam de forma inconsistente.

As listas brancas são suas para criar. Dispositivos conhecidos, intervalos de endereços, entidades comerciais e utilizadores vão aqui.

As listas personalizadas são para tudo o resto — as suas próprias taxonomias, grupos de vigilância, coortes de revisão.

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

O mecanismo que importa

Aqui está a forma comum de incluir algo em lista negra, e é a forma 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 inclui um endereço em lista negra. Entretanto, a sessão que estava a investigar 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 tem de 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 incluído em lista negra e liga a entrada de volta à sessão para que a consola possa mostrar de onde veio.

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

Sem extração manual. O seu analista não lê uma impressão digital do dispositivo num ecrã e a redigita. Erros de transcrição nos dados de aplicação são falhas silenciosas — o banimento simplesmente não é acionado, e ninguém descobre.

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

A aplicação é repetível. A mesma chamada contra cada lista negra 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 juntamente com reference_session_id para desambiguar.

Também pode aplicar a partir de fora de uma sessão de verificação. reference_object_uuid juntamente com metadata.reference_type — transaction, vendor_user ou vendor_business — inclui em lista negra a partir de uma transação ou de um utilizador ou empresa fornecedor, e mantém a mesma ligação de volta à fonte.

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 na cadeia
bank_account	A conta
user	O registo do utilizador
business	A entidade
country	A jurisdição
key	Uma chave personalizada

Dois merecem destaque para este problema.

ip_address aceita um intervalo CIDR. Incluir 203.0.113.0/24 em lista negra bloqueia a infraestrutura, não um endereço. Quando uma operação de farming funciona numa sub-rede alugada, esta é a diferença entre uma aplicação que escala e uma aplicação que joga “whack-a-mole”. Use-o com cuidado — um intervalo cobre também utilizadores reais, e intervalos muito amplos é como se bane silenciosamente uma operadora móvel de um país.

face suporta upload direto. Quando 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 biométrico. A partir daí, esse rosto é verificado em todas as verificações.

O que acontece depois de uma entrada ser registada

Adicionar a uma lista negra do sistema bloqueia correspondências futuras 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 limiar rígido e deve ser encaminhada para revisão, não para recusa.
• IP_ADDRESS_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_BLOCKLIST — acertos de rede e dispositivo.

Na Pesquisa Facial, uma correspondência de lista negra é 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 lhe mostre imediatamente quais partes de um cluster já estão sob aplicação e quais ainda estão ativas.

A remoção é simétrica: eliminar uma entrada desbloqueia a entidade correspondente. A aplicação é reversível por design, o que importa porque uma aplicação muito abrangente é um risco real e precisa de um caminho limpo de volta.

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

Listas brancas: protegendo os desenvolvedores que deseja

A aplicação que apenas escala acaba por estrangular o produto. Os mesmos 12 tipos de entrada suportam listas brancas, e são a válvula de escape.

Inclua na lista branca os intervalos de IP do escritório de um parceiro de design. Inclua na lista branca os dispositivos da equipa de engenharia de um cliente empresarial. Inclua na lista branca uma entidade comercial verificada para que os seus utilizadores nunca atinjam um caminho de escalonamento. IP_ADDRESS_IN_ALLOWLIST e DEVICE_FINGERPRINT_IN_ALLOWLIST são acionados quando ocorre uma correspondência, para que possa confirmar que a isenção foi aplicada em vez de assumir que o foi.

Este é o mecanismo que torna a aplicação agressiva sustentável. Pode permitir-se uma política rigorosa em infraestruturas desconhecidas precisamente porque a sua população conhecida e boa está 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. Este último caso é comum e benigno: nem toda a sessão captura todos os identificadores.
• 403 — {"detail": "Não tem permissão para realizar esta ação."}

Note que um 400 de “a sessão não tem dados desse tipo” é esperado quando faz um loop numa sessão através de todas as listas negras de tipo de entrada. Trate-o como um salto, 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 dispositivos e IP adiciona mais uma dúzia. A aplicação antes da resolução bane uma conta e avisa o operador.
2. Inclua em lista negra a partir da sessão confirmada — reference_session_id contra as listas negras 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 da rede apontar para infraestrutura alugada, uma entrada CIDR cobre a sub-rede. Verifique primeiro o que mais vive lá.
4. Aja no cluster de acordo com a sua própria política — as contas que já identificou não se desbanem sozinhas.
5. Verifique a aplicação. Execute novamente a pesquisa facial. As correspondências devem agora conter is_blocklisted: true.
6. Aguarde a tentativa de regeneração. A próxima conta criada com esse rosto, dispositivo ou sub-rede é recusada na verificação em vez de aparecer no seu tráfego três semanas depois.

O passo 6 é o ponto principal. O custo do operador para retornar já não é “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 de destilação ou abuso confirmado em aplicação em cada identificador que o operador tocou.

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

Marketplaces bloqueando vendedores removidos de se registrarem novamente sob uma nova empresa.

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

Perguntas frequentes

Posso criar a minha própria lista negra?

Não. As listas negras são criadas pelo sistema, uma por tipo de entrada, e imutáveis — apenas adiciona e remove entradas. Pode criar listas brancas e listas personalizadas livremente. A restrição mantém o significado de “incluído em lista negra” o mesmo em todo o lado.

Com que rapidez uma entrada entra em vigor?

Imediatamente, na próxima verificação.

E se eu incluir algo em lista negra por engano?

Elimine a entrada e a entidade é desbloqueada. É por isso que a proveniência importa — cada entrada criada a partir de uma sessão liga-se de volta a ela, para que possa auditar para que servia uma entrada antes de a remover.

Incluir um intervalo de IP em lista negra afeta utilizadores legítimos nesse intervalo?

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

Posso incluir em lista negra 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) cobre transações e utilizadores ou empresas fornecedores.

Isso impede a extração de modelos?

Não. Impede que um ator conhecido específico reentre através dos identificadores contra os quais aplicou, e aumenta o custo de regeneração. Detetar 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. Este é o braço 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 Dispositivos.
• Veja o produto — Verificação de Utilizador.
• Verifique os preços — publicamente listados, pague por sucesso, sem mínimos.
• Comece gratuitamente — business.didit.me, 500 verificações KYC por mês sem custos.