跳到主要内容
Didit 融资 750 万美元，打造身份与欺诈基础设施
Didit
返回博客
博客 · 2026年8月4日

封禁列表传播：让单个确认的滥用案例扼杀整个网络 (ZH)

封禁一个账户就像从九头蛇身上砍掉一个头。通过会话进行封禁，Didit能自动提取该会话中涉及的所有标识符——面部、证件、电话、电子邮件、IP、设备——涵盖12种入口类型，确保下一个账户在入口处就被阻止。.

作者：Didit更新于
ai-api-abuse-blocklist-propagation.png

大多数滥用防范程序在某个特定时刻会流失价值：那就是在你成功之后。

你的流量层标记了一个账户。分析师进行调查。证据确凿，案件得到确认，账户被封禁。然而，几小时后，同一个操作员又通过新账户回来了，因为你的执法措施只触及了用户表中的一行记录。

Anthropic在其2026年2月关于“蒸馏攻击”的报告中精确描述了这种动态——一个代理网络“同时管理着20,000多个欺诈账户”，并在它们被移除后立即替换。移除不是瓶颈。再生比移除更便宜。

解决方案是让执法措施作用于标识符而非账户。Didit的列表API围绕一个机制构建，可以通过一次调用实现这一点。

主要收获

  • 通过reference_session_id进行封禁，Didit可以自动从会话中提取正确的值——面部、证件、电话、电子邮件、IP或设备——将底层模型标记为已封禁，并将条目链接回源会话。
  • 12种入口类型：face（面部）、document（证件）、phone（电话）、email（电子邮件）、ip_address（IP地址）、device_fingerprint（设备指纹）、wallet_address（钱包地址）、bank_account（银行账户）、user（用户）、business（企业）、country（国家）、key（密钥）。
  • 封禁列表是系统创建的，每种入口类型一个，且不可变。你无法创建它们，这正是执法统一性的原因。
  • 条目在验证时立即生效。删除条目会解除匹配的封禁。
  • ip_address接受一个CIDR范围，因此你可以封禁基础设施而非单个地址。
  • 在相同的12种类型上建立允许列表，让受信任的开发者免于所有升级路径。

两种重要的列表类型

API有三种列表类型，它们之间的区别是经过深思熟虑的。

封禁列表是系统创建的——每种入口类型一个——且不可变。你不能创建、重命名或删除它们。你只能添加和移除条目。这种限制是一个特性：这意味着“已封禁”在你的组织中只有一个确切的含义，并且不会出现四个相互竞争的面部封禁列表，被不同服务不一致地检查的情况。

允许列表由你创建。已知良好的设备、地址范围、商业实体和用户都放在这里。

自定义列表用于其他所有情况——你自己的分类法、观察组、审查队列。

# 查找面部封禁列表
curl -X GET 'https://verification.didit.me/v3/lists/?list_type=blocklist&entry_type=face' \
  -H 'x-api-key: YOUR_API_KEY'

重要的机制

这是封禁某物的普通方式，但在几乎所有实际情况中都是错误的方式：

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

这只会封禁一个地址。而你正在调查的会话还包含了面部、证件号码、电话、电子邮件和设备指纹——操作员在返回之前必须替换所有这些标识符。

更好的调用方式是：

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

传递reference_session_id后，Didit会自动从会话中提取该列表入口类型对应的正确值，将底层模型标记为已封禁，并将条目链接回会话，以便控制台可以显示其来源。

由此产生了三点，这三点在操作上都非常重要：

无需手动提取。你的分析师无需从屏幕上读取设备指纹并重新输入。执法数据中的转录错误是无声的失败——封禁根本不会触发，而且没有人会发现。

保留出处。每个条目都链接回证明其合理性的会话。当有人在四个月后询问为什么此设备被封禁时，答案只需点击一下，而不是一个考古项目。

执法可重复。针对每个入口类型封禁列表的相同调用覆盖了会话的整个标识符表面。

如果一个会话包含同一类型的多个实例，请在reference_session_id旁边传递value以消除歧义。

你也可以在验证会话之外进行执法。reference_object_uuid与metadata.reference_type（transaction、vendor_user或vendor_business）结合使用，可以从交易或供应商用户或企业进行封禁，并保持与源的相同链接。

12种入口类型

入口类型封禁对象备注
face个人也可通过面部上传直接加载
document凭证
phone号码自动标准化为E.164
email地址
ip_address地址或范围接受CIDR，例如10.0.0.0/8
device_fingerprint设备最少8个字母数字字符
wallet_address链上地址
bank_account账户
user用户记录
business实体
country司法管辖区
key自定义密钥

其中有两点值得在此问题中特别指出。

ip_address接受CIDR范围。封禁203.0.113.0/24是封禁基础设施，而不是一个地址。当一个“农场”操作在租用的子网运行时，这是可扩展的执法和“打地鼠”式执法之间的区别。请谨慎使用——一个范围也可能覆盖真实用户，过度宽泛的范围可能会悄悄地封禁一个国家的移动运营商。

face支持直接上传。当你有一张图像但没有会话时，可以直接加载它：

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会提取生物识别信息。从那时起，该面部将在每次验证时受到筛查。

条目生效后会发生什么

添加到系统封禁列表的条目将在验证时立即阻止未来的匹配。没有传播延迟，也没有批处理作业。

在下一次验证时，执法措施会以警告形式出现：

  • FACE_IN_BLOCKLIST — 确定性匹配，验证被拒绝。POSSIBLE_FACE_IN_BLOCKLIST是低于硬阈值的边缘匹配，应路由到审查，而不是拒绝。
  • IP_ADDRESS_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_BLOCKLIST — 网络和设备命中。

在面部搜索中，封禁列表匹配是唯一能将status设置为"Declined"的情况。响应中的每个匹配项也带有is_blocklisted，因此调查可以立即显示集群的哪些部分已经受到执法，哪些仍然活跃。

移除是对称的：删除条目会解除匹配实体的封禁。执法措施在设计上是可逆的，这一点很重要，因为过度宽泛的执法是一个真实的风险，你需要一个清晰的恢复路径。

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

允许列表：保护你想要的开发者

只会升级的执法最终会扼杀产品。相同的12种入口类型支持允许列表，它们是压力阀。

将设计合作伙伴的办公室IP范围列入允许列表。将企业客户工程团队的设备列入允许列表。将已验证的企业实体列入允许列表，这样其用户就不会进入升级路径。当发生匹配时，IP_ADDRESS_IN_ALLOWLIST和DEVICE_FINGERPRINT_IN_ALLOWLIST会触发，因此你可以确认豁免已应用，而不是假设它已应用。

这是使激进执法得以存活的机制。你可以对未知基础设施采取严格的策略，正是因为你明确排除了已知良好的用户群体。

值得处理的错误

  • 400 — 值未能通过入口类型的验证器，list_type对于操作错误（例如，对非面部列表进行面部上传），或者reference_session_id没有请求类型的数据。后一种情况很常见且无害：并非每个会话都捕获所有标识符。
  • 403 — {"detail": "您没有执行此操作的权限。"}

请注意，当你在所有入口类型封禁列表上循环会话时，来自“会话没有该类型数据”的400错误是预期的。将其视为跳过，而不是失败。

一个已完成的执法流程

分析师已确认账户acct_8842存在滥用行为。

  1. 首先解决集群问题。对会话中的面部进行面部搜索会返回十二个账户；设备和IP关联会再拉入十几个。在解决问题之前进行执法只会封禁一个账户并警告操作员。
  2. 从已确认的会话中进行封禁——针对面部、设备、IP、电子邮件、电话和证件封禁列表使用reference_session_id。六次调用，无需手动提取，完整溯源。
  3. 考虑范围。如果网络证据指向租用基础设施，则CIDR条目会覆盖该子网。首先检查那里还有什么。
  4. 根据你自己的策略对集群采取行动——你已经识别出的账户不会自行解除封禁。
  5. 验证执法。重新运行面部搜索。匹配项现在应该带有is_blocklisted: true。
  6. 等待再生尝试。在该面部、设备或子网上创建的下一个账户将在验证时被拒绝，而不是三周后出现在你的流量中。

第6步是关键所在。操作员返回的成本不再是“创建一个新的电子邮件地址”。而是“获取新硬件、新网络和新人”。

用例

  • AI API平台将已确认的“蒸馏攻击”或滥用案例转化为对操作员接触过的每个标识符的执法。
  • 试用和信用滥用，同一设备和面部不断返回以获取新的免费分配。
  • 市场平台阻止已被移除的卖家以新业务重新注册。
  • iGaming（在线博彩）执行自我排除，被排除的玩家重新出现是监管失败，面部层级的执法是唯一可靠的控制措施。

常见问题

我可以创建自己的封禁列表吗？

不可以。封禁列表是系统创建的，每种入口类型一个，且不可变——你只能添加和移除条目。你可以自由创建允许列表和自定义列表。这种限制确保了“已封禁”在任何地方都只有一个含义。

条目多久生效？

立即生效，在下一次验证时。

如果我错误地封禁了某物怎么办？

删除该条目，实体就会被解除封禁。这就是为什么出处很重要——从会话创建的每个条目都链接回该会话，因此你可以在删除之前审核该条目的用途。

封禁IP范围会影响该范围内的合法用户吗？

是的，这就是风险所在。CIDR条目会阻止其中的所有内容。当证据指向专用基础设施时，请使用范围；否则，请使用单个地址；并首先将已知良好的范围列入允许列表。

我可以从非验证会话中进行封禁吗？

可以。reference_object_uuid加上metadata.reference_type（transaction、vendor_user或vendor_business）涵盖了交易和供应商用户或企业。

这能阻止模型提取吗？

不能。它阻止的是一个特定的已知行为者通过你已强制执行的标识符重新进入，并提高了再生的成本。首先检测提取是你的流量层的工作，限制提取的产出是你的模型层的工作。这是三层防御中的执法层，而不是替代其他两层。

准备好开始了吗？

列表API在每个Didit账户上都可用。

继续阅读

相关文章

身份与欺诈基础设施。

一个 API 即可实现 KYC、KYB、交易监控和钱包筛选。5 分钟即可集成。

免费开始联系我们
让 AI 总结此页面
12种入口类型的封禁列表传播 | Didit.