A03 子 Agent 权限继承问题 · 知识库

当一个 orchestrator 在运行时 spawn 出一批子 agent 去并行跑子任务，一个看似纯工程的问题立刻变成安全问题：这些子 agent 应该带着父 agent 的哪些权限上路？ 全继承（图省事、传一份 service account token 下去）？还是逐跳最小化（每个子 agent 只拿它这一步任务必需的那一小撮工具与 scope）？本节点的判断是：子 agent 全继承父权限，等于把”权限提升”这件本该被严防死守的事，变成了系统的默认行为——它不是一个偶发漏洞，而是一种架构层面的”横向越权放大器”。本节用”委托代理”（delegation / principal-agent）这个跨域框架来给这个技术问题定性，并落到 PM 可操作的设计判据上。

§0 为什么是”委托代理”框架，而不是”权限分配”框架

读者脑中默认的框架往往是 RBAC 式的”权限分配”：把 agent 当成一个新员工，给它配一个角色，角色绑一组权限，配完即可。这个框架在单 agent、静态权限的场景下够用，但在 orchestrator 动态 spawn 子 agent 的场景下会整体失效，原因有三：

权限不是分配的，是被传递的。子 agent 的权限不是管理员事先配好的，而是父 agent 在运行时沿着委托链往下传的。RBAC 描述”谁有什么权限”，但回答不了”权限在多跳传递中应该怎么衰减、谁为最终那个动作负责”。
委托链是动态、不可预知深度的。orchestrator 可能再 spawn sub-orchestrator，链可以是 3 跳、5 跳，事先画不出完整的角色图。
责任主体在传递中会被”洗白”。一旦 token 被原样传下去，下游的工具调用在审计日志里看起来就是”父 agent 干的”，委托关系丢失——这正是经济学/法学”委托代理问题”（principal-agent problem）的技术翻版：代理人（子 agent）行动，但责任与信息不对称地留在委托人（父 agent / 用户）一侧。

所以正确的框架是委托授权（delegated authority）+ 逐跳衰减（scope attenuation），而不是静态权限分配。这个框架直接对接 0411 专题里的 A06 Orchestrator 编排器：orchestrator 不只是个任务调度器，它同时是一个授权下发点，每一次 spawn 都是一次委托决策。

§1 全继承模型：为什么”图省事”会放大爆炸半径

全继承的实现非常自然：父 agent 持有一个 service account token（或环境变量里的 API key、Kubernetes 挂载的 service account token），spawn 子 agent 时直接把这套凭证传下去，或让子进程继承同一环境。工程上零成本，所以它是事实上的默认。

它的安全代价是爆炸半径（blast radius）从单点放大到全链。考虑一条链：用户 → orchestrator（持有”读写数据库 + 发邮件 + 调支付”的全集 token）→ spawn 一个”总结网页内容”的子 agent。这个子 agent 任务上只需要”读取一个 URL”，但它继承了全集 token。一旦它读到的网页里藏着间接 prompt injection（被污染的工具返回值），攻击者就拿到了整条链的全部权限——本来只能污染一个”网页总结器”，现在能调支付。

这就是 confused deputy（被搞糊涂的代理人）攻击在多 agent 架构里的标准形态：低权限或被污染的下游 agent，借用上游传下来的高权限去做它本不该做的事。SEAgent 论文（arXiv 2601.11893，2026-01）系统地把 LLM agent 的权限提升路径分成五类：直接 prompt injection、间接 prompt injection（污染工具返回值）、RAG 投毒、confused deputy（多 agent 系统）、以及未授权第三方 agent 的越权操作——其中后两类正是子 agent 委托场景特有的。

[!warning] 全继承的本质全继承不是”偷懒的最小权限”，它是反最小权限：它让每一个子 agent 都暂时拥有了系统的最高权限，把单点风险默认提升为系统级风险。这与 A06 Orchestrator 编排器作为”权限层”的定位是直接冲突的。

§2 判断主轴：90% 的人在子 agent 权限上会搞错的四个点

这一节是本节点的命门——子 agent 委托里最容易踩、且后果最重的四个错位。

① 把”父能做的”等同于”子该做的”

症状：spawn 子 agent 时直接 token=parent.token，理由是”反正都是我这个系统内部的 agent”。
为什么会错：内部 ≠ 可信。子 agent 的输入（待总结的网页、检索回来的文档）来自外部不可信源，它随时可能被劫持。把它当可信内部组件，等于把信任边界画错了地方。
正确做法：每次 spawn 都做一次任务→scope 推导，子 agent 只拿这一步必需的最小工具集。父能调支付不代表”网页总结子 agent”该能调支付。
真实反例：2025 年记录的 Cross-Agent Privilege Escalation（跨 agent 权限提升，2025-09）正是利用了下游 agent 对上游传入权限的无条件接受（来源：WorkOS Blog，2026，关于 OAuth 多跳委托）。

② 委托链权限”平传”或”升级”，而非递减

症状：每一跳子 agent 拿到的 token 和父一样宽（平传），甚至因为”子任务要多调一个工具”而比父更宽（升级）。
为什么会错：递归委托链里只要有任意一跳不衰减，整条链的有效权限就等于其中最宽的那一跳。攻击者只需找到链上权限最宽、防护最弱的那个 agent。
正确做法：scope attenuation（权限递减）原则——每一跳子 agent 的权限必须严格 ⊆ 上游权限，禁止平级或升级传递。多篇 arXiv 论文（2501.09674、2510.26702、2604.02767）把这条列为防委托链提权的核心设计原则。
真实反例：RFC 8693（OAuth Token Exchange，正式 RFC）明确承认自身的局限——嵌套的 act claim（委托链记录）“仅供参考，不得用于访问控制决策”，即多跳授权链在标准层面无法被强制执行（来源：IETF Datatracker，2026-06-07 核实）。这意味着递减原则目前主要靠应用层自律，而非协议保证。

③ 委托链断裂导致审计无法归因

症状：子 agent 用父的凭证直接调工具，日志里只看到”父 agent 调用了 X”，看不到”是父委托给某子 agent、子代表用户 X 做的”。
为什么会错：当 agent A 委托 B、B 代表用户 X 调用工具 C，现有大多数框架回答不了”是谁的授权链导致了这个动作、在哪一跳违反了策略”。出了事无法定责，等于没有问责。
正确做法：保留双身份/多身份日志（agent 身份 + 用户身份 + 委托链同时记录）。Google Cloud Agent Identity 的设计就支持用户委托时的”双身份日志”（来源：Google Cloud 官方文档，2026-06-05 更新）。
真实反例：SentinelAgent（arXiv 2604.02767，2026-04-03）正是为解决这个问题提出”委托链演算”（Delegation Chain Calculus），定义 forensic reconstructibility（可取证重建）等属性——但它同时承认 intent preservation（意图保留）这条属性是概率性的，在复杂改写攻击下检测率会掉到 13%。这是个有边界的方案，不是银弹。

④ 把”意图”当成可随 token 一起传递的东西

症状：假设父 agent 授权子 agent 调某工具，就等于用户原本的意图也安全地传到了那次工具调用。
为什么会错：存在”意图不可传递性”（lack of intent transitivity）——没有任何密码学机制能把 agent 对工具的”理解”绑定到工具的实际行为，也没有标准能证明最终那次工具调用仍在用户最初授权的范围内（来源：arXiv 2510.25819，South 等，OpenID Foundation，2025-10-29）。委托链每多一跳，原始意图就被 LLM 重新解释一次，漂移一次。
正确做法：把授权绑定到具体任务/具体调用而非”系统访问权”。AIP 协议（arXiv 2603.24775，2026-03-25）提出的 Invocation-Bound Capability Token（IBCT，调用绑定能力令牌），用 Biscuit token + Datalog 策略把身份、递减权限、溯源合并进一条 token 链，正是为了让”权限”跟着”具体调用”走而不是跟着”agent 身份”走。

§3 产品 PM 视角补盲：不是只有工程耦合

工程上谈完委托链，PM 还要看三个常被工程视角漏掉的点：

用户心理模型错位：用户授权的是”帮我订一张机票”，不是”允许这个 agent 及其所有子 agent 在我账户里读写数据”。全继承模型把用户的”任务级心理授权”偷换成了”系统级技术授权”。产品上若不把这层差异显式化，用户的”同意”在法律与体验上都是无效同意。
确认疲劳的连锁放大：如果对每个子 agent 的每次越权都弹确认框，用户会被淹没。Anthropic 的共享责任模型数据显示，开发者在 93% 的权限提示弹窗中未经有效审查即点批准（来源：Backslash Security 对 Anthropic 共享责任模型的分析，2026-04-29）。这说明子 agent 的权限治理不能靠”每跳都问用户”，必须靠计划级治理（一次性批准一个有边界的执行计划）+ 默认最小化，把确认预算留给真正高副作用的动作。
合规归因要求：在受监管行业（金融、医疗），“谁做了这个动作、依据谁的授权”是硬性审计要求。委托链断裂直接导致不合规。FINOS 的金融业 AI 治理框架把 MI-18「Agent Authority Least Privilege」列为专门缓解项，要求 agent 权限最小化并可追溯。

§4 对手框架回应：全继承真的一无是处吗

业界反方立场（接受其合理内核）：一部分工程团队主张”逐跳最小化”在实践中开销过大——每次 spawn 都做语义 scope 推导会引入延迟和不确定性，且当任务需要多个 scope 时，基于 LLM 的”任务→scope”匹配准确率会明显下降（这是有实证的：arXiv 2510.26702，El Helou 等，2025-10-30，引入 ASTRA 数据集后发现多 scope 任务下匹配准确率下降）。他们的结论是：与其依赖一个概率性的权限推导器，不如给一个”够用就好”的中等权限集，靠运行时监控兜底。

接受的部分：他们对的地方在于——纯靠 LLM 做实时最小权限推导确实不可靠，把安全关键决策交给一个概率模型本身就是风险。逐跳最小化不能天真地等同于”让 LLM 每次现算”。

坚持的边界与赌注：但这不构成回到全继承的理由。我赌的是：最小权限的默认值必须是”窄”，扩展才需要审批——这正是 Progent（arXiv 2504.11703，伯克利等，v3 修订 2026-05-14）的核心机制：用 SMT solver 对策略变更分类，“收窄”自动批准、“扩展”需显式人工审批。它在 AgentDojo 和 ASB 基准上把攻击成功率降到 0%。也就是说，可靠的不是”让 LLM 推导权限”，而是”用确定性规则守住权限只能收窄不能扩张”。反方的有效批评只否定了前者，没有否定后者。这条边界会在两类场景失效：(a) 任务本质上就需要宽权限（如一个合法的”全库迁移” agent），此时最小权限退化为全权限，监控成为唯一防线；(b) 委托链跨越信任域时（详见 §2③），递减原则缺乏协议级强制，只能靠各域自律。

§5 跨域呼应：委托代理问题与”权力的可传递性”

经济学的委托代理问题（principal-agent problem）描述的是：委托人无法完全观察代理人的行为，代理人可能追求自己的目标而非委托人的利益，于是需要激励与监督机制来对齐。把它搬到 agent 委托链上，会改变我们对这个技术问题的判断：

传统 IAM 隐含一个假设——权限是一种可以安全地、无损地向下传递的东西（你有钥匙，你可以把钥匙给别人）。但委托代理理论提醒我们：每一次委托都伴随信息不对称的扩大和目标对齐的衰减。父 agent 无法完全观察子 agent 会拿这份权限做什么（信息不对称），而子 agent 的”目标”是被一段可能被污染的 prompt 临时定义的（目标不可靠）。

这就解释了为什么”全继承”在直觉上似乎无害（“都是我自己的 agent”）却在结构上危险：它假设了一个不存在的目标一致性。社会用”逐级授权 + 留痕 + 可追责”来管人类代理链（一个 CEO 不会把公司公章直接复印一份塞给每个临时工），agent 系统也必须用 scope 递减 + 委托链审计 + 可撤销 token 来做同样的事。权力的可传递性不是默认成立的公理，而是需要被工程显式约束的特例。这一视角也呼应了 0435 红队专题 S03（Agent 权限边界与最小权限设计，0435 专题 staging）提出的”权限是最后防线”——当注入已经发生，决定损失大小的就是当初委托下去的那份权限有多窄。

§6 PM 决策启示

面试怎么用：被问”多 agent 系统怎么做权限”时，不要答”配 RBAC”。答：“默认我会反对子 agent 全继承父权限，因为那是把权限提升变成默认行为、把爆炸半径从单点放大到全链。我会要求三件事：逐跳 scope 递减、委托链双身份审计、扩展权限需显式审批而收窄自动放行。“——这一句就把候选人从”会用工具”拉到”懂安全架构”。
选型怎么用：评估 A06 Orchestrator 编排器 / multi-agent 框架时，加一道硬性问题——spawn 子 agent 时是否支持逐任务下发 scope、且能保证 token 只能衰减不能扩张？ 若框架只能传一份全局凭证给所有子 agent，在高合规场景直接扣分。这是对 m208 - AI 基础设施与中间件选型编排框架对比里缺失的安全维度的填实。
复现怎么用：自己搭 multi-agent demo 时，刻意构造一条”网页总结子 agent 继承了支付权限”的链，注入一段恶意网页，观察它能不能调到支付——亲手看到 confused deputy 攻击成功，比读十篇论文都印象深。

§7 与已有节点的关系

对 0411 A06 Orchestrator 编排器：深化。A06 把 orchestrator 定位为任务调度 + 权限层，本节点把”权限层”这件事在”spawn 子 agent”这个具体动作上展开，给出 confused deputy 攻击形态与 scope 递减的具体设计判据。不复述 A06 对 orchestrator 角色的基础界定。
对 0411 A07 Multi-Agent Teams：补缺。A07 讲多 agent 协作的拓扑与分工，本节点补它未覆盖的”协作的安全代价”——agent 间的隐式信任正是 confused deputy 的温床。
对 0435 红队专题 S03（0435 专题 staging）：对话。S03 的”权限是最后防线”是总论，本节点是它在”委托链”这一特定场景下的分论，互为印证。
对本专题 A06 委托与代理（本专题同级节点）：互补。本节点聚焦”子 agent 继承”这个具体决策点，委托与代理节点处理更一般的 delegated authority 标准化问题。

§8 关联节点

核心（必读）

延伸（可选）

死链登记：本专题同级节点（A06 委托与代理、S03 Agent 权限边界等 0436 节点）尚未落盘，正文已降级为普通文本引用，并登记于 _待建概念清单.md。

修订日志

R0.1（2026-06-07）：首稿。建立”委托代理”框架定性，四点判断主轴（全继承=反最小权限、scope 递减、委托链审计、意图不可传递性），接入 Progent / SentinelAgent / AIP / RFC 8693 反方与边界，跨域呼应 principal-agent problem，链 0411 A06/A07 与 0435 S03。