说明

面向产品团队的 Web Bot Auth: 签名的 agent 请求对你的路线图意味着什么

AI agent 和爬虫越来越需要一种方式来证明自己是谁，而不是依赖任何人都能复制的 User-Agent 字符串。IETF 的 Web Bot Auth 工作是标准化这一点的领先努力。下面用通俗方式为产品经理和工程负责人解释: 它如何工作，它能证明什么，截至 2026 年 11 月的状态，以及如何为它做规划。

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

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

多年来，自动化客户端向网站说明自己是谁，唯一的方式往往就是 User-Agent 头里的一个名称，以及少数大型运营方发布的 IP 地址列表或反向 DNS 检查。名称很容易被复制。网络列表只能覆盖维护这些列表的运营方。随着 AI agent 开始在整个网络上代表真实用户执行操作，这个缺口已经成为产品问题，而不只是安全问题。

Web Bot Auth 是填补这一缺口的领先工作。它让自动化客户端可以用自己控制并发布的密钥为请求签名，这样站点就能校验签名，而不是只相信一个名称。这个说明文档面向需要理解它是什么、会改变什么、不会改变什么的产品经理和工程负责人，无需逐字阅读全部规范。

简要版本

它是什么: 一个 IETF 工作组 webbotauth，以及它正在标准化的用于对自动化 HTTP 客户端进行身份验证的方法。
它如何工作: 客户端使用 HTTP Message Signatures (RFC 9421) 对每个请求的部分内容签名，并指向自己的公钥目录。站点获取密钥并验证签名。
它能证明什么: 哪把密钥对请求进行了签名，以及签名覆盖的部分在传输过程中没有被更改。
它不能证明什么: 该 agent 是否被授权执行其请求的操作，是否代表某个特定用户，或者它是否会表现良好。
截至 2026 年 11 月的状态: RFC 9421 已作为 Proposed Standard 发布。Web Bot Auth 协议文档仍是工作组 Internet-Draft，尚不是 RFC。
你应该做什么: 计划把有效签名视为强证据，同时继续处理未签名流量，并把授权决策保留在你自己的代码中。

IETF 的 Web Bot Auth 工作是什么

IETF 设立了 Web Bot Auth 工作组，用于标准化对自动化客户端进行密码学身份验证的方法，以及向网站提供更多关于其背后运营方的信息。该章程主要面向服务人类用户的网站，并列出了一组广泛纳入范围的客户端: 爬虫、网页归档器、链接检查器、AI 训练爬虫，以及代表终端用户行动的 AI agent。

该章程中有两个排除项值得产品团队注意。终端用户身份验证不在范围内，因此这不是让某人登录的方式。跟踪 bot 声誉也不在范围内，因此该标准告诉你是谁签了请求，而不是该运营方是否值得信任。

章程列出了三类交付物:

关于为面向人类的网站认证自动化客户端的标准轨道文档。
关于使用现有标识符，例如域名或 URL，传达更多关于请求 bot 的信息的标准轨道文档。
关于密钥管理、生命周期和部署等运维主题的最佳当前实践或信息性文档。

截至 2026 年 11 月，该工作组有一份已采纳的工作组文档: draft-ietf-webbotauth-httpsig-protocol，标题为 "HTTP Message Signatures for automated traffic"，版本 01，日期为 2026 年 10 月 29 日。它是 Internet-Draft，这意味着它仍在推进中，未来可能继续变化。它不是 RFC。

该工作组还讨论了若干个人草案，包括关于注册表和 agent card 格式的提案、匿名 bot 身份验证、用于发布自动化客户端 IP 段的 JSON 格式，以及用于签名 agent 元数据的头部。个人草案只是提案; 截至该日期，其中没有任何一项被工作组采纳。

章程在 2026 年设定了将规范提交 IESG 审批的里程碑。截至 2026 年 11 月，该协议文档仍是工作组草案。你可以在 IETF datatracker 上该工作组的页面和协议草案查看当前状态。

HTTP Message Signatures 如何工作

Web Bot Auth 建立在 RFC 9421, HTTP Message Signatures 之上，该标准于 2024 年 2 月作为 Proposed Standard 发布。RFC 9421 是一种通用机制: 它定义了如何对 HTTP 消息的选定部分进行签名，以及如何在头部中携带签名。Web Bot Auth 则把它用于自动化客户端。

用通俗的话说，带签名的 agent 请求大致这样工作:

运营方创建一对密钥。 它保留私钥秘密，并发布公钥。
客户端选择要签名的内容。 它选取请求的组成部分，例如目标主机或 URI 以及创建时间。当前草案要求覆盖 authority 或目标 URI，因此针对一个站点的签名不能简单地重放到另一个站点。
客户端签名并发送。 请求携带一个 Signature-Input 头，说明签名了什么以及使用了哪把密钥，并携带一个 Signature 头，包含签名值。草案使用 web-bot-auth 标记，并要求每个签名都有创建时间和到期时间。
站点进行验证。 它找到公钥，根据收到的请求重建被签名的组成部分，并检查签名。如果检查通过，说明该请求确实由那把密钥的持有者签名，而且被覆盖的部分没有被更改。

该草案还允许站点请求签名。源站可以发送一个 Accept-Signature 头，通常带有拒绝响应，表示它希望收到带签名的请求。

密钥目录的思路

如果站点找不到正确的公钥，签名就没有意义。Web Bot Auth 用 密钥目录 来解决这个问题。

在当前工作组草案中，客户端会添加一个包含 HTTPS URL 的 Signature-Agent 头。该 URL 提供一个运营方公钥目录，格式为 JSON Web Key Set。站点获取该目录，选择与签名中密钥标识符匹配的密钥，然后进行验证。草案还定义了一个 well-known 路径 /.well-known/http-message-signatures-directory，运营方可以在这里提供其目录。

对产品团队来说，这个想法的关键在于 URL 成为身份。agent 运营方通过发布密钥的位置来被识别，这把签名绑定到其控制的域名上。密钥轮换的方式是先发布新密钥和旧密钥并存，然后移除旧密钥。

验证方需要谨慎处理目录: 按照正常 HTTP 规则缓存，设置大小限制和超时，并避免从私有网络地址获取。這些都是标准工程问题，也正因为如此，许多团队更倾向于使用一个专门为他们执行验证的组件。

有效签名能证明什么，不能证明什么

对于编写产品策略的人来说，这是最重要的一节。

有效签名可以证明:

请求由某个特定私钥的持有者签名。
该密钥发布在运营方控制的目录 URL 上。
请求中被签名的部分在传输过程中没有被更改，并且签名仍在其有效期内。

有效签名不能证明:

该 agent 是否被授权执行该操作。可识别不等于可许可。参见 agent authorization。
该 agent 是否代表某个特定的人，或是否在该人授予的权限范围内行事。参见 delegated authority。
运营方是否值得信任，或者该 agent 是否会表现良好。该工作组明确不包含声誉问题。
关于未签名请求的任何信息。未签名流量仍需要单独处理。

把有效签名视为关于 谁发送了请求 的强证据，然后让你自己的访问控制决定 该发送方可以做什么。

产品团队应如何应对

你不必等到 RFC 发布后再规划。带签名的 agent 流量现在就可以准备，尽管草案中的某些细节未来可能会变化。

1. 先测量，再决定

了解你的流量中有多少是自动化流量，agent 使用了哪些 route，其中有多少是带签名的。先进入观测模式，这样测量不会对用户造成任何改变。

2. 将证据与策略分开

把证据所说明的内容, verified、declared、inferred 或 unknown，与你决定采取的措施分开记录。这样可以让策略更清晰，也能让你在不重新埋点的情况下收紧或放宽策略。证据基础条目解释了这四个级别。

3. 为 verified 的 agent 提供更好的路径

在合适的地方，为 verified agent 提供结构化内容或更适合 agent 的流程，而不是为人类构建的页面。为 AI agent 提供结构化内容指南介绍了这些模式。

4. 把授权保留在你的代码中

使用签名来知道是谁在请求。使用你现有的权限、范围和确认机制来决定它们可以做什么。高影响操作即使签名者是谁已知，仍可能需要人工确认。参见在不阻挡 agent 的情况下保护敏感操作。

5. 为未签名和 Unknown 流量做好准备

不同 agent 和工具对签名的支持各不相同，因此预计一段时间内会同时出现已签名和未签名请求。按 route 决定 declared、inferred 和 Unknown 流量会如何处理，而不是选择一个全站统一规则。处理 Unknown 流量指南对此有详细说明。

Proof of Actor 如何使用 Web Bot Auth

Proof of Actor 会告诉你的应用在每次交互中是谁或什么在执行操作，Human、Human + AI、Agent 或 Unknown，并标明证据基础。Web Bot Auth 签名是它最强的证据来源之一。

当 agent 使用 HTTP Message Signatures 对请求签名时，Proof of Actor 会根据运营方发布的密钥检查签名。如果检查通过，结果会带有 verified basis，以及你的团队可以审查的证据。如果客户端只是在头部中声明自己是谁，结果就是 declared。如果结论基于行为或上下文信号，则标记为 inferred。如果证据不足，结果就是 Unknown。

你的应用决定如何处理这些上下文。策略按 route、按 actor class、按 basis 编写，结果可以是 allow、adapt、challenge、review 和 rate-limit。默认不会强制执行任何内容: 你先用真实流量预览策略，然后再按 route 在你自己的代码中执行。

Founding 团队可以通过 Node.js middleware、Next.js、边缘集成、经批准页面上的浏览器采集器、通用 HTTP API，或 MCP server 集成来收集证据。参见集成，以及验证带签名的 agent 请求指南了解实际步骤。

Proof of Actor 遵循与该标准相同的限制: 已验证签名只会告诉你是哪把密钥签了请求，而不会告诉你该 agent 是否被授权。授权仍由你决定。证据与限制页面会准确说明每个结果可以支持什么，不能支持什么。

开始使用

Proof of Actor 目前处于私有 beta。入选的 Founding Developer 团队可在约定使用限制内获得最长 12 个月的免费访问权限，不会自动计费。申请早期访问，并告诉我们你预计哪些 route 会使用带签名的 agent，以及你希望如何处理它们。

面向开发者

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

常见问题

什么是 Web Bot Auth?

Web Bot Auth 是 IETF 工作组 webbotauth 的名称，也是它正在标准化的方法: 自动化客户端用 HTTP Message Signatures (RFC 9421) 对 HTTP 请求签名，并发布其公钥，这样网站就能验证是哪一方发送了请求。

Web Bot Auth 是一个已经完成的标准吗?

还不是。截至 2026 年 11 月，主要协议文档 draft-ietf-webbotauth-httpsig-protocol 仍是第 01 版的工作组 Internet-Draft。RFC 9421 是它所基于的签名格式，已经作为 Proposed Standard 发布。

有效的 Web Bot Auth 签名是否意味着 agent 被允许执行操作?

不意味着。它只能证明是哪把密钥对请求进行了签名，以及签名覆盖的部分没有被篡改。该 agent 是否可以读取数据、提交表单，或代表某个特定用户执行操作，仍然是你的应用要做的授权决策。

产品团队需要自己实现 Web Bot Auth 吗?

站点负责验证签名，不需要自己去签名，除非它们也运行自动化客户端。验证包括获取密钥目录、安全缓存它们并检查签名，这些工作可以由 Proof of Actor 这样的工具替你完成。

对于没有对请求签名的 agent，我们应该怎么做?

根据可用证据来处理: declared、inferred 或 Unknown。预计一段时间内会同时存在已签名和未签名流量，因此应按 route 设置回退方案，而不是使用一个全站统一规则。

Proof of Actor 如何使用 Web Bot Auth?

它会根据已发布的密钥检查 HTTP Message Signatures，并在检查通过时将结果标记为 verified basis。然后你的策略可以把 verified 的 agent 与 declared 或 Unknown 流量区别对待。

了解谁在使用您的 app。

面向少数 founding developers 的私有 beta。

获取抢先访问查看定价

想先聊聊？联系创始人