摘要

  • Agent Authorization Center 草案把用户、智能体及自动访问政策集中在一处：服务在自动名单内直接批准，在禁止名单内拒绝，其余情况才询问用户。
  • 授权令牌应包含用户账户、智能体与授权中心标识；“自动批准还是人工批准”的标记却是可选的。草案的安全考虑章节目前只有 TBD。

把服务写进名单，往后的敲门声就可以省掉。这是智能体授权中心草案真正改变的动作。它聚焦个人设备上的智能体，想让智能体替用户办事时少一次次打断本人。便利来自一项更早的决定：谁把哪家服务放进可以自动通过的名单。

草案所称的 AAC 保管用户身份、用户与智能体组及具体智能体的关联，以及个性化的自动访问政策。智能体先向服务方提出访问请求，带上用户和 AAC 标识；服务方引导它去中心申请授权。中心收到用户、智能体和服务方信息后查询名单：自动名单命中便无须当次人工介入；禁止名单命中则拒绝；两边都没有才向用户请求确认。

批准之后，流程仍用 OAuth 授权码。AAC 发码，服务方换取访问令牌并验证，再按用户权益提供服务。草案要求令牌应带上用户账户、智能体和 AAC 标识，却只说可以附带批准方式。服务方因此可能知道“这个令牌有效”，不知道“这次授权有没有人当场同意”。

名单适合安排日常任务，也会把一次设置延长成未来的多次决定。六页草案没有规定名单条目按具体动作收窄的规则、修改记录、失效期限或撤回时序。它说服务方仍按用户权益提供服务，但“允许去这家服务”与“允许下这笔单、公开这份资料、改这个账户”之间还有一层决定。谁写那一层规则，接收方能否核实，才是快通道的实际边界。

目前草案的 Security Considerations 一节仅写 TBD。RFC 9700已给出 OAuth 授权流程的安全实践，RFC 7636定义了授权码的 PKCE 保护。新草案还需写清智能体、AAC 与服务方各自怎样使用保护；它没有提供部署试验记录。

Datatracker 将它列为 I-D Exists 的个人 Informational 草案。接下来的试验很具体：将一家服务加入自动名单，只准智能体办一件有限的事，随后修改名单，再看服务方从下一枚令牌究竟能验证什么。有效令牌和当次人工同意，需要两张不同的凭据。