摘要

  • 2026 年 9 月 28 日提交的 AAuth-R3 初版是个人 Internet-Draft，不是 RFC、IETF 背书或部署证据。其第 10.4 节允许没有外部后果的待处理调用先执行，再让人决定是否把固定结果交给智能体。
  • 审批说明必须明示调用已经执行。资源服务器可描述实际返回的记录数、字段类别和敏感性，而不是让人只凭查询语句猜测披露范围。
  • 若执行本身会触发审计记录、计量、收费、限额消耗或第三方调用，批准必须先于执行；把接口称作“只读”不能替代这个检验。

按钮前面的动作已经发生

想象智能体请求查询一批员工资料。资源端运行后发现结果包含薪酬和住址，却暂时不交付。人的屏幕此时不应写成“是否允许查询”，因为查询已经结束；真正待决定的是是否向智能体披露这份现成答案。AAuth-R3 初版文本把这一情形称为批准结果释放，而非批准执行。

区别并非措辞游戏。查询条件无法保证说明结果规模：十行与千万行带来的披露风险不同，字段名也可能不在提问文字中。草案让资源端在单次调用提案的可选 result 成员里描述实际数量和数据类别，供发行方及面向人的服务评估；结果本身不随提案传输。资源端还能决定隐去或删减什么。人看到的是资源端提供的描述，因此描述不充分时，即使授权令牌正确，知情选择仍可能失真。

草案同时划出停止线：只有执行不改变结果以外的任何东西，才可以先跑。某些看似读取的调用会写入访问审计、消耗费率配额、产生账单，或通知别的组织。上述任何后果都发生在结果交付之前；后来拒绝披露，也不会抹掉费用或日志。因此这类调用必须先拿到批准，不能把“暂存答案”当成“尚未行动”。

固定的结果与可替换的参数

Datatracker目前把 -00 列为 I-D Exists 的个人草案。文本设计的是单次调用提案：写明操作、具体参数，令牌用 r3_uri 和 r3_s256 指向提案，不直接装入参数。资源端若以 HTTP 202 暂存调用，随后收到单次授权令牌才完成待处理流程；若以 401 要求智能体重试，就必须把实际参数与已批准提案逐项比对。对摘要表示的大型或敏感值，比对还要求原始字节一致。同一令牌不得执行两次调用。

对于已在批准前执行的合格调用，结果已经定格，人的选择针对这一份答案，而不是未来可能变化的再次查询。但结果定格不等于自动可披露：资源端仍决定哪些结果说明交给审批界面、哪些数据可放行。这也是控制权的重心。记录“用户点了同意”而不记录用户同意的是执行还是披露，日后无法解释系统究竟阻止了什么。

文本未提供实际部署、互通测试或事故统计。本站此前关于 AAuth 的稿件分别讨论并行令牌预算总额和异步事件的中介收件回执；本文关注的是同一调用中执行已完成、交付尚未发生的时间缝隙。

来源