Web Bot Auth 是什么
Web Bot Auth 是一个 IETF 工作组 的名称，也是其关于自动化 Web 流量身份验证的 Internet-Draft 工作。其思路很直接: 爬虫、AI 助手和自主代理使用 HTTP Message Signatures (RFC 9421) 对自己的 HTTP 请求签名，并在其控制的标识符下发布用于验证这些签名的公钥。然后，网站可以确认某个请求确实来自它所标识的运营方，而不是依赖任何人都能复制的 user-agent 字符串。关于这对产品团队意味着什么，请参见 Web Bot Auth for product teams; 关于实现步骤，请参见 如何验证已签名的 AI 代理请求 指南。
截至 2026 年 11 月，该工作组的核心文档是 draft-ietf-webbotauth-httpsig-protocol，它定义了一个用于带内密钥发现的 Signature-Agent 头、一个基于 JSON Web Key Sets 的密钥目录格式，以及该目录的 well-known URI。 工作组文档页面 会将其与相关的个人草案一并列出。这些都是 Internet-Drafts，意味着它们仍在完善中。密钥如何发现、哪些请求组件必须签名、哪些头部携带运营方信息等细节，可能会在不同版本之间变化。实现者应跟踪当前草案，而不是任何快照版本。
为什么它重要
网站和 API 长期以来一直使用 user-agent 字符串和 IP 段来识别机器人。两者都有局限: user-agent 字符串很容易伪造（参见 user-agent spoofing），而 IP 段会变动，并且在云服务商之间共享。随着 AI 代理开始代表人们浏览网页、调用 API 并使用 MCP servers，应用需要一种更稳妥的方法来区分协作型自动化客户端和匿名客户端。
已签名请求提供了这种更稳妥的基础。经验证的签名可以让应用持续识别已知运营方，为其提供结构化路径，而不是人类界面，并准确衡量其活动。
它的工作原理概览
- 运营方生成一对密钥，并将公钥发布在与其身份关联的位置，通常是其域名下的
http-message-signatures-directorywell-known 路径。 - 每个请求都包含覆盖所选请求组件的
Signature-Input和Signature头，以及一个密钥标识符和一个指向密钥目录的Signature-Agent头。 - 接收站点获取或缓存运营方发布的密钥，重建签名基准并验证签名。
- 验证成功后，站点就知道该请求是由与该已发布标识符关联的密钥持有者生成的。
它确立了什么，又不确立什么
Web Bot Auth 签名会验证自动化客户端的身份。它不会回答以下问题:
- 运营方是否被允许执行它所请求的操作（agent authorization），
- 某个人是否指示或批准了该操作（delegated authority），
- 该操作是否安全，或者返回的内容是否会被适当地使用。
这些仍然是接收应用自身的身份验证、授权和策略决策。我们的博客文章 已签名的 AI 代理请求能证明什么，不能证明什么 对这条边界做了进一步探讨。
常见误解
- "每个机器人很快都会签名。" 采用会按客户端逐步增长。应用在很长一段时间内都会看到已签名、已声明和匿名流量的混合，因此需要清晰的方式来分别处理它们。
- "签名就意味着机器人是好的。" 它只是让机器人变得已知。已知是策略的起点，不是策略本身。
- "草案已经定稿。" 这仍是一个不断演进的 Internet-Draft。应基于当前文本开发，并预期后续修订。
Proof of Actor 如何关联
Proof of Actor 将经验证的签名视为 basis 为 Verified 的 evidence，并限定在其所证明的密钥和标识符范围内。它会将其与已声明名称和推断信号分开处理，并且绝不会把身份变成权限。Proof of Actor 的设计目标是在这些标准成熟时验证已签名请求; 由你在 Route 中定义的策略决定一个经验证的代理可以做什么。
了解这如何融入 APIs 和 MCP servers，或者 申请提前访问。
来源
- IETF Web Bot Auth 工作组: 章程、主席和状态
- Web Bot Auth 工作组文档: 当前工作组文档和相关草案
- draft-ietf-webbotauth-httpsig-protocol:
Signature-Agent、JWKS 密钥目录及其 well-known URI（截至 2026 年 11 月仍在进行中） - RFC 9421: HTTP Message Signatures: Web Bot Auth 所基于的签名标准