多跳委托：Agent 转包 Agent，权限为什么必须"逐跳收敛"
上一篇给 Agent 发身份证时，三道关——标识、认证、登记——里我特意留了一道没展开的开放题：多 Agent 交接时，身份和权限必须"每跳收敛"。 那篇只给了结论和四个要记录的字段，没往下钻。这一篇专门补上，因为它正在变成企业落地 Agent 最硬的一道坎。
场景一点都不抽象。你授权一个客服 Agent 帮你处理退款，它自己搞不定，转手叫来退款 Agent，退款 Agent 又拉上风控 Agent 核验——一次授权，任务在三四个 Agent 之间层层转包。问题是：你只授权了"退款不超过 500 元、只动我自己的订单"，这份权限传到第三跳的风控 Agent 手里，还剩多少？该剩多少？
现实里的答案往往是：一分没少，甚至更多。上游 Agent 把用户的令牌原样丢给下游，或者干脆共用一个万能 API Key，下游继承了全部权限。平时没事，可一旦链条中有一个 Agent 被提示注入、被投毒、或本身就是恶意的，它就能拿着上游的全权干任何事——越额支付、越权查库、删除数据。更糟的是出了事你还查不清：日志里只看到"这个令牌被用了",看不出是哪一跳、哪个 Agent、越了谁授的权。
这就是 多跳委托（multi-hop delegation）问题。WorkOS 把它称为"企业采用 AI Agent 的决定性技术难题",NIST 在 2026 年 2 月的概念文件里把它明确列为开放题。下面我们从事故现场开始，一路拆到怎么解。
一、先看事故：不收敛的委托链是怎么爆的
多跳委托不是纸上谈兵的隐患。2025 下半年，安全研究者接连披露了一批真实漏洞，它们形态各异，但根因惊人地一致。
2025 年 9 月，Cross-Agent Privilege Escalation（跨 Agent 提权）。安全研究员 Johann Rehberger 演示：当 Copilot、Claude、Gemini 等多个 Agent 共用一个代码库时，一个被提示注入攻陷的 Copilot，可以去改写 Claude Code 的 .mcp.json 配置文件；Claude 下次启动时加载这份被投毒的配置，就执行了攻击者的代码，反过来还能再去重配 Copilot。用他的话说，"一次简单的间接提示注入，能迅速升级成多 Agent 的连环沦陷。"
2025 年 11 月，Agent Session Smuggling（会话夹带）。Palo Alto Networks 的 Unit 42 展示了一条更隐蔽的路径：一个理财助手 Agent 向研究助手 Agent 要市场资讯，研究助手（已被控制）在返回的新闻摘要里夹带了一条隐藏的股票买入指令。理财助手照单全收，在用户毫不知情的情况下买入了 10 股。用户只看到一段干净的新闻摘要，那个 buy_stock 调用完全隐形。Unit 42 的判断很冷峻：一个被攻陷的 Agent 是"更强大的对手"——它能自主生成适应性策略，利用会话状态，把影响力扩散到所有相连的 Agent。
同期还有 ServiceNow Now Assist（2025 年 10 月，AppOmni 披露）：低权限 Agent 通过"Agent 发现"机制招募高权限同伴，借它们的手把数据倒出去；以及 EchoLeak（微软 365 Copilot，CVE-2025-32711，CVSS 9.3，2025 年 6 月）：邮件里的隐藏提示零点击触发，从 SharePoint、Teams、OneDrive 静默拖走数据。
这些事故摊开看，攻击面各不相同，但失守的机制是同一个：
- 权限继承或透传：下游 Agent 直接拿到了上游的完整授权，没有任何收窄；
- 信任链断裂：每一跳都默认信任上一跳的输出，没有一层去校验"这个动作还在不在最初授权的范围内";
- 无凭证血缘：到了第三跳，已经没有任何密码学证据能追回到最初那个人和那次授权。
这不是小概率事件。云安全联盟（CSA）2026 年初的分析指出，绝大多数非人类身份（97%）本就携带过度授权；另一组被反复引用的数据是，80% 的身份泄露事件涉及被攻陷的非人类身份（服务账号、API Key 之类），而只有 5.7% 的组织能完全看清自己有哪些服务账号。地基本就是歪的，Agent 只是把这些长期被忽视的过度授权，以机器速度接进了支付、数据库和对外 API。
一句话：当授权在委托链上不收窄，任意一跳被攻破，爆炸半径就是整条链。
二、单跳好办，多跳崩盘：OAuth 为什么不够
要理解难在哪，得先承认单跳其实已经解决了。
身份篇第四关和MCP 直连数据库那篇都讲过 OAuth 2.0 On-Behalf-Of（OBO）/ RFC 8693 令牌交换：用户授权 Agent A，A 拿这份授权去授权服务器换一张代表用户、但范围更窄的令牌，去访问服务 B。身份链清清楚楚：人 → Agent A → 服务 B。授权服务器能验证这次委托，审计日志能还原谁干了什么。这就是单跳，today 能跑通。
多跳把这个模型击碎了。当 A 派生出 B、B 调 C、C 访问服务 D，授权链变成 人 → A → B → C → D。RFC 8693 确实能用嵌套的 act（actor）声明把这条链表示出来，但规范自己写明：消费令牌的一方只应考虑顶层声明和当前 actor，那些嵌套在里面的前序 actor 声明"仅供参考"（informational only），不得用于访问控制决策。
这句话值得停下来品一下——OAuth 自己的标准都承认：多跳场景里，它并不真正强制那条委托链。 嵌套 act 声明是一串"面包屑",能看，但不能当证据用。
于是就剩两条难看的退路：
| 做法 | 怎么运作 | 致命问题 |
|---|---|---|
| 每跳回授权服务器换票 | 链上每个 Agent 都去 AS 换一张下游令牌 | AS 成为每次委托的必经参与者：单点依赖 + 高延迟。AS 一挂，整条多 Agent 工作流全停；成百上千次机器速度的转包，AS 直接被打爆 |
| 令牌透传 / 共享 Key（反模式） | 把上游令牌原样传给下游，或全公司共用一个 Key | 零收敛，下游继承全权；出事无法归因——SIEM 看到的是一串成功认证，根本分不清是哪个 Agent 被攻陷 |
Red Hat 在 2026 年 5 月的一篇文章里把这对矛盾提炼成 "假冒 vs 委托"（impersonation vs delegation）：透传令牌本质是让 Agent 假冒（impersonate） 成你，继承你的一切，一旦被攻陷攻击者就拿到你令牌能碰的所有东西，而且下游一多，审计链就融进"同一个身份"里消失了。真正该做的是委托（delegation）——Agent 拿到的是一份明确收窄、且身份和你分离的授权，每一跳都可追溯。
难点于是变得很具体：怎么让权限在去中心的多跳链上一路收窄、还能被下游离线验证、出事还能精确归因，同时不必每跳都回中心换票？
三、核心原则：权限只能越传越窄
所有靠谱的方案，最后都收敛到同一条原则上：委托链的每一跳，权限必须小于等于上一跳；没有任何 Agent 能派生出比自己更大的权限，也不能委托它自己都没有的能力。
这条原则有个更技术的名字——单调收敛（monotonic attenuation），或者叫权限衰减。它对应一个朴素的集合关系：
第 k 跳的权限是第 k-1 跳的子集，一路上溯，任意下游的权限都不超过用户最初的授权 scope₀。Red Hat 在 Kagenti（一个开源 Agent 编排项目）的零信任 demo 里，把它写成一个更好记的公式——权限求交（permission intersection）：
用户授权给 Agent 时，系统取"用户被允许访问的"与"这个 Agent 被配置能访问的"两者的交集，谁也没法越过自己的边界往上扩权。他们举的例子很直观：Bob 有财务和管理员两个部门的权限，他委托给一个只有"财务 + 工程"能力的摘要 Agent，交集就只剩财务——Bob 的管理员权限在这次委托里自动丢掉了，他能碰的文档从 3 份降到 2 份。哪怕换一个"拥有全部部门权限"的 Agent，也没法让 Bob 拿到他本来就没有的 HR 文档。Agent 在这里扮演的是"权限限流器",只会做减法。
除了子集这条主约束，一个完整的收敛模型还得管住另外三件事，缺一个都留后门：
- 委托深度上限：链不能无限接下去，超过阈值就拒绝，防"无限转包";
- 环检测：委托链里不能出现重复的 Agent（A→B→C→A），否则会被绕成自我强化的控制回路（Cross-Agent 提权正是这么升级的）;
- fail-closed（默认拒绝）：一旦发现越界、断链、超深、成环——一律拒绝，而不是默认放行或"交给应用自己判断"。传统系统最常见的错误恰恰是缺省放行。
把这几条合起来看，收敛的价值不只是"更安全",而是把三件过去做不到的事变成了可能：权限恒收窄（缩小爆炸半径）、逐跳可追责（每一跳都留下"谁委托谁、收窄到什么范围"的记录）、以及离线可判定（下游不必回中心问，凭手里的信息就能算出这次请求越没越界）。难点全在于——这三件事怎么同时做到。 业界目前有两条技术路线。
四、两条技术路线：中心策略引擎 vs 自包含令牌
收敛原则大家都认，分歧在于在哪里、用什么来强制它。业界分成两派，各有代价。
路线一：运行时中心策略引擎——授权判断从令牌里挪出来。
这条路不去改 OAuth 的令牌模型，而是在 Agent 调工具的那一刻，插一个独立的策略层现场做决定，不管 Agent 手里拿的是什么令牌。代表是 AWS 用 Cedar 做的三层授权参考实现（Cedar 是 AWS 开源的授权策略语言）。它把每次调用拆成三层策略，遇到第一个拒绝就停：
- L1 Agent→工具：这个 Agent 的信任分够不够（1–5 分）、命名空间对不对（比如
payments）、是不是production阶段; - L2 Agent→Agent 委托：委托深度在不在限内（硬上限 5 跳），请求的能力是不是目标 Agent 已注册能力的子集;
- L3 发起用户授权：最初那个人有没有
admin角色、过没过 MFA、委托深度够不够浅。
它的测试场景很能说明问题：一个 admin 用户带 MFA、请求删除记录，但委托链有 6 跳——L1、L3 都过，L2 因为深度超过 5 跳直接拒绝。哪怕是授权的管理员，也绕不过深度约束。这套东西跑在 Agent 的推理循环之外，用 HMAC-SHA256 给用户上下文签名防篡改，每次判定都产出一条 OCSF 审计事件。OWASP 的《Agentic 应用 Top 10》把它防的这类风险编号为 ASI03：身份与权限滥用。
同一路线上还有 Auth0 FGA（基于 Google Zanzibar 的关系型访问控制 ReBAC），把委托状态存在策略引擎里、每跳收窄，好处是不用换令牌格式就能实现能力式收敛；以及 Google 2026 年 4 月发布的 Gemini 企业 Agent 平台，内置一个能感知 MCP 和 A2A 协议的 Agent Gateway，在 Agent 到 Agent、Agent 到工具的连接上强制策略。
这条路的软肋：策略引擎（或授权服务器）容易变成每跳必经的中心节点，把委托拓扑和它的可用性绑死——这正是身份篇提醒过的"厚腰"风险。
路线二：自包含能力令牌——把收敛编进令牌，离线就能验。
另一派的思路是让令牌自带约束、离线可验，不必回中心。这类"能力令牌"其实有十来年历史了：
- Macaroons（Google，2014）：基于 HMAC 链式签名的授权凭据，持有者可以给令牌追加 caveat（约束条件），生成一张新的、权限只会更小的令牌，支持去中心委托和离线验证;
- Biscuit（Clever Cloud）：用 Datalog 描述授权逻辑，主打离线衰减（offline attenuation）——持有令牌的一方无需请求授权服务器签发新令牌，就能给它加约束、收窄权限。
Okta 在分析里点得很透：这类令牌"烘焙"进了身份、有效期和一个密码学根，持有者只能往上追加"只减不增"的约束层，形成一条只能收窄、离线可验的链——研究 Agent 想调 buy_stock，请求会带着"谁在哪一跳限制了什么"的证据被拒掉。代价也很直白：目前没有一家主流身份厂商原生支持 Macaroons 或 Biscuit，而且离线令牌一旦签出去，吊销很难（这一点第六节细说）。
两派正在收敛到中间地带，而这正是 2026 年最值得盯的动向——IETF 的 OAuth 工作组同时在赶四份草案，每份补一个短板：
| IETF 草案 | 解决什么 | 关键机制 |
|---|---|---|
| Attenuating Authorization Tokens for Agentic Delegation Chains | 权限逐跳收窄 | 扩展 RFC 9396（Rich Authorization Requests），定义一套带类型的约束词汇，强制每跳单调收敛；且验证算法无需联系根授权服务器即可校验整条收敛链，去掉了回源瓶颈 |
| Cryptographically Verifiable Actor Chains（Oracle、摩根大通、Telefónica、Aryaka 工程师联合起草） | 证明"谁真的在链里" | 让令牌携带防篡改的前序 actor 记录，接收方能验证完整委托路径而非只信直接发送方；一种模式全链可读，另一种让每跳只证明自己被授权、而不暴露链上其他方（跨组织时有用） |
| OAuth Identity and Authorization Chaining Across Domains | 跨组织的委托链 | 结合 RFC 8693 令牌交换与 JWT bearer 授权（RFC 7523），让请求跨越不同授权服务器时，每个资源方仍知道最初那个人是谁、授了什么权 |
| TLS-Session-Bound Access Tokens | 令牌被偷也没用 | 把每张令牌绑定到它签发时的那条 mTLS 连接，被提示注入或工具侧信道偷走的令牌无法在别处重放 |
工作组里还有一个尚未成稿、但很关键的讨论：委托链拼接（delegation chain splicing）——攻击者往合法的 actor 链中间插入自己。2026 年 3 月的邮件列表提出的缓解思路是：要求第 N 跳的受众（audience）与第 N+1 跳的主体（subject）密码学匹配，再配短有效期和撤回授权时的后端吊销。
把两条路线摆到一起对比，取舍就清楚了：
| 维度 | 令牌透传（反模式） | 每跳回 AS 换票 | 中心策略引擎（Cedar/FGA） | 自包含能力令牌（Macaroons/Biscuit） |
|---|---|---|---|---|
| 权限是否收敛 | 否，继承全权 | 是 | 是 | 是 |
| 是否离线可验 | —— | 否，必回源 | 否，回中心引擎 | 是 |
| 机器速度 / 大规模转包 | 快但失控 | 慢、单点瓶颈 | 中，取决于引擎 | 快 |
| 可归因 | 几乎不可能 | 可 | 可（审计事件） | 可（链上证据） |
| 吊销 | —— | 容易 | 容易 | 难（离线令牌） |
| 落地成熟度 | 普遍（但危险） | 成熟 | 已有参考实现 | 生态支持少 |
没有银弹。企业级落地往往是组合拳：能力令牌管"离线收敛 + 归因",策略引擎管"上下文动态判定 + 吊销",mTLS/DPoP 绑定管"防重放"。
五、谁在推动，进展到哪了
这件事从"研究者敲警钟"到"厂商和监管一起下场",只用了大半年，节奏很快。
身份厂商在补委托层。 Okta 和 Auth0 推 Cross App Access（XAA），把同意（consent）收拢到身份提供商侧，基于 ID-JAG，能追踪并吊销委托血缘，让 Agent 的动作可记录、可撤销；这套东西 2025 年 11 月已被纳入 MCP 的"企业托管授权"。Auth0 还用 Token Vault 专治前面提过的"迷惑代理"（confused deputy）——要求提供当前用户会话的密码学证明，而不是随手传一个 userId 参数，避免被提示注入骗去取别人的凭据。
新玩家在给 Agent 造原生身份。 就在这几天（2026 年 7 月初），Vercel 收购了 Better Auth，要做一套 Agent Auth 协议，给 AI Agent 独立的、带 scope 的身份——又一个信号：Agent 的授权不该继续借用人类账号的老一套。硬件侧也在动，Delinea 与 Yubico 在 2026 年 RSA 大会上联手推硬件背书的角色委托令牌（Role Delegation Token），把高风险动作绑回到某个具体的人类决策，形成从 Agent 动作到批准人的可验证痕迹。
逼着大家动的，是合规。 监管这次跑在了技术前面：欧盟《AI 法案》更广泛的执行阶段 2026 年 8 月启动，对高风险 AI 系统的审计留痕提出明确要求，其第 14 条要求人类能充分理解并监督 AI 的运作。问题在于，传统审计日志只记录了 OAuth 令牌交换，记不下委托的语义——审计员能看到 A 换了令牌给 B、B 换给 C，却很难判断 C 的动作到底还在不在最初那个人授权的范围内。跨组织时更糟：链条碎在三个授权服务器、三套日志规范里，还原一条委托链的"证据链"变成一场手工取证。没有可验证的收敛委托链，第 14 条要求的那种监督就是空话。
这也是为什么 NIST 2026 年 2 月的 Agent 身份倡议、以及 IETF 那批草案，都反复强调：可验证的链，而不只是可表示的链——面包屑不够，监管要的是能对一次受控动作举证的完整监管链（chain of custody）。
六、还没解决的硬骨头
别被上面的进展迷惑，这道题远没结束。至少四块硬骨头还硌着牙：
一是离线令牌的吊销。 自包含能力令牌最大的优点（离线、不回源）恰恰带来最大的软肋：一张已经签出去、在链上流转的令牌，很难说撤就撤。中心策略引擎撤权很容易，能力令牌却要靠短有效期、后端吊销列表、或绑定连接来兜——这本质上又把一部分"中心"请了回来。离线可验与即时可撤，天然是一对矛盾。
二是语义注入，令牌管不住。 这是最反直觉、也最容易被忽视的一点：权限收敛能挡住"越权",却挡不住"在权限内被骗"。 Agent Session Smuggling 里那笔隐藏交易，每一步的令牌可能都合法、都在 scope 内——攻击活在 Agent 之间对话的语义层，而这是 OAuth 从设计上就看不见的地方。Unit 42 给的解法叫 context grounding（上下文锚定）：会话开始时立一个"任务锚",然后持续校验后续行为在不在语义上对齐最初意图。这已经超出授权协议的范畴，是另一个战场。
三是跨域根信任。 委托链跨越组织时，根令牌到底锚在谁的授权服务器上？B 组织凭什么信 A 组织签发的根？"跨域身份链"草案在试着解，但多信任域下的根切换、再签发，仍是开放问题。
四是生态与标准都没定型。 能力令牌没有主流 IdP 原生支持；IETF 四份草案还在 draft 阶段，随时可能改；"链拼接"这类攻击的缓解措施还没正式落进规范。现在下重注押某一个具体协议，都有返工风险——这也是为什么务实的建议是"为可迁移性架构",而不是赌某一份草案会赢。
七、工程落地：现在能做的清单
标准没定型，不等于只能干等。WorkOS、Okta、AWS 的实践已经沉淀出一批"押哪个协议都不亏"的动作：
1. 把多跳当显式架构题，别当隐式继承。
在编排器设计阶段就把委托链画出来：从人到 Agent、到子 Agent、到工具、到资源，每一步谁在场、哪里丢了归因。不允许"隐式继承用户全权"——单跳 OBO 能跑通，不代表多跳安全。
2. 每跳强制子集校验，宁可停下来重新授权。
每次令牌交换只准请求上一跳权限的子集，任何"变宽"的请求一律拒绝。如果后面某个 Agent 确实需要更大权限，正确做法是停下来回到用户重新授权，而不是让它在链上悄悄扩权。
3. 设委托深度上限 + 环检测 + fail-closed。
给链设硬上限（AWS 参考实现用的是 5 跳），检测重复 Agent 防成环，越界/断链/超深/成环全部默认拒绝。
4. 令牌绑定运行时，防重放。
用 mTLS 或 DPoP 做 sender-constrained 令牌，让被偷走的中间令牌没法在预期运行时之外重放。
5. 保住"最初是谁"这条归因线。
无论用哪条技术路线，都要保证每个下游动作能可验证地追回到某个具体的人类决策。把 Agent 当一等身份、给独立凭据，别共享 API Key 或长期服务账号令牌。
6. 高危动作走带外人审。
大额转账、生产部署、访问受监管数据这类，路由到 Agent 碰不到的通道（推送、独立 UI，而不是聊天框内）做人类确认——这正是针对 Session Smuggling 的对症下药。
7. 和支付、数据关一起验收。
支付篇的 Mandate、MCP 数据库篇的 OBO、责任篇的归因，全靠委托链这根钉子串成一条"人 → Agent → 子 Agent → 工具"的故事线。上线 checklist 里得能回答：日志里能不能把这条链串起来？
八、ICE 观察
技术层面：多跳委托的技术主线，是把"权限只减不增"从一句原则，变成可离线校验、可精确归因、还能防重放的工程约束。两条路线各有代价——中心策略引擎灵活但有单点，自包含能力令牌快而难撤——终局大概率是组合而非二选一：能力令牌管收敛与归因，策略引擎管动态判定与吊销，连接绑定管防重放。IETF 那四份草案谁先跑出参考实现、被主流 IdP 接纳，谁就握住了这层的定义权。这也是整个 Agent 授权栈里，护城河最深、也最没被填平的一块。
落地层面：企业最该记住一句话——权限收敛管越权，管不住语义注入。别以为上了 attenuation 就万事大吉，Session Smuggling 那种"在权限内被骗"的攻击，得靠上下文锚定和带外人审另开战场。优先级建议：清点过度授权的非人类身份 → 单跳 OBO 收窄 → 多跳设深度/环/子集约束并 fail-closed → 高危动作带外人审 → 令牌绑定防重放。97% 的非人类身份过度授权这个数字，说明大多数团队连第一步都没走完。
本土视角：国内的节奏其实是"身份层在快跑，授权收敛层还没起跑"。身份篇讲过的 AIP/AIC 国标，把"给 Agent 发身份证"推进到了实测入口——但那解决的是"你是谁",还没系统回答"你替谁、能做到哪一跳为止"。而这恰恰是可信数据空间、数据要素流通这类场景的硬需求：面向金融、政务客户，一次数据授权在多个 Agent 间流转时，必须能可离线验证的最小授权 + 逐跳可归因 + fail-closed，否则"数据可用不可见"的信任承诺就立不住。7 月上旬的一系列信号——国家数据局"数据要素×"发布会、"数据空间成为 AI 时代关键基础设施"的定调——都在把数据往 AI 和 Agent 上推；谁能在往里推的同时，把多跳委托的授权底座做扎实，谁卖的就不只是"能跑的 Agent",而是"出事查得到、越权走不通、对监管举得了证"的信任资产。这和责任篇、组织边界篇的逻辑一脉相承：Agent 时代真正稀缺的，是可验证的信任，不是又一个能力更强的模型。
结尾
给 Agent 发身份证，回答的是"你是谁";多跳委托要回答的是更难的下一问——"你替谁、被允许做到哪一跳为止"。
2025 下半年那几起事故已经把答案的反面演示得清清楚楚：只要权限在委托链上不收窄，任意一跳被攻破，整条链就是攻击者的。 而修复它的原则朴素得近乎笨拙——权限只能越传越窄，越界就地拒绝——难的从来不是想明白，而是在机器速度、跨组织、还要满足监管举证的现实里，同时做到"快、可验、可追、可撤"。
所以留个问题给你：如果现在有一条 Agent 委托链在你的生产系统里跑到第三跳，你能不能当场说清——这一跳的权限是谁给的、比上一跳窄了多少、出事能追到哪个 Agent？ 如果答不上来，那条链就已经是一张说不清的责任账单，只是还没到期。