跳转到主要内容
已验证的自动化

识别已验证的自动请求

当自动客户端对其请求进行签名时，你的应用可以检查该签名，并据此对调用方进行相应处理。Proof of Actor 将这项检查转化为清晰、可路由的结果。

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

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

并非所有自动流量都一样

自动客户端每分钟都会访问你的应用: 搜索爬虫、监控工具、合作伙伴集成、为用户抓取页面的 AI 助手，以及执行任务的自主 agent。多年来，大多数应用区分它们的唯一方式是 user-agent 头，这是一种任何客户端都可以随意设置的字符串。

这让应用团队陷入两难。若对所有自动化都持怀疑态度，就会降低客户所依赖的合法 agent 的使用体验。若相信这个头部字段，就等于允许任何人冒充知名爬虫。

已验证的自动请求改变了这一局面。当自动客户端使用其已发布的密钥对请求签名时，你的应用可以检查该签名，并在密码学层面知道究竟是哪个客户端签署了该请求。Proof of Actor 将这项检查纳入一个统一、一致的 actor 结果中，供你的代码进行路由判断。若想更深入了解该检查能证明什么、不能证明什么，请阅读 已签名的 AI agent 请求能证明什么。

请求签名的工作方式

用于自动流量的新兴方法采用 HTTP message signatures，其标准化定义见 RFC 9421，该标准规定了如何对 HTTP 消息的各个组成部分创建、编码和验证签名。客户端使用私钥对每个请求的选定部分进行签名，并在 header 中包含签名及其参数。然后，它会在与其控制的标识符相关联的位置发布对应的公钥，通常是其域名。

当请求到达时，接收方会获取或查找已发布的密钥，重建被签名的内容，并检查签名。如果验证通过，说明该请求是由持有该密钥的一方签署的。对自动流量签名的工作仍在 IETF 的 Web Bot Auth working group 中继续推进，其章程涵盖对自动客户端进行密码学认证，例如代表最终用户运行的爬虫和 AI agent；Web Bot Auth 词条对其作了概述。关于 已签名的 AI agent 请求能证明什么 的博客文章会逐步展示一个已验证请求的完整流程，而 APIs use case 则说明验证最先在哪些场景产生价值。

关于 验证已签名的 agent 请求 的指南则详细介绍了相关机制，包括时间戳、重放窗口和密钥缓存。

已验证的签名能证明什么，不能证明什么

这是妥善处理已验证自动请求时最重要的区别。

有效签名证明该请求是使用与已发布标识符关联的密钥签署的。如果该密钥属于运营方的域名，则该请求来自持有该运营方密钥的客户端。

有效签名不能证明:

  • 是谁指示了该 agent，或是否有人要求执行此操作;
  • 某个人是否将权限委托给了该 agent;
  • 运营方背后的真实世界法律身份;
  • 请求的操作在你的应用中是否安全或被允许。

这些都是不同的问题。你的应用会通过自身的凭证、授权模型和 policy 来回答它们。Proof of Actor 会刻意将这些层面区分开来，而 Detection & Limitations 页面会明确说明每类证据能够建立什么。

Proof of Actor 如何处理已验证的自动请求

Detect

你的集成会将请求上下文，包括任何签名 header，传递给 Proof of Actor。系统会根据已发布的密钥检查签名。通过验证的请求会以 Verified 基础记录。仅声明自身身份的客户端会以 Declared 记录。行为模式会以 Inferred 记录。当证据不足时，结果为 Unknown。只有在密码学检查通过时，才会提升为 Verified。

Understand

查看哪些已验证的运营方在调用你的应用、他们使用哪些 route、频率如何，以及这与已声明和未知自动化相比有何不同。每个结果上的证据摘要都会告诉你涉及了哪一个密钥和标识符，因此你的团队可以快速调查任何请求。

Route

在你的 policy 中使用该依据。常见模式包括:

  • 在只读 route 上为已验证 agent 提供结构化响应，例如 API 或页面的 Markdown 版本。
  • 对你识别出的已验证运营方提高 rate-limit，同时对已声明客户端保持标准限制。
  • 无论签名如何，对每条写入 route 都保留现有授权。
  • 为每条 route 明确定义未签名和 Unknown 调用方的回退处理。

由你的 policy 决定，Proof of Actor 提供证据。

为什么 user-agent header 还不够

user-agent 字符串只是声明。任何客户端都可以发送任意值，而且 user-agent spoofing 不需要什么技巧。这就是爬虫运营方会发布自己的检查方法的原因: Google 记录了用于 验证 Googlebot 的反向和正向 DNS 查询以及已发布的 IP 段，Bing 记录了用于 验证 Bingbot 的 DNS 检查，而 OpenAI 为其每个 crawlers and user agents 发布了 IP 段文件。Proof of Actor 将 user-agent 声明视为已声明证据，绝不将其视为验证。这意味着，一个自称知名爬虫但没有有效签名的客户端，会被报告为具有已声明或已推断基础，而你的 policy 可以将其与已证明身份的客户端区别对待。

这正是已验证自动请求的价值所在: 它们为你提供了一种可靠方式，把信任扩展给那些赢得信任的客户端，而不是扩展给每一个复制其 header 的客户端。

身份证据、凭证与授权

在任何服务自动客户端的应用中，以下三层都会协同工作:

  1. 身份依据: 是哪个客户端签署了这次请求? 已验证签名会回答这个问题。
  2. 凭证: 是哪个账户负责? 你的 API key、token 或 session 会回答这个问题。
  3. 授权: 这个调用方可以这样做吗? 你的权限模型会回答这个问题。

Proof of Actor 强化第一层并使其可见。它不会签发身份或委托凭证，也不会替代你的授权。保持各层分离，才能让你在低风险 route 上更宽松地对待已验证 agent，同时在高影响 route 上保持审慎。

它适合放在哪里

Proof of Actor 位于你的 gateway、认证和 rate limiting 旁边。集成以服务器端 middleware 的形式运行，部署在 edge、你的 MCP server 中，或通过通用 HTTP 集成实现，并与每个创始团队一起进行面对面的交付。如果你的流量主要是 APIs 和工具，APIs 和 MCP Servers use case 展示了最重要的模式。

从观察模式开始

每次集成都从观察模式开始。系统会记录结果，而不会改变你的应用响应方式，因此你可以看到自动流量中有多少是已验证的、哪些运营方在签名，以及 Unknown 比例在哪些地方最高。只有当证据支持时，policy 才会在之后按 route 引入。How It Works 会完整演示整个流程。

让验证可靠的实用细节

签名检查的可靠性取决于其周边细节。若要在生产环境中依赖已验证的自动请求，以下实践很重要。

检查新鲜度

RFC 9421 定义了 created 和 expires signature 参数，已签名请求通常会携带这些参数。拒绝超出短时间窗口的签名，这样被截获的请求就无法在之后重放。

合理缓存密钥

如果每个请求都去获取运营方已发布的密钥，会增加延迟。应在合理时长内缓存这些密钥，并在签名因未知密钥标识符而失败时刷新，以避免密钥轮换造成误判失败。

签署请求的正确部分

只覆盖时间戳的签名几乎不能证明什么。要检查被签名的组件是否包含 method、path 和 host，这样签名才能绑定到你的应用实际收到的请求。

记录证据

为每个已验证请求保留 key identifier、已发布标识符和结果。当出现异常时，你的团队可以精确查看是谁在什么时间签署了什么。

Proof of Actor 在 Detect 步骤中处理这些检查，并将结果作为 policy 可读取的依据报告出来，因此你的应用代码可以保持简洁。

加入创始开发者计划

Proof of Actor 目前处于 private beta。入选的创始开发团队可在约定的使用限额内，获得最长 12 个月的免费访问，并由我们的工程师提供直接集成支持。

如果自动客户端会访问你的应用，而你希望对已验证的客户端区别对待，请 申请早期访问。告诉我们你的应用以及你看到的自动调用方，我们会向你展示 Proof of Actor 如何适配。

来源

面向开发者

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 集成指南

常见问题

什么是已验证的自动请求？

这是来自自动客户端的请求，其加密签名可通过与已知标识符发布的密钥进行验证，例如运营方的域名。它显示是哪一个客户端签署了该请求。

已验证的签名是否意味着该 agent 已获授权？

不。签名只是将请求与某个密钥及其已发布标识符关联起来。该客户端是否可以执行某项操作，是由你的应用单独做出的授权决定。

那些没有对请求签名的自动客户端怎么办？

Proof of Actor 仍然会对它们进行分类，在可用时使用已声明和已推断的证据，并在证据不足时报告为 Unknown。每个结果都会说明其依据。

user-agent 字符串可以验证客户端吗？

不可以。user-agent 字符串很容易伪造，因此它们只能算作声明，而不是验证。加密签名才是让请求可验证的依据。

我该如何开始？

申请早期访问。创始团队从观察模式开始，入选团队可在约定使用限额内获得最长 12 个月的免费使用。

了解谁在使用您的 app。

面向少数 founding developers 的私有 beta。

获取抢先访问查看定价

想先聊聊？ 联系创始人