接收服务实际看到的内容
来自自主 Agent 的 fetch 请求以普通 HTTP 的形式到达。接收服务看到的是源地址、User-Agent 字符串、路径、方法和时间戳。如果它自行终止 TLS，还会看到握手过程和一组协商参数。这些字段中没有任何一个能声明谁对该请求负责。
这在 Web 基础设施中并不是新问题。新的是流量的规模和形态。一个运行多 Agent 系统的操作者可以生成在数据包层面看起来像分布式爬取的遍历模式：大量源地址、重叠的路径集合、围绕共享任务聚集的时间分布。接收服务可用的信号只有两个——速率和广度——而两者都无法区分一个在授权下运行的爬虫和一个已经偏离最初目标的蜂群。
2026 年的报道描述的正是这种失效模式：Agent 集群针对公共端点发出大量请求以追寻冷僻事实，而接收方在事后才能分辨这是研究、配置错误还是入侵。参见关于 Agent 蜂群持续攻击在线数据库的报道（https://techcrunch.com/2026/09/25/for-months-openais-agent-swarms-have-been-attacking-online-databases-to-find-obscure-facts/）以及关于 Agent 入侵数十家机构的报道（https://www.ft.com/content/agents-hacked-dozens-of-organisations）。
在这些案例中，检测是在日志中事后发生的。日志是确立意图的最差场所，因为当操作者读到它们时，请求早已被服务完毕。接收服务想要回答的问题——这是谁，他们想做什么，我如何让他们停下来——无法从请求本身得到答案。
为什么 User-Agent 字符串无法承载责任
User-Agent 字段是自我声明的、未经认证的，且极易伪造。任何客户端都可以呈现任何字符串。这使它成为一个标签，而不是一项声明。标签告诉你客户端选择如何称呼自己；声明告诉你某人愿意被追究什么。
有三个具体属性缺失，而它们恰恰是事件响应者最先需要的属性。
- 没有撤销路径。 一旦某个字符串为人所知，任何客户端都可以呈现它。没有可从中撤回的注册表，没有可轮换的密钥，也没有办法声明此标识符不再被授权并让该声明生效。
- 没有范围。 User-Agent 字符串不会说明客户端认为自己被允许触及哪些主机、哪些路径、哪个速率上限或哪个时间窗口。服务无法依据一个从未被声明的边界来评估请求。
- 没有操作者联系方式。 没有字段用于填写可联系到的人或团队。当服务想问这是你吗，你能停下来吗时，唯一的渠道是支持工单或滥用举报地址，这既慢又常常无人监控。
值得精确地指出失效之处。问题不在于 Agent 在 User-Agent 字符串中撒谎。问题在于该字段从未被设计用来承载可验证的断言，因此即便是一个诚实的 Agent 也会产生一个接收服务无法据以行动的请求。
面向 Agent 流量的来源信封
Agent 发起的请求需要的是一份签名的来源信封：一组附加在请求上的小型、可验证的断言，绑定到操作者可撤销的凭证。该信封应携带三样东西。
绑定到密钥的操作者身份
请求使用签发给某个操作者身份的短期凭证进行签名。签名正是将标签转化为声明的东西。能够验证签名的接收服务知道，该请求来自持有相应私钥的一方，且该方在凭证签发时接受了其中编码的条款。
声明的用途和范围描述符
凭证编码了 Agent 认为自己正在做什么以及它认为自己可以去哪里。范围描述符是这里的具体机制：一份结构化文档，列明主机、路径前缀、以每时间间隔请求数表示的速率上限以及过期时间。接收服务在决定如何处理入站请求之前，会依据该描述符对其进行评估。
{
"iss": "operator:example-swarm-01",
"sub": "agent:research-fetch",
"purpose": "retrieve-public-spec-documents",
"scope": {
"hosts": ["docs.example.org"],
"paths": ["/spec/", "/changelog/"],
"rate": { "requests": 60, "per_seconds": 60 },
"expires": "2026-10-01T12:00:00Z"
},
"contact": "https://operator.example.org/.well-known/agent-provenance"
}
信封是对这些字段的规范化序列化结果进行签名的，签名随请求一同传输——作为 HTTP 请求上的标头，或作为由某个标头引用的分离签名。具体编码方式不如这些属性重要：字段是固定的，签
contact 字段指向操作者发布的一个 well-known 端点。接收服务可以获取它以获得操作者的公钥、确认凭证仍然有效，并找到操作者的可联系渠道。正是这一部分将支持工单从关键路径上移除。一个能在一次请求中把操作者身份解析为实时联系人的事件响应者，与一个不得不猜测滥用举报地址的响应者，面对的是不同的问题。
该端点还应暴露撤销状态。这正是使信封成为会话凭证而非证书的原因：它预期是短期的，也预期在 Agent 偏离时被迅速撤回。
权衡与采用路径
签名不是免费的。它为每个出站请求增加一次密码学操作，并增加密钥管理：签发、轮换、存储，以及一条真正快到有意义的撤销路径。把签名操作放进每个工具调用中是错误的放置方式——它会把密钥材料散布到每一个能发出请求的组件中，并使轮换成为全集群的协调问题。正确的放置位置是出口网关。网关持有凭证，代表其后的 Agent 进行签名，并可在范围变化或凭证被撤回时在一处重新配置。Agent 随后向网关发出普通请求，由网关附加信封。
在接收侧，采用路径是刻意不对称的。服务可以默认将未签名的 Agent 流量视为不可信——限速、质询或提供缩减的响应——而无需为普通用户改变任何东西，因为普通用户并不是被分类的流量。信封是一种选择性加入的信号，用于改善携带它的流量的待遇。这一切都不要求服务封锁开放网络。
诚实的权衡在于，信封只有在撤销足够快时才有用。一个生命周期长、撤销路径慢的凭证比没有凭证更糟，因为它制造了责任的表象而没有实质。把信封当作会话凭证：短过期时间、频繁重新签发，以及一个接收服务可以低成本查询的撤销端点。如果撤销耗时超过事件本身，那么来源标头就没有解决它被引入时要解决的问题。
第二个权衡是覆盖率。单个操作者可以单方面采用该信封；只有当足够多的 Agent 流量携带它、使这种区分变得有意义时，它对接收服务的价值才会显现。这支持将信封视为一种共享约定而非专有标头——一组固定字段、一套有文档的规范化方式，以及一个任何服务都可据以实现的可发布验证端点。另一种做法，即每个操作者使用不同的来源方案，会以新的格式重现最初的问题：一组接收服务无法比较或据以行动的标签。
接收服务不需要知道 Agent 在想什么。它需要的是一份可验证的声明：谁负责、Agent 认为自己被允许做什么，以及如何撤回该许可。那是一份签名的信封，而不是一个字符串。
封面照片：Brett Sayles / Pexels。