摘要

  • IETF 已宣布 OAuth 工作组将在 2026 年 9 月 28 日召开线上临时会议，公开议程只有“Anthropic & OpenAI Agentic Use Cases”。这能证明一次会议及其主题，不能证明两家公司支持某份草案，也不能证明工作组已经采纳方案。
  • OAuth 已能表达细粒度授权，并把令牌约束到持钥客户端。剩余危险发生在模型生成具体调用以后：同一份未受信任的参数不能既定义候选行为，又替自己生成授权。系统应以外部于候选行为的依据作决定，把决定绑定到最终参数，并在第一个能够造成现实后果的入口核验、消费，再分别记录执行与结果。

想象一个付款代理。它持有发给正确客户端的令牌，DPoP 证明它拥有正确私钥，scope 和 resource 也都指向正确的付款服务。模型却从一封被污染的邮件中抽取了攻击者的收款账户。认证链条没有断，错误仍然可以发生：被授权的是“可以使用付款工具”，未必是“可以向这个账户支付这笔金额”。

IETF 公告给这个边界提供了新的标准化讨论窗口。会议定于 9 月 28 日 17:00–18:00 UTC。议程中的公司名不等于公司提案、背书或部署承诺；公告更没有把邮件列表里的任何文本变成工作组共识。

OAuth 章程把 OAuth 描述为一种委托协议：用户无需交出长期凭据，甚至无需暴露身份，就能让第三方应用有限访问资源。代理系统并非面对一片空白。RFC 9396 的 Rich Authorization Requests 允许在 authorization_details 中放入结构化的细粒度条件。标准里的付款示例包含金额和收款人；如果这些值事先已知并由用户批准，资源服务器完全可以拒绝不一致的实际请求。

因此，不能把问题偷换成“OAuth 只能做粗粒度授权”。真正的问题是谁让动态值获得权威。9 月 1 日的 OAuth/WIMSE 发帖问的是：模型刚输出的工具名和参数，能否与一次具体授权绑定，而不是只凭一类调用的权限继续执行。

随后围绕 RAR 的讨论把分界说得更清楚。若商户、123.50 欧元和 IBAN 已经确定，RAR 正是在做它应做的事。若具体值只在模型运行后才出现，把它们原样复制进更精细的授权对象，并不会自动产生独立的授权判断。同一个不可信输出不能既提出行为，又成为批准该行为的理由。

独立来源不一定是每次都请人点击。它可以是用户此前确认的预算与对象范围、版本化企业政策、已验证订单、另一个受控系统签发的状态，或越界时的新批准。关键是候选行为不能凭格式正确给自己铸造权限。

Chen 等人的用例草案用周一提出野餐任务、周二出现订场授权请求的例子解释“上下文坍缩”：传统同意页只显示 parks.book 和 calendar.write，却丢掉最初目的、地点选择和价格。草案同时明确，OAuth 不负责理解自然语言或编排任务；它关注的是先前约束如何跟随后来的具体执行。

Liu 等人的操作授权草案提出另一种拆分：先把操作方案结构化为不包含原始自然语言的 JWT，再由确认后的特定操作形成授权令牌。这样做至少承认，用户原话是证据，不能未经负责的结构化与确认就直接成为机器执行合同。

Yossif 的 mandate 问题陈述把授权时刻称为 T0，把代理执行时刻称为 T1。人类在 T1 有意缺席，一次授权可能支配成千上万个动作。要求每次回问会消灭自动化；完全不把 T0 约束带到 T1，又会让授权变空。文件要求第三方可确定地判断 T1 行为是否仍在 T0 边界内，但明确不规定协议方案。

参数绑定需要规范字节表示。JSON 键顺序、数字形式、默认值、URL 正规化或浏览器页面中的实时字段都可能改变摘要。系统要版本化 canonicalization 规则，把工具身份、目的地、金额、对象标识、后果等级和一切会改变效果的字段纳入 digest。

然而 digest 只证明“现在的字节与先前看到的一样”。恶意账户被忠实哈希后仍是恶意账户。加密可以封存一次决定，不能凭空补上缺失的委托人。

Das 的工具绑定草案给出一个具体但尚未被 IETF 采纳的主机流程：把模型输出视为不生效的 candidate act，规范化参数、计算摘要、验证、提交证据、签发限定权限，在 dispatch sink 核验并消费权限，最后才 invoke。该文件是个人提交的 Informational Internet-Draft，并含知识产权说明；它的规范词语不能当成现行义务。它最有价值的判断是位置：tool_use 不是 invoke()。

所谓 sink，是第一个能让世界改变的地方。HTTP 资源服务器可能直接划款；本地函数映射可能在调用瞬间写入磁盘；computer-use 控制器可能在任何懂 OAuth 的服务器之前点击提交；MCP 客户端也可能连接多个实现不一的服务器。若只有某个合作端点执行核验，而相同凭据还能从旧 wrapper 直达后台，绕过路径才是实际产品。

邮件讨论的后续提出一种非正式表述：最终参数摘要没有匹配已授权政策断言时，主机不得调用工具入口。这是参与者观点，不是标准。但它指出三个必要动作：比较最终 live 参数，确认权限仍有效且面向这个 sink，并在调用前原子消费一次性权限，以阻断并发与重放。

RFC 9449 的 DPoP 在这里仍然重要。它把令牌约束到密钥，减少令牌被盗后的重放，却不证明持钥者的这次行为符合用户意图。RFC 8693 能交换令牌并表达委托或冒用语义，却也不会自动审定终端参数。身份、委托、行为与结果是相邻层，不是同一个事实。

执行之后还需要另一条证据链。权限已消费后进程宕机，请求可能从未发送，也可能已在下游提交。盲目重试会重复付款；永不重试会丢失任务。可靠系统要共享幂等标识，区分“已授权、已提交、已接受、已落地、已观察”，并支持对账与补偿。HTTP 200 只是协议响应，不是业务目标完成。

最小回执应从模型之前开始：委托人或政策身份、版本化 mandate、任务上下文、批准边界；候选阶段的工具、后果等级、canonicalization 版本和最终摘要；授权阶段的独立依据、签发者、audience、expiry 与持钥约束；sink 阶段的 live 摘要、目的地、重放检查与消费结果；最后才是下游状态、撤销或补偿以及用户可见结果。

这也决定“取消任务”能否兑现。仅撤销一个可复用令牌，无法说明哪些候选行为已获批、哪些一次性权限已消费、哪些调用正在途中、哪些效果需要逆转。若系统不能从 T0 mandate 追到 T1 receipt，取消按钮只是没有因果链的承诺。

Heng Lu 的最小初始规范原则主张共享层保持薄：标准只需让不同系统辨认 mandate、行为、绑定、sink 与回执，本地机构保留风险阈值和审批政策。把所有企业决策塞进全球协议，会制造新的权力瓶颈。

他的现实层次论则要求拒绝概念冒充：令牌是协议事实，policy assertion 是授权事实，dispatch receipt 是实现事实，外部状态改变是运营事实，用户目的达成才是结果事实。前一层可以支撑后一层，不能代替后一层。运行代码优先把最终裁判交给破坏性测试：批准后篡改收款人、同时使用一次性权限、从遗留入口绕过、消费后杀死进程。任何路径若能在没有匹配回执时产生效果，系统拥有的只是授权词汇，不是授权控制。

来源