Propagació de la llista de bloqueig: Un cas d'abús confirmat acaba amb tota la xarxa (CA)

Hi ha un moment concret on la majoria de programes d'abús perden valor: el moment després de guanyar.

La vostra capa de trànsit marca un compte. Un analista investiga. L'evidència és sòlida, el cas està confirmat, el compte està prohibit. I aleshores, hores després, el mateix operador torna amb nous comptes, perquè l'únic que va tocar la vostra aplicació va ser una fila en una taula d'usuaris.

Anthropic va descriure exactament aquesta dinàmica en el seu informe de febrer de 2026 sobre campanyes de destil·lació —una xarxa proxy que "va gestionar més de 20.000 comptes fraudulents simultàniament", reemplaçant-los a mesura que eren eliminats. L'eliminació no era el coll d'ampolla. La regeneració era més barata que l'eliminació.

La solució és fer que l'aplicació operi sobre identificadors en lloc de comptes. L'API de Llistes de Didit es basa en una mecànica que ho fa amb una sola trucada.

Punts clau

• Bloquejar amb reference_session_id fa que Didit extregui automàticament el valor correcte de la sessió —cara, document, telèfon, correu electrònic, IP o dispositiu—, marqui el model subjacent com a bloquejat i enllaci l'entrada amb la sessió d'origen.
• 12 tipus d'entrada: face, document, phone, email, ip_address, device_fingerprint, wallet_address, bank_account, user, business, country, key.
• Les llistes de bloqueig són creades pel sistema, una per tipus d'entrada, i immutables. No les podeu crear, cosa que fa que l'aplicació sigui uniforme.
• Les entrades tenen efecte immediatament en el moment de la verificació. Suprimir una entrada desbloqueja la coincidència.
• ip_address accepta un rang CIDR, de manera que podeu bloquejar infraestructures en lloc d'una única adreça.
• Les llistes permeses (allowlists) en els mateixos 12 tipus mantenen els desenvolupadors de confiança fora de qualsevol via d'escalada.

Els dos tipus de llistes que importen

L'API té tres tipus de llistes, i la distinció entre elles és deliberada.

Les llistes de bloqueig són creades pel sistema —una per tipus d'entrada— i immutables. No les podeu crear, canviar el nom ni suprimir-les. Només podeu afegir i eliminar entrades. Aquesta restricció és una característica: significa que "bloquejat" té exactament un significat a tota la vostra organització, i no hi ha manera d'acabar amb quatre llistes de bloqueig de cares que competeixen entre si i que diferents serveis comproven de manera inconsistent.

Les llistes permeses són vostres per crear. Aquí hi van els dispositius coneguts com a bons, els rangs d'adreces, les entitats comercials i els usuaris.

Les llistes personalitzades són per a tot la resta —les vostres pròpies taxonomies, grups de vigilància, cohorts de revisió.

# Troba la llista de bloqueig de cares
curl -X GET 'https://verification.didit.me/v3/lists/?list_type=blocklist&entry_type=face' \
  -H 'x-api-key: YOUR_API_KEY'

La mecànica que importa

Aquí teniu la manera ordinària de bloquejar alguna cosa, i és la manera incorrecta en gairebé totes les situacions reals:

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" }'

Això bloqueja una adreça. Mentrestant, la sessió que estavau investigant també portava una cara, un número de document, un telèfon, un correu electrònic i una empremta digital del dispositiu —cadascun d'ells un identificador que l'operador ha de reemplaçar abans de tornar.

La millor trucada:

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" }'

Passa reference_session_id i Didit extreu automàticament el valor correcte per al tipus d'entrada d'aquesta llista de la sessió, marca el model subjacent com a bloquejat i enllaça l'entrada de nou a la sessió perquè la consola us pugui mostrar d'on prové.

D'això se'n deriven tres coses, i totes tres importen operacionalment:

Sense extracció manual. El vostre analista no llegeix una empremta digital del dispositiu d'una pantalla i la reescriu. Els errors de transcripció en les dades d'aplicació són errors silenciosos —la prohibició simplement no s'activa, i ningú se n'assabenta.

La procedència es conserva. Cada entrada s'enllaça amb la sessió que la va justificar. Quan algú pregunta d'aquí a quatre mesos per què aquest dispositiu està bloquejat, la resposta és un clic, no un projecte d'arqueologia.

L'aplicació és repetible. La mateixa trucada contra cada llista de bloqueig de tipus d'entrada cobreix tota la superfície d'identificadors de la sessió.

Si una sessió conté múltiples instàncies del mateix tipus, passa value juntament amb reference_session_id per desambiguar.

També pots aplicar des de fora d'una sessió de verificació. reference_object_uuid juntament amb metadata.reference_type — transaction, vendor_user o vendor_business — bloqueja des d'una transacció o des d'un usuari o negoci del venedor, i manté el mateix enllaç amb la font.

Els 12 tipus d'entrada

Tipus d'entrada	Bloqueja	Notes
face	La persona	També es pot carregar directament mitjançant la càrrega de cara
document	La credencial
phone	El número	Normalitzat automàticament a E.164
email	L'adreça
ip_address	L'adreça o rang	Accepta CIDR, p. ex. 10.0.0.0/8
device_fingerprint	La màquina	Mínim 8 caràcters alfanumèrics
wallet_address	L'adreça on-chain
bank_account	El compte
user	El registre d'usuari
business	L'entitat
country	La jurisdicció
key	Una clau personalitzada

Dos d'ells mereixen una menció especial per a aquest problema.

ip_address accepta un rang CIDR. Bloquejar 203.0.113.0/24 bloqueja la infraestructura, no una adreça. Quan una operació de "farming" s'executa en una subxarxa llogada, aquesta és la diferència entre una aplicació que escala i una aplicació que juga a "whack-a-mole". Utilitzeu-lo amb cura —un rang també cobreix usuaris reals, i els rangs massa amplis són la manera com prohibiu en silenci un operador de telefonia mòbil d'un país.

face admet la càrrega directa. Quan teniu una imatge però no una sessió, carregueu-la directament:

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>" }'

Didit extreu la biometria. A partir d'aquest moment, aquesta cara es verifica a cada verificació.

Què passa després que una entrada s'afegeix

Afegir a una llista de bloqueig del sistema bloqueja les futures coincidències immediatament en el moment de la verificació. No hi ha cap retard de propagació ni cap tasca per lots.

A la següent verificació, l'aplicació es manifesta com a advertències:

• FACE_IN_BLOCKLIST — coincidència definitiva, verificació denegada. POSSIBLE_FACE_IN_BLOCKLIST és una coincidència límit per sota del llindar dur i hauria d'anar a revisió, no a denegació.
• IP_ADDRESS_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_BLOCKLIST — impactes de xarxa i dispositiu.

A la cerca de cares, una coincidència de la llista de bloqueig és l'única cosa que estableix l'status a "Declined". Cada coincidència a la resposta també porta is_blocklisted, de manera que una investigació us mostra immediatament quines parts d'un clúster ja estan sota aplicació i quines encara estan actives.

L'eliminació és simètrica: suprimir una entrada desbloqueja l'entitat coincident. L'aplicació és reversible per disseny, cosa que importa perquè una aplicació massa àmplia és un risc real i cal un camí clar de tornada.

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

Llistes permeses: protegint els desenvolupadors que voleu

Una aplicació que només escala acaba per ofegar el producte. Els mateixos 12 tipus d'entrada admeten llistes permeses, i són la vàlvula de pressió.

Permeteu els rangs d'IP de l'oficina d'un soci de disseny. Permeteu els dispositius de l'equip d'enginyeria d'un client empresarial. Permeteu una entitat comercial verificada perquè els seus usuaris mai arribin a un camí d'escalada. IP_ADDRESS_IN_ALLOWLIST i DEVICE_FINGERPRINT_IN_ALLOWLIST s'activen quan es produeix una coincidència, de manera que podeu confirmar que l'exempció s'ha aplicat en lloc de suposar-ho.

Aquest és el mecanisme que fa que l'aplicació agressiva sigui suportable. Podeu permetre-us una política estricta sobre infraestructures desconegudes precisament perquè la vostra població coneguda com a bona està explícitament exclosa.

Errors que val la pena gestionar

• 400 — el valor no ha superat el validador del tipus d'entrada, el list_type és incorrecte per a l'operació (per exemple, una càrrega de cara contra una llista que no és de cara), o reference_session_id no té dades del tipus sol·licitat. Aquest últim cas és comú i benigne: no totes les sessions capturen tots els identificadors.
• 403 — {"detail": "No teniu permís per realitzar aquesta acció."}

Tingueu en compte que s'espera un 400 de "la sessió no té dades d'aquest tipus" quan es recorre una sessió a través de totes les llistes de bloqueig per tipus d'entrada. Gestioneu-ho com a salt, no com a error.

Un flux d'aplicació elaborat

Un analista ha confirmat un abús en el compte acct_8842.

1. Resoldre primer el clúster. La cerca de cares a la sessió retorna dotze comptes; la correlació de dispositius i IP n'afegeix una dotzena més. L'aplicació abans de la resolució prohibeix un compte i adverteix l'operador.
2. Bloquejar des de la sessió confirmada — reference_session_id contra les llistes de bloqueig de cara, dispositiu, IP, correu electrònic, telèfon i document. Sis trucades, sense extracció manual, procedència completa.
3. Considerar l'abast. Si l'evidència de la xarxa apunta a una infraestructura llogada, una entrada CIDR cobreix la subxarxa. Comproveu què més hi ha abans.
4. Actuar sobre el clúster segons la vostra pròpia política —els comptes que ja heu identificat no es desbloquegen sols.
5. Verificar l'aplicació. Torneu a executar la cerca de cares. Les coincidències ara haurien de portar is_blocklisted: true.
6. Esperar l'intent de regeneració. El següent compte creat amb aquesta cara, dispositiu o subxarxa es denega en la verificació en lloc d'aparèixer en el vostre trànsit tres setmanes després.

El pas 6 és el punt clau. El cost de l'operador per tornar ja no és "crear una nova adreça de correu electrònic". És "adquirir nou maquinari, nova xarxa i una nova persona".

Casos d'ús

Plataformes d'API d'IA que converteixen un cas d'abús o destil·lació confirmat en una aplicació a tots els identificadors que l'operador va tocar.

Abús de proves i crèdits on el mateix dispositiu i cara segueixen tornant per una nova assignació gratuïta.

Mercats que bloquegen els venedors eliminats perquè no es tornin a registrar amb un nou negoci.

iGaming que aplica l'autoexclusió, on un jugador exclòs que torna és un error regulador i l'aplicació a nivell de cara és l'únic control fiable.

Preguntes freqüents

Puc crear la meva pròpia llista de bloqueig?

No. Les llistes de bloqueig són creades pel sistema, una per tipus d'entrada, i immutables; només podeu afegir i eliminar entrades. Podeu crear llistes permeses i llistes personalitzades lliurement. La restricció fa que "bloquejat" signifiqui una sola cosa a tot arreu.

Quina rapidesa té una entrada per tenir efecte?

Immediatament, a la següent verificació.

Què passa si bloqueo alguna cosa per error?

Suprimeix l'entrada i l'entitat es desbloqueja. Per això, la procedència és important: cada entrada creada a partir d'una sessió s'hi enllaça, de manera que pots auditar per a què servia una entrada abans d'eliminar-la.

El bloqueig d'un rang d'IP afecta els usuaris legítims d'aquest rang?

Sí, i aquest és el risc. Una entrada CIDR bloqueja tot el que hi ha dins. Utilitzeu rangs quan l'evidència apunti a una infraestructura dedicada, utilitzeu adreces úniques en cas contrari i permeteu els rangs coneguts com a bons primer.

Puc bloquejar des d'una cosa que no sigui una sessió de verificació?

Sí. reference_object_uuid més metadata.reference_type (transaction, vendor_user o vendor_business) cobreix transaccions i usuaris o empreses del venedor.

Això atura l'extracció de models?

No. Atura un actor conegut i específic d'entrar de nou a través dels identificadors contra els quals heu aplicat la normativa, i augmenta el cost de la regeneració. Detectar l'extracció en primer lloc és feina de la vostra capa de trànsit, i limitar el que l'extracció produeix és feina de la vostra capa de model. Aquest és el braç d'aplicació d'una defensa de tres capes, no un reemplaçament de les altres dues.

Llest per començar?

L'API de Llistes està disponible a tots els comptes de Didit.

• Llegiu la documentació — Visió general de l'API de Llistes i el catàleg d'advertències d'IP i dispositius.
• Vegeu el producte — Verificació d'usuaris.
• Consulteu els preus — publicats, pagament per èxit, sense mínims.
• Comenceu gratis — business.didit.me, 500 verificacions KYC al mes sense cost.