令牌证明的是智能体，不是那件差事

一眼概览

Meta 与 Sierra 在 10 月 6 日宣布了这套协议，三天后发布草案，而那个昵称——Poppy——已经比正式名字传得更远。各家报道给出的设计伙伴数量与名单并不一致；真正值得读的是草案本身。

连接层确实做得好，而那正是人们会跳过的部分

值得把草案做对了什么说准确，因为下面的批评并不是说作者们草率。会话令牌用 DPoP 的持有证明绑定到智能体的密钥上，所以一枚从日志里或被攻陷的代理上捞走的令牌，没有那把签出证明的私钥就是惰性的。Bearer 令牌——那种被偷走一串字符就能完美重放的——只在恰好一个面上被接受，即 MCP API，而且仅当请求的 resource 是该 API 自己的 URL 时。这比多数生产环境里的 OAuth 部署所做到的受众限制都更紧。

Issuer 比对是那个安静但重要的一条。智能体必须确认公司 OAuth 授权服务器元数据里公布的 issuer 与 poppy.json 里写明的 issuer 一致，并且该域名出现在那份文档里。省掉它，任何域名都能冒认另一家公司的 issuer 并收走为其签发的令牌——这是教科书式的被混淆的代理人，智能体是那个代理人，而你客户的账户是那个资源。它也恰恰是那种会在赶工集成时被丢掉的检查，因为你省掉它的时候什么也不会报错。

所以握手不是弱点。弱点在于：一套围绕「是谁在调用」建得如此仔细的协议，把「它被派去做什么」几乎整个留给了实现者。

两个 scope 就是全部的授权模型

poppy:read 覆盖查看账户信息——订单、预订。poppy:write 覆盖做出变更，草案给出的例子是换一件商品。两者彼此独立，所以同时需要二者的客户端就把二者都申请下来。对一块同意界面来说这是干净的设计，而作为一项权限它是无界的：在 poppy:write 之内，改一个收货地址与取消一份订阅是同一笔授权，商户 API 暴露为变更操作的任何别的东西也是。

草案确实留了一个逃生阀——公司可以声明自己的 scope，而已公布的示例文档里就包含一个 addresses scope，描述为管理已保存的收货地址。这是对的压力阀，却是让细节落脚的错地方。一套协议之所以存在，要标准化的那一件事恰恰是一笔授权意味着什么，好让一个在某家商户那里同意过一次的用户，学到某种能迁移到下一家的东西。把这件事推进 custom_scopes，用户就什么也学不到：对话框在每个站点上都写着「管理你的账户」，而在每个站点覆盖的爆炸半径都不一样。

对比一下智能体对智能体那一脉是怎么处理同一个问题的。能力描述是一份关于「某个操作做什么」的机器可读陈述，这正是能力发现与智能体名片把复杂度花在动词而不是调用方身上的原因。Poppy 继承的是 OAuth 的形状，而 OAuth 的 scope 一向是一个人类可读的标签、含义由各家提供方自定——当一个人为一个照片分享应用点一次同意时，这还能忍；当被授权方是一个会把这笔授权行使一千次、而且不会再被问一次的循环时，就不太行了。

三条进来的路，而流量会走最弱的那条

草案描述了三个接入面，而它们的性质并不对等。账户 API 携带那枚带 DPoP 的、与密钥绑定的令牌。MCP 端点接受一枚受众被钉在自己 URL 上的 bearer 令牌。浏览器接入在种类上就不一样：智能体用一份签名断言换取会话 cookie，从那一刻起，它持有的就是一个已登录浏览器所持有的东西。密钥在门口干完了活，然后退出了画面。

预测一下流量会去哪里。对多数商户来说，发布一个合规的账户 API 是一个路线图条目；而把现有的 Web 会话暴露给智能体，只是在本来就存在的基础设施上套一层薄薄的转接。浏览器那条路会承载不成比例的流量，理由与屏幕抓取承载了十年流量的理由一样——它是在你已经上线的那套栈上就能跑通的那一条。于是协议里最弱的那枚凭据在实践中成了最常见的那枚，并且把智能体放回了浏览器智能体一直所处的位置：对会话能触达的一切拥有环境权限，而模型与那次变更之间没有任何逐动作的关卡。

这些都不是反对上线浏览器面的论点。这是一个论点，反对把「符合 Poppy」读成一句关于安全姿态的陈述。三个面、三种凭据强度、一套共享的授权词汇，意味着那枚合规徽章几乎不能告诉你某一次具体集成用的是哪一个。

如果你是那家发布文档的公司，该做什么

两-scope 模型有一个有用的后果：你自己的 API 成了那块策略面。协议拒绝去区分的一切，你都得在令牌的另一侧把它们区分开来。

• 在发布之前，把 poppy:write 能触达的范围用文字列全。一枚智能体持有的令牌能执行的每一项变更，现在都在同一个桶里。如果取消订阅、改变收款目标与兑付一笔额度都在那个桶里，协议不会拦住其中任何一项，而你的同意界面暗示的只是其中一项。
• 为不可逆的操作声明自定义 scope，而不是为顺手的那些。示例文档切出去的是已保存地址。这个机制更好的用法，是那张短名单：你希望为之单独设立、可单独吊销、可单独记录的那些动作——退款、付款、删除，以及任何牵涉对手方的事。
• 把加强确认留在你这一侧的边界内。草案把更细的权限推后了，这意味着目前唯一能给高价值动作设关卡的地方就是你自己的 API。请把一次超过阈值的、源自智能体的变更，当作智能体的受限凭据对待任何特权调用那样来对待：一次单独的授权，而不是会话上的一个标志位。
• 在每一次写操作上记录客户端标识符，并让它可被查询。协议交给你一样真正新的东西——一个稳定的、经密码学证明的调用方智能体身份。那是决策凭据的连接键，是「吊销一个智能体而不吊销一整类」的依据，也是事故之后所有人第一句要问的那个问题的答案。
• 把你自己的速率限制与错误响应体当作一套智能体接口。对一个自动化调用方而言，429 是一次暂停而不是一个信号，而你的错误文本现在是一段提示词。无论请求由哪套协议送来，工程都是同一套——见服务智能体流量。

还没有的那些东西，以及它对你的排期意味着什么

草案 0.1 明说：在稳定版之前它的任何部分都可能变动，包括以不向后兼容的方式变动——而文档以 Apache 2.0 发布，这是关于意图的好信号，关于稳定性则根本不是信号。本周就在对着它做实现的人报告了三处具体的缺失：发现文档没有 JSON Schema、没有官方一致性测试套件、也没有已发布的参考实现，而设计工作坊与参考实现预计在接下来几周内到来。

支付、推送通知与更细粒度的权限被明确排除在覆盖范围之外。宣布前后被报道的伙伴名单里包含支付网络，这一点值得松松地拿着：一个设计伙伴不等于一项已被规定的功能，而这两者在报道里混得很快。诚实的现状是：一份有相当分量背书的草案，而它三个最有后果的面都被推后了。

实操上的读法：发布一份 poppy.json 和一个账户 API 既便宜又可逆，现在就做能给你占到位置。而把你产品需要的授权语义写进一套尚未规定它们的协议里，才是那块将来必须重做的部分，所以请把那套逻辑放进你自己的授权层，让一次规范修订无法把它作废。这是关于协议修订的一贯建议，而一份自陈有权打破兼容的 0.1，正是它当初为之而写的情形。

延伸阅读

本站相关：

• 智能体身份与权限——证明「是谁在调用」与界定「它可以做什么」之间的区别。
• 能力发现——要让一个操作机器可读、而不只是有个名字，需要付出什么。
• MCP 认证与 OAuth 2.1——Poppy 的 MCP 面所依靠的那套 resource 指示与受众绑定规则。
• 环境权限——为什么一枚会话 cookie 与一枚受限令牌是两类不同的凭据。
• 凭据有效期——一笔长期有效、授予自动化调用方的授权，在攻击者眼里究竟值多少。
• 委派访问与同意记录——当用户说他从未授权过那件事时，你需要的那份记录。

来源：

• Personal Agent Protocol 规范草案 0.1（2026 年 10 月 9 日发布；文档以 Apache 2.0 授权），以及 Sierra 的同期公告
• 关于 Meta 与 Sierra 10 月 6 日公告与 10 月 9 日草案的同期报道，各家在设计伙伴名单上并不一致
• 正在对接草案 0.1 的项目给出的独立实现说明，其中报告了缺失的 JSON Schema、一致性套件与参考实现