对比

Proof of Actor 与 API 机器人防护: 密钥说明谁在付费，actor 上下文说明谁在执行

API 网关、WAF 机器人规则、API 密钥和速率限制让你的 API 保持可用并可追责。它们并不是为判断某个请求来自应用中的人、与助手协作的人，还是来自自主 agent 而设计的。下面说明 API 的机器人管理如何与 Proof of Actor 对比，以及两者如何配合使用。

获取抢先访问了解其工作原理

作者 Toshendra Sharma创始人兼 CEO，AgentCredia · Updated November 13, 2026

API 曾经有一个很简单的流量模型。开发者注册、拿到 key、编写集成，然后该集成按计划或在用户点击时调用你的 endpoint。面向 API 的机器人管理就是围绕这个模型发展起来的: 验证 key、限制流量、过滤明显的滥用请求，并让服务对其他人保持可用。

这个模型依然成立，围绕它构建的工具也依然重要。变化在于调用背后是谁在执行。同一个 API key 现在可能承载来自客户应用中某个人的请求，来自要求 AI 助手代为完成工作的人的请求，以及来自夜间执行多步骤任务的自主 agent 的请求。你现有的控制措施只能看到一个 key 和一个请求速率，而你的产品、支持和 policy 决策往往需要更多信息。

Proof of Actor 弥补了这个空白。它向你的 API 说明每个请求背后是谁或什么在行动，并给出 evidence，然后把决定权留给你的代码。本页将它与 API 机器人防护的主要层进行对比，帮助你了解各自的位置。

	API 机器人防护	Proof of Actor
主要问题	这个请求是否允许、是否已认证、是否在限制内？	谁或什么在执行，依据是什么？
典型层	API 网关、WAF 机器人规则、API keys、速率限制	在你的 API 或 MCP server 内部进行 actor 分类
识别对象	拥有该 key 的账号或集成	每个请求背后的 actor: Human、Human + AI、Agent 或 Unknown
输出	allow、reject、throttle; 有时还有 bot score	一个 class 加一个 basis: verified、declared、inferred 或 unknown
不明确流量	通常在 key 有效时放行，或按规则拒绝	Unknown，并按你选择的 route 进行回退
谁决定响应	网关和 WAF 配置	你的应用代码
安装后的默认行为	enforcement	observation; 在你添加 policy 之前不会改变任何行为
最擅长	可用性、滥用过滤、配额、可追责性	为每类 actor 正确提供服务并理解 API 使用情况

API 机器人防护擅长什么

有必要明确每一层各自负责什么，因为 Proof of Actor 的设计是与它们并列，而不是取代任何一层。

API gateways

gateway 是你的 API 的前门。它终止连接，验证 API keys 或 tokens，将请求路由到正确的服务，执行配额限制，并且通常会记录使用情况以用于计费和分析。它快速而一致地回答“这个调用者是否允许进入，以及从哪扇门进入？”这个问题，覆盖每个 endpoint。

WAF bot rules

带有 bot rules 的 web application firewall 会检查流量中的已知攻击模式和滥用型自动化行为。它可以过滤注入尝试，阻止来自有滥用历史来源的流量，并对看起来像爬取或凭证攻击的请求进行 challenge 或直接丢弃。这是防止不应到达你代码的流量的最佳防线。

API keys 和 tokens

keys 和 tokens 提供可追责性。每个请求都会映射到某个账号，因此你知道是谁的集成发起了调用，你可以撤销访问权限，并且可以归因使用情况。作用域 token 还能进一步限制调用者可以执行的操作。

速率限制

速率限制保护可用性。它们防止某个集成消耗原本应服务于所有人的容量，也能减缓暴力破解和枚举攻击。按 key 和按 route 进行限制，是标准且有效的控制措施。

这些层放在一起时，已经能很好地回答防护和可追责这两个问题。请保留它们。

它们原本没有被设计用来回答的问题

上述任何一层都不是为了告诉你，经过认证的请求背后是哪一类 actor。有效的 key 只能说明哪个账号拥有该集成。它并不能说明:

这个具体调用是否来自你客户应用里点击按钮的人，
是否有人要求 AI 助手执行该动作，
是否某个自主 agent 作为更长任务中的一步发起了调用，
或者是否无法判断。

这个区别每个月都更重要。服务于 CRM 集成、排程工具或开发者平台的 API，越来越多地会通过同样的 key 接收 agent 流量，而这些 key 同时也服务于由人驱动的应用。如果你希望给 agent 返回结构化响应，对 agent 驱动的高影响写操作要求确认，为 AI 辅助提交添加标签，或者只是统计你的 API 使用中有多少来自 agent，你就需要 actor 上下文。

Proof of Actor 为 API 增加了什么

Proof of Actor 会为每次交互返回四种 class 之一:

Human: 可观察到的信号表明这是由人直接驱动的交互。
Human + AI: 由人发起，并通过支持的集成声明或观察到有 AI 辅助。
Agent: 自动化或由 agent 发起的交互。
Unknown: 证据不足以得出可靠判断。

每个结果还会说明其 evidence basis:

Verified: 例如，经过发布的 key 校验的 HTTP Message Signature (RFC 9421)。
Declared: 客户端或你自己的应用已声明这一点。
Inferred: 行为或上下文信号，并明确标注为推断。
Unknown: 没有可靠 basis。

对于 API，verified basis 尤为有用。对请求进行签名的 agent 可以根据其已发布的 key 进行检查，这也是 IETF Web Bot Auth 工作背后的方法。关于背景，请阅读面向产品团队的 Web Bot Auth 说明；关于实现，请参阅验证已签名 agent 请求指南。

这里有一个限制需要注意。有效签名只能证明是哪个 key 对请求进行了签名，并不能证明该 agent 被授权执行该操作。授权仍然应该留在它所属的位置，也就是你的 API 自身的访问控制中。agent authorization 条目解释了两者的区别。

分数和 key 与 actor evidence 的区别

一些机器人防护产品会为每个请求附加分数。分数适合用于阻断决策，但对于 API 产品决策来说，作用较小，因为它无法告诉你一个合法请求是由人驱动还是由 agent 驱动，也无法区分已验证事实和推断。

API keys 的限制则相反。它们在所有权上很精确，但对 actor 保持沉默。某个客户的 key 在一小时内就可能承载全部四种 class。

Proof of Actor 会让这两个区别都保持可见。你的 API 可以看到来自 key 的账号、来自 Proof of Actor 的 actor class，以及支持该判断的 basis。每一层都回答它最擅长的问题。

每一层运行在哪里

gateway 和 WAF 运行在你网络的边缘，或者位于你的服务之前。这个位置非常适合做防护和配额控制。

Proof of Actor 运行在你的 API 逻辑所在之处。Founding 团队可以通过 Node.js middleware、Next.js、你控制的 edge 层、通用 HTTP API，或者 MCP server 集成来接入。完整列表请参见 integrations。由于它运行在你的应用内部，它可以使用你的 API 已知的信息: route、workflow、客户端是否声明了自己，以及签名是否验证通过。

路由决策仍然由你的代码负责

Proof of Actor 默认不会阻断任何内容。它从 observation mode 开始，因此安装它不会改变你的 API 响应方式。你可以看到按 endpoint 统计的 actor 组合，查看单个结果的 evidence，并观察 Unknown 比例。

当你准备好后，可以按 route、按 actor class 和按 basis 编写应用定义的 policy。常见结果包括:

Allow: 正常提供请求服务。
Adapt: 为已验证的 agent 返回结构化或精简后的响应。
Challenge: 要求额外确认步骤，例如在高影响写操作前进行人工批准。
Review: 将该操作排入队列，交由人工检查。
Rate-limit: 在特定 route 上对特定 class 和 basis 施加更严格的限制。

你可以先在真实流量上预览 policy，然后再逐 route 执行 enforcement。关于流程，请参阅安全推出具备 actor 感知的 policy 指南；在不阻断 agent 的情况下保护敏感操作展示了常见模式。

处理 Unknown API 调用者

每个 API 都会收到无法高置信度分类的流量。传统控制中，有效 key 通常意味着请求放行，无效 key 则意味着拒绝。中间没有状态。

Proof of Actor 提供明确的 Unknown 结果，并允许你按 route 选择回退策略。只读目录 endpoint 可以保持开放。账号变更可以继续沿用你现有的更严格检查。批量导出可以进入 review。详情请参见处理 Unknown 流量和未知的自动化流量。

它们如何协同工作

最强的 API 架构会让每一层各司其职:

在边缘，WAF 过滤滥用和格式异常的流量。
在网关，验证 keys、执行配额并记录使用情况。
在 API 内部，Proof of Actor 对每个通过的请求进行分类并给出 basis。
在你的 handler 中，policy 使用 class 和 basis 选择响应: 对由人驱动的调用正常处理，对已验证的 agent 返回结构化响应，对 agent 驱动的高影响写操作要求确认，对 Unknown 使用回退策略。
在分析中，你的团队可以看到每个 actor class 使用了哪些 endpoint 和 workflow，同时结合来自网关的账号数据。

这个栈中没有重复的职责。网关知道账号，WAF 知道威胁模式，而 Proof of Actor 知道 actor。

什么时候优先关注哪一项

当你的主要问题是滥用、可用性或未计量使用时，先关注 API 机器人防护: 针对 auth endpoint 的凭证攻击、激进爬取，或某个集成占满其他集成容量。

当你的主要问题是调用者本身时，优先关注 Proof of Actor: 你的 API 流量中有多少由 agent 驱动，哪些 agent 调用哪些 endpoint，人驱动和 agent 驱动的使用有何差异，以及哪些 route 需要 actor-aware policy。APIs use case 和 AI agent identification for APIs 会进一步展开。

运行生产 API 的大多数团队都需要同时回答这两类问题。

开始使用

Proof of Actor 目前处于 private beta。入选的 Founding developer 团队可在约定使用范围内免费使用最长 12 months，并且不会自动计费。申请 early access，并告诉我们你想理解的 API 以及调用者。

面向开发者

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human、Human + AI、Agent 或 Unknown。
basis: 证据有多强：Verified、Declared、Inferred 或 Unknown。
evidence: 结果背后的信号，让您的团队看清原因。

从观察模式开始: 将结果记录在日志旁边，在您选择 policy 之前不做任何更改。阅读 Node.js 集成指南

常见问题

Proof of Actor 会替代我的 API 网关或 WAF 吗？

不会。你的网关仍然负责验证密钥并执行配额限制，你的 WAF 仍然负责过滤滥用流量。Proof of Actor 在你的 API 内部运行，为通过前置防护的请求增加 actor 上下文。请保留你现有的控制措施。

如果每个调用者都有 API 密钥，为什么我还需要 actor 上下文？

API 密钥标识的是拥有该集成的账号。它并不能说明某个请求是由客户应用中点击按钮的人发起的，还是由使用 AI 助手的人发起的，抑或是由执行任务的自主 agent 发起的。Proof of Actor 会连同其 basis 一起报告这些信息。

Proof of Actor 能验证到底是哪个 agent 在调用我的 API 吗？

当客户端使用 HTTP Message Signatures (RFC 9421) 为请求签名并发布其 key 时，Proof of Actor 会检查该签名并返回 verified basis。有效签名只能证明是哪个 key 对请求进行了签名，并不能证明该 agent 有权执行该操作，因此授权仍然留在你的代码中。

Proof of Actor 会自动对我的 API 流量做速率限制或拦截吗？

不会。它默认从 observation 模式开始，不会阻止任何请求。rate-limit 是你可以在 policy 中按 route、actor class 和 basis 选择的一种结果，而 enforcement 仍然由你的代码负责。

如何把 Proof of Actor 接入一个 API？

Founding 团队可以使用 Node.js middleware、Next.js、你控制的 edge 集成，或者通用 HTTP API。MCP server 也有自己的集成方式。详情请参见 integrations 页面。

对于无法分类的调用者会发生什么？

它们会被报告为 Unknown，这是一种一等结果。你可以按 route 选择回退策略，例如在只读 endpoint 上允许通过，而在写入 endpoint 上保留更严格的检查。

了解谁在使用您的 app。

面向少数 founding developers 的私有 beta。

获取抢先访问查看定价

想先聊聊？联系创始人