跳转到主要内容
术语表

HTTP Message Signatures (RFC 9421)

Toshendra Sharma

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

一项用于对 HTTP 消息的选定部分进行签名的 IETF 标准 (RFC 9421),使接收方能够检查某个请求是否由特定密钥的持有者生成。

什么是 HTTP Message Signatures

HTTP Message Signatures 定义于 RFC 9421,这是一个用于对 HTTP 请求或响应的部分内容创建和验证数字签名的 IETF 标准。客户端选择要覆盖的组件,例如 method、target URI、authority 和选定的 headers,以它们构建规范化的 signature base,并使用 private key 对其签名。结果会通过两个 headers 传输: Signature-Input (Section 4.1),其中列出被覆盖的组件以及 created、expires、keyid 和 alg 等参数,以及 Signature (Section 4.2),其中承载签名值本身。两者都使用 RFC 9651 的 Structured Field Values 语法。

接收方会根据其实际收到的请求重建相同的 signature base (Section 2.5), 查找由 keyid 引用的 public key,并检查签名。如果签名覆盖的任何内容在传输过程中发生变化,验证就会失败。

它们为何对 apps、APIs 和 MCP servers 重要

大多数自动化流量会通过 user-agent 字符串或自定义的客户端名称来标识自己。这两者都很容易伪造。消息签名不同: 它将请求绑定到某个密钥,而只有 private key 的持有者才能生成有效签名。对于接收来自爬虫、助手和自主 agent 的应用来说,这就把“这个客户端说它是 X”变成了“这个请求是由 X 公布的密钥签名的”。

这种区别是将协作型自动化客户端视为已知参与方,而不是匿名流量的基础。它让 API 能够把已签名的爬虫路由到结构化 endpoint,对已知操作者应用不同的 rate limit,或者为 MCP server 提供更多关于是谁在调用工具的上下文。

验证在实践中如何工作

  1. 解析 Signature-Input 和 Signature,并确认预期组件都被覆盖。覆盖内容毫无实际意义的签名,证明价值很有限。
  2. 检查 created 和 expires 参数,在你的容忍范围内拒绝过期或重放的请求(参见关于签名重放的 Section 7.2.2)。
  3. 将 keyid 解析为你信任来源中的 public key,例如操作者在已知位置发布的密钥目录。IETF 的 Web Bot Auth protocol draft 为自动化客户端定义了这样的目录。
  4. 按规范精确重建 signature base,并使用声明的算法进行验证。
  5. 记录哪些内容已被验证,以及验证发生在什么上下文中,以便后续决策引用。

在生产环境中,应该使用维护中的 RFC 9421 实现,而不是手工编写解析逻辑: 规范化细节很容易出错。如何验证已签名的 AI agent 请求 这份指南用代码逐步说明了每一步。

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

有效签名能证明该请求是由某个密钥签名的,并且如果该密钥是在某个域名下发布的,那么该请求与该域名的操作者相关联。它不能证明:

  • 操作者是诚实的,或该动作是安全的,
  • 某个人指示或批准了该请求(参见 delegated authority),
  • 客户端被允许执行它所请求的操作(参见 agent authorization)。

身份依据和权限是两个不同的问题。应用自身的认证和授权仍然决定客户端可以做什么。我们的博客文章 已签名的 AI agent 请求能证明什么,不能证明什么 对此有更深入的说明。

常见误解

  • “签名就意味着可信。” 签名意味着可归因。是否信任,是你对被归因一方所作出的策略决定。
  • “签名可以取代 API keys。” 它们回答的是不同的问题。API key 说明是谁在调用;签名说明是谁生成了请求。许多部署同时使用两者都会受益。
  • “未签名流量就是恶意流量。” 如今大多数自动化流量都没有签名。缺少签名只会减少可建立的事实,仅此而已。这也是为什么 Unknown 是一个一等结果。

Proof of Actor 如何处理签名

在 Proof of Actor 中,若某个签名能对已发布的密钥验证通过,则会以 verified 作为 basis 记录,并且范围严格限定为检查实际建立的内容: 该密钥以及它所属的标识。生成的 class(通常是 Agent)绝不意味着授权。结果会流入 Understand 用于分析,并进入 Route,由你的自有策略决定已签名客户端是获得结构化路径、不同限制,还是完全不变。像 Web Bot Auth 这样的已签名 agent 标准仍在演进中,而 Proof of Actor 的设计目标就是在这些标准成熟时验证已签名请求。

进一步阅读 这些 evidence 能建立什么,或 申请早期访问。

来源

在你自己的 app 中查看 actor intelligence。

想先聊聊? 联系创始人