Web Bot Auth：验证 Agent 请求身份，不等于批准它下单

商户希望区分有明确身份的购物 Agent 与匿名机器人。只匹配 User-Agent 文本并不可靠，其他客户端也能发送相同内容。Web Bot Auth 在 HTTP 层增加可验证的密码学信号，供网站结合自己的访问与交易规则判断。

即使签名有效，仍有一个问题没有回答：这个请求方在这里到底可以做什么？

资料边界： 本文于 2026 年 11 月 1 日核对官方接入文档与标准文本。相关 Web Bot Auth 架构和目录文件仍为 Internet-Draft，底层 HTTP 消息签名标准为 RFC 9421。我们没有注册机器人、修改防火墙或测试签名请求。

公钥目录把请求与验证材料连起来

架构草案 描述 Agent 为 HTTP 请求签名，再由源站或前置验证方检查的过程；Signature-Agent 帮助定位验签公钥。验证后赋予什么信任或访问权，仍由网站决定。

身份验证概念图，非实测部署。图中刻意把购买授权放在验签之外。

架构里还应把请求签名密钥与支付权限分开。识别爬虫或 Agent 服务的密钥，不必也是控制钱包的密钥；产品权限界面不应把两者混为一谈。

有签名，还要问签了什么

RFC 9421 允许对选定的 HTTP 组件生成签名。签名有效，不代表请求里所有重要内容都被覆盖。应用需要选择并检查与业务相关的签名范围。

商户可以据此提出具体审查问题：哪些签名材料把请求绑定到目标站点，什么机制保护交易敏感内容？不能因为机器人身份签名有效，就推断收银请求体里的金额也经过同样验证。

验证器最好返回足够的结构化证据，让应用继续判断，而不是用一个“可信机器人”标签代替所有权限决策。已识别的请求方可以被允许浏览商品目录，但购买时仍需客户授权。

Cloudflare 的接入规则有明确版本边界

Cloudflare 文档 描述其支持的算法、目录要求与请求头格式。目前文档采用 directory-03 的 Signature-Agent 结构化字符串形式，并说明不接受后续草案的字典形式。

因此，接入时应锁定实际验证方的配置版本。“实现了最新草案”不代表已有验证方就能接受。签名库、代理路径和接收端，应作为一个组合维护兼容性测试样例。

同一文档明确写到，Cloudflare 当前不会用已见 nonce 数据库检查 nonce 唯一性。因此，不能把填写 nonce 宣传成自动实现“一次性请求”。较短有效期可以减少暴露窗口，但涉及购买时，应用仍需自己的防重放与重复操作控制。

密钥轮换需要完整操作流程

目录草案 讨论了密钥有效期重叠和验证方缓存。服务应协调公钥发布、签名切换与旧钥退役，而不是新钥刚生成就删除旧钥。

建议的上线前检查包括：

• 使用过期密钥签名，检查是否按选定策略拒绝。
• 修改必须签名的组件，确认验签失败。
• 经过实际代理路径测试，而不是只测本地直连。
• 在验证方仍缓存旧目录时轮换密钥。
• 在签名有效期内重复购买请求，确认业务幂等阻止第二张订单。

这些是建议测试，不是 Cloudflare 实测结果。日志应能定位密钥标识、配置版本和失败阶段，同时避免暴露私钥或不必要的客户数据。

认证应帮助判断，而不是跳过判断

Web Bot Auth 能为站点增加可验证的请求身份信号，但并不要求站点放行所有已识别 Agent，也不能替代限流、账户权限或支付检查。

我们的建议是先定义较窄的权限，例如允许已识别 Agent 读取商品目录，再独立评估收银操作。可继续看 Web Bot Auth 目录条目 与相邻的 KYA/KYAPay 身份及支付声明。两者都不应被当作自动购买的全面通行证。