可验证的智能体授权委托：从技术身份到被委派的权限
两份 IETF 互联网草案对智能体身份、访问授权与授权委托作了哪些规定——又把哪些问题留给了组织
本页的性质。本页是 ARENOMICS Institute 对两份 IETF 互联网草案（Internet-Draft）所作的教育性分析。互联网草案是工作文件，不具备标准的正式地位，随时可能被修改或放弃。draft-hulea-wimse-agent-mandate-00 是 2026 年 10 月 24 日的个人提交草案，尚未被任何 IETF 工作组采纳；draft-ietf-wimse-aims-00 是 WIMSE 工作组 2026 年 9 月 15 日的工作组草案，并非 RFC。研究院与 IETF、WIMSE 工作组及各位作者均无关系，未对这些文件作出任何贡献，也未实现或测试过它们。
如何阅读本简报
全文区分三类表述，每一段都带有相应标签：
- 草案原文所述 互联网草案本身规定或陈述的内容，以贴近原意的转述和简短引文呈现；
- 研究院分析 研究院对草案已解决什么、尚未解决什么的解读；
- 教育问题 — ARENOMICS Institute 研究院为 Mandate Engineering 教学而正在发展的问题与立场。
本简报延续研究院分析 The 10,000-Agent Problem（2026 年 10 月 12 日）的第 3 节。该分析发现，智能体身份方面的标准化工作正在趋于一致，而授权委托方面则没有。文件状态于 2026 年 10 月 26 日在 IETF Datatracker 上核对。本页以“授权委托”译 mandate，以“访问授权”译技术意义上的 authorization。
A. 两份草案，两个不同的问题
IETF Datatracker 显示的文件状态，2026 年 10 月 26 日
| AI Identity Management System (AIMS) | Verifiable Mandates for Agents Acting Across Administrative Domains | |
|---|---|---|
| 草案 | draft-ietf-wimse-aims-00 | draft-hulea-wimse-agent-mandate-00 |
| 类型 | IETF WIMSE 工作组（Workload Identity in Multi System Environments）的工作组草案 | 个人互联网草案：未定义流程（stream），未被任何工作组采纳；其页眉带有 WIMSE 工作组名称，Datatracker 将其列为与 WIMSE 相关的文件 |
| 日期 | 2026 年 9 月 15 日 | 文件页眉为 2026 年 10 月 24 日；Datatracker 为 2026 年 10 月 23 日 |
| 预期状态 | 文件页眉为 Informational；Datatracker 未设置 | 文件页眉为 Standards Track；Datatracker 未设置 |
| 到期 | 2027 年 3 月 19 日 | 2027 年 4 月 27 日 |
| 作者 | P. Kasselman（Defakto Security）、J.-F. Lombardo（AWS）、Y. Rosomakho（Zscaler）、B. Campbell（Ping Identity）、N. Steele（OpenAI）、A. Parecki（Okta） | C. Hulea（Braincap SRL） |
| 目的 | 将已发布的标准（OAuth 2.0 系列 RFC、SPIFFE、OpenID 规范）与仍在制定中的互联网草案（WIMSE 协议草案、OAuth 事务令牌、身份链接、身份断言 JWT 授权许可）组合配置，提出 AI 智能体身份认证与访问授权的最佳实践；不定义新协议 | 一种令牌格式和一套确定性流程，使一个管理域中的依赖方能够验证代表另一管理域中委托人行事的智能体的授权委托 |
| 实现声明 | 未作声明 | 未作声明；带签名的测试向量预告将在后续版本中提供 |
草案原文所述 AIMS 开篇即称：“本文件提出 AI 智能体交互中身份认证与访问授权的最佳实践。”授权委托草案指出了一个更窄的缺口：“尚未定义的，是证明授权委托根部一方有权授予该委托的证据。”
研究院分析 两份文件回答的是不同的问题。AIMS 描述智能体如何在现有身份基础设施中证明自己是谁并获得访问权限；授权委托草案追问的是：另一个组织中的陌生方如何核实该智能体确实获得了其所声称的权力，而且授予者有权授予。授权委托草案本身将其与 AIMS 的关系描述为互补。两者都不是标准；Datatracker 目前列出的与 WIMSE 相关的个人草案共有十八份，授权委托草案是其中之一，其中有数份涉及委派链和访问授权证据。
B. 智能体身份与工作负载身份认证
草案原文所述 AIMS 将智能体视为工作负载（workload）。“参与本框架的智能体必须被分配恰好一个 WIMSE 标识符，该标识符可以是 SPIFFE ID”；智能体的凭证应当是短期的，并且必须带有明确的到期时间；智能体通过双向 TLS、WIMSE Workload Proof Token 或 HTTP Message Signatures 进行身份认证。“静态 API 密钥是智能体身份的反模式。”语言模型本身“不得访问智能体的凭证”。
草案原文所述 授权委托草案说明了这种身份能证明什么：运营方签发的 Workload Identity Token 断言的是一个绑定到密钥的实例标识符，而不涉及模型、其配置或其行为。
研究院分析 身份回答两个问题：这是哪个正在运行的工作负载？它能否证明这一点？它并不说明是谁允许该工作负载行事、代表谁、在什么限度之内。这些草案与“10,000 个智能体”分析中的判断一致：身份是标准化工作正在趋于一致的层面。
C. 访问授权与组织权限
草案原文所述 在访问授权方面，AIMS 以 OAuth 2.0 作为委派框架。在访问令牌中，智能体是客户端（client），它所代表的用户或系统是主体（subject）。用户通过授权码流程进行委派；以自身名义行事的智能体使用客户端凭证或 JWT 授权许可。令牌可以换取绑定到单一事务的短期事务令牌，而把智能体的令牌转发给下游服务被称为反模式。事务令牌、身份链接和身份断言 JWT 授权许可本身都由仍在制定中的互联网草案定义。当需要由人确认某项操作时，智能体“不得将本地界面上的确认本身视为充分的访问授权”。
研究院分析 OAuth 授权许可记录的是某个用户或系统同意在一定范围内允许某个客户端访问。它并不记录此人在其组织内部是否有权授予这种权力——例如，把司库智能体接入公司银行账户的员工，是否有权让公司承担付款义务。技术上的访问授权与组织权限是两种不同的关系：前者可以完美无缺，而后者却可能根本不存在。
D. 授权委托、权限断言与验证
草案原文所述 授权委托草案把通常被混为一谈的角色区分开来：委托人（principal），即智能体代表其行事的一方；委派人（delegator），即授予根授权委托的一方——委托人本人或有权代表其行事者；权限来源（authority source），即断言委派人拥有该权限的一方；授权委托签发方，即依委派人指示签署授权委托的一方；智能体实例；以及另一管理域中的依赖方。草案举的例子是：公司的司库智能体在公司开户银行发起付款，以及经纪商的智能体向托管机构发送指令。
草案原文所述 草案随后把两份签名声明分开。授权委托断言（Mandate Assertion）表明某项授权委托已被授予；权限断言（Authority Assertion）由权限来源（例如法定代表人登记簿）签发，表明委派人有权授予该委托。草案指出：“仅凭一份授权委托断言，绝不能确立委派人的权限。”草案并未规定哪些权限来源可以接受；就欧盟而言，草案指出断言可以依据欧盟第 2024/1183 号条例下的电子属性证明生成。
草案原文所述 验证按十三个有序步骤进行，从链的结构、签名、时间和撤销状态，到委派人的权限、密钥绑定、受众，以及所请求操作与授权委托是否匹配。验证方执行所有能够执行的步骤并记录每一项失败，而不是在第一处失败时停止；并且“两个符合规范的验证方在输入完全相同时，必须得出完全相同的验证结果。”结果为有效、无效，或在仅无法获取撤销状态时为不确定。
研究院分析 这一提案直指 Mandate Engineering 的出发点：不仅要问智能体可以做什么，还要问作出这一决定的人是否有资格作出它。草案的贡献在于，让不信任第一个组织的一方也能核查后一个问题。它的依赖同样清楚：这种核查的可靠程度，取决于权限来源以及决定哪些来源可被认可的信任框架，而草案有意对二者都不作定义。
E. 委派链与权限收窄
草案原文所述 在授权委托草案中，智能体只有在最大深度允许时才能再委派。每个子授权委托的到期时间不得晚于其父委托，并且必须收窄（attenuation）：凡与子委托匹配的请求，也必须与父委托匹配。累计预算随链传递，因此子智能体的操作计入同一限额。草案也指出了仅靠收窄的局限：“一条只会收窄的链，证明没有任何一跳超出其上一跳”——而不能证明根授权委托处于委派人自身的权限之内。
草案原文所述 AIMS 没有定义多智能体委派链的通用模型。它通过令牌交换和身份链接来处理跨信任域的访问，要求智能体只申请所需的最小范围，并用绑定到单一事务的事务令牌来收窄访问。
研究院分析 权限收窄是正当委派链的必要条件，但不是充分条件。一条链完全可以从一个本无权限发起它的根部出发，在每一步都正确地收窄。草案为 Foundation 课程以组织语言阐述的一个要点提供了精确的技术词汇：委派所传递的权限只能少于、不能多于委派人所拥有的权限，而且第一个环节本身必须有正当依据。
F. 撤销、到期、执行限额与审计证据
草案原文所述 授权委托草案以可由机器检查的谓词表达限额——等于、属于、上限、下限和时间窗口——另有两个有状态的谓词：滚动周期内的累计预算，以及超过阈值时须由第二方会签。金额以十进制字符串表示：“金额不得使用 JSON 数字。”每个令牌只授权执行一次操作；其有效期受链中最早到期时间的限制；撤销状态在验证时检查一次，在访问授权时再检查一次。关于时延，草案指出签发后的撤销“最迟在令牌到期时生效”。依赖方应当保留验证结果、决定和执行确认；为应对争议而保存的记录可能需要在多年内保持可验证。
草案原文所述 AIMS 要求对访问授权决定和补救措施保留持久的审计日志，其中除其他信息外还应记录智能体标识符、被委派的主体、资源、操作和决定：“审计记录必须具备防篡改可检测性，并按部署方的安全策略保存。”撤销和风险信号可以通过 Shared Signals Framework 分发，接收方“必须确保已被撤销或降级的访问授权得到及时执行，不得无故拖延。”
研究院分析 两份草案都为证据链提供了原材料。但两者都不决定由谁审查这些证据、什么算作合规：AIMS 把合规标准视为各部署方自己的事情，授权委托草案则把保存期限、法律责任和争议处理留给信任框架。草案自己把多个依赖方共享累计预算列为未决问题，因此一个看似全局的限额，实际上可能只由各依赖方分别执行。
G. 尚未解决的层面：从组织意图到可强制执行的访问权限
草案原文所述 AIMS 指出，智能体通常以自然语言接收任务，并且“将任务转化为访问授权要求，预期作为规划步骤，在智能体请求访问授权之前完成。”AIMS 把这一转化过程本身排除在范围之外，策略模型及其格式同样如此。
草案原文所述 授权委托草案不“定义信任框架、保证级别或授权委托的法律效力”，也不定义如何向委派人展示授权委托及其如何表示同意，更不判断智能体的推理或输出是否正确。“该格式能够表达范围狭窄的授权委托，但无法强制签发方这样写。”关于操纵问题：“有效的授权委托表明某项操作处于被委派的权限之内，而不表明智能体没有被操纵去请求这一操作。”
研究院分析 这些草案使转化的结果可以验证，却既不执行也不检查转化本身。像“在每月预算内向已批准的供应商付款”这样的授权委托是否体现了董事会的本意、限额是否恰当，以及当一项有效的授权委托导致有害操作时由谁负责，仍然是组织和法律层面的问题。这正是“10,000 个智能体”分析所说的尚未处理的层面。在这些草案之后，它依然没有得到处理，但现在至少在一侧有了更清晰的技术边界。
H. 草案为 Mandate Engineering 解决了什么——又留下了什么
| Mandate Engineering 的问题 | AIMS（工作组草案） | 授权委托草案（个人草案） | 仍未解决 |
|---|---|---|---|
| 这是哪个行动者？ | 智能体标识符、短期凭证、工作负载身份认证 | Workload Identity Token；可选的证明结果 | 身份能说明模型、其配置和行为的什么 |
| 谁授予了权力——他们是否有权这样做？ | 来自用户或系统的 OAuth 授权许可 | 授权委托断言，加上来自权限来源的独立权限断言 | 哪些权限来源和信任框架被认可，由谁认可 |
| 它可以做什么，在什么限度之内？ | OAuth 范围；事务令牌 | 谓词、累计预算、会签阈值、一次性令牌 | 这些限额是否体现了组织的真实意图 |
| 它可以委派到何种程度？ | 跨域的令牌交换与身份链接 | 最大深度、到期和收窄规则；共享预算 | 多个依赖方之间以及多个根授权委托之间共享的限额 |
| 如何让它停下来？ | 通过 Shared Signals Framework 传递撤销与风险信号 | 两次检查状态；撤销最迟在令牌到期时生效 | 紧急情况下谁有权撤销，以及撤销多快生效 |
| 什么能证明合规？ | 持久且可检测篡改的审计记录 | 保存的验证结果、决定和执行确认 | 合规标准、由谁审查、保存期限和争议处理 |
| 谁为它的行为负责？ | 未涉及 | 法律责任留给信任框架；法律效力不在范围之内 | 委托人、运营方和签发方的问责 |
研究院分析 优点：授权委托草案把授予行为与其背后的权限分开，定义了确定性的验证，使每个令牌只能使用一次，并坦诚对待操纵风险。AIMS 由已发布的标准及若干仍在制定中的互联网草案搭建了一套连贯的身份与访问基线。局限：授权委托草案是单一作者的个人草案，未被采纳，没有实现报告，也没有公布测试向量；它与其他关于委派链的个人草案有重叠，并自称其链格式可以被替换；两份草案都可能发生重大变化。
教育问题 — ARENOMICS Institute 研究院将这些文件视为授权委托问题已进入技术标准讨论的证据，而不是可供讲授的标准。在 Foundation 课程中，它们可以作为示例，说明一项有边界、可撤销的授权委托可以如何表达和核查。课程不要求学员使用它们，课程规范也没有改变。
开放的研究问题
- 应当认可谁作为组织委派行为的权限来源？这种认可本身又如何治理？
- 如何证明一项以机器可检查的限额写成的授权委托，与它所要表达的组织意图相符？
- 当同一项授权委托同时被多个依赖方采信时，限额和撤销应当如何运作？
资料来源
- C. Hulea（Braincap SRL），Verifiable Mandates for Agents Acting Across Administrative Domains，draft-hulea-wimse-agent-mandate-00，个人互联网草案，2026 年 10 月 24 日，2027 年 4 月 27 日到期。Datatracker · 全文。
- P. Kasselman、J.-F. Lombardo、Y. Rosomakho、B. Campbell、N. Steele、A. Parecki，AI Identity Management System，draft-ietf-wimse-aims-00，WIMSE 工作组互联网草案，2026 年 9 月 15 日，2027 年 3 月 19 日到期。datatracker.ietf.org/doc/html/draft-ietf-wimse-aims-00。
- IETF，Workload Identity in Multi System Environments（WIMSE）工作组文件页面，2026 年 10 月 26 日访问。datatracker.ietf.org/group/wimse/documents。
- ARENOMICS Institute，The 10,000-Agent Problem: Who Has the Authority to Let Machines Act?，v0.1，2026 年 10 月 12 日。
核查：标题、作者、日期、状态和每一处引文均已于 2026 年 10 月 26 日对照原文件和 Datatracker 核对；引文译自英文原文。互联网草案经常变动；在依据任何细节之前，请在 Datatracker 上核对当前版本。