概述

当 Agent A 代表用户 X 委派给 Agent B，Agent B 再调用工具 C——这条链路上信任如何传递？权限如何收窄？意图如何验证？2026年5月，Red Hat 发布重磅文章明确"委派胜过冒用"，IETF 推出 OAuth 2.0 AI Agent 扩展草案，Microsoft 开源 Agent Governance Toolkit，CoSAI 在 RSAC 2026 发布 Agentic IAM 框架，CSA 发布委派链安全指南，SentinelAgent 论文提出意图验证链证书。一条从身份冒用到零信任委派的产业共识正在形成，其核心是六层信任栈：身份绑定→作用域令牌→权限递减→意图验证→链式审计→运行时沙箱。本文拆解这六层的工程实现、已披露的攻击面与生产落地方案。

一、核心矛盾：冒用身份 vs 受托委派

当前绝大多数 Agent 框架采用冒用模式（Impersonation）：Agent 拿着用户的完整 Token 去调用 API，仿佛 Agent 就是用户本人。这在单 Agent 单工具时勉强可行，一旦进入多 Agent 委派链——编排器 Agent → 研究 Agent → 写码 Agent → 部署 Agent——冒用模式的三大致命缺陷立即暴露：

Red Hat 在2026年5月21日发文标题直截了当——"Zero Trust for AI Agents: Why Delegation Beats Impersonation"。核心论点：Agent 不应成为用户，而应作为独立身份，接收一组作用域明确的委托权限。这是零信任原则在 Agent 领域的自然延伸。

二、六层信任栈全景

graph TB
    subgraph L6["第六层：运行时沙箱"]
        S6["Microsoft AGT / Docker / gVisor"]
    end
    subgraph L5["第五层：链式审计"]
        S5["委派链完整日志 / 不可篡改追踪"]
    end
    subgraph L4["第四层：意图验证"]
        S4["SentinelAgent DCC / 意图对齐检查"]
    end
    subgraph L3["第三层：权限递减"]
        S3["Authority Narrowing / 每跳权限缩减"]
    end
    subgraph L2["第二层：作用域令牌"]
        S2["OAuth 2.0 OBO / AAP 协议 / Scoped Token"]
    end
    subgraph L1["第一层：身份绑定"]
        S1["Agent 独立身份 / CoSAI Agentic IAM"]
    end

    User["用户 X"] -->|"发起委派"| L1
    L1 -->|"颁发令牌"| L2
    L2 -->|"每跳缩减"| L3
    L3 -->|"验证意图"| L4
    L4 -->|"记录日志"| L5
    L5 -->|"沙箱执行"| L6
    L6 -->|"调用工具"| Tool["工具/API"]

    style L1 fill:#1a73e8,color:#fff
    style L2 fill:#34a853,color:#fff
    style L3 fill:#fbbc04,color:#333
    style L4 fill:#ea4335,color:#fff
    style L5 fill:#9334e6,color:#fff
    style L6 fill:#ff6d01,color:#fff

三、对比表格：六大委派链安全引擎

四、深度分析

4.1 第一层：身份绑定——Agent不再是影子

CoSAI（Coalition for Secure AI）在 RSAC 2026 发布的 Agentic IAM 框架提出了一个根本性区分：Agentic Identity ≠ Non-Human Identity（NHI）。传统 NHI（服务账号、API Key）是静态的、预定义的；而 Agent 身份是动态的、上下文相关的、可委派的。

核心概念是"三元绑定"：每个 Agent 的身份由三个维度定义——Who（代表哪个用户）、What（执行什么任务）、When（在什么时间窗口内）。这三元组构成 Agent 的身份证书，与传统的 Bearer Token 有着本质区别：Bearer Token 只回答"我能做什么"，三元绑定还回答"我为什么能做"。

# CoSAI Agentic IAM 三元绑定的伪代码表示
class AgentIdentity:
    principal: str        # WHO: 委托人 (用户 X)
    agent_id: str         # Agent 自身唯一标识
    task_scope: str       # WHAT: 任务意图描述
    validity_window: (datetime, datetime)  # WHEN: 时间窗口
    delegation_depth: int  # 委派深度 (防止无限递归)

    def to_claims(self) -> dict:
        return {
            "sub": self.agent_id,
            "act_as": self.principal,
            "scope": self.task_scope,
            "nbf": self.validity_window[0],
            "exp": self.validity_window[1],
            "del_depth": self.delegation_depth
        }

Strata Identity 在其分析文章中明确指出：将 Agent 归类为传统 NHI 是危险的简化。Agent 可以在运行时动态获得新权限、委派子任务、创建子 Agent——这些行为在传统 IAM 模型中完全没有对应概念。

变现潜力：Agentic IAM 咨询与实施正在成为企业安全团队的新刚需。一个典型的落地路径是：Agent 身份审计 → IAM 策略改造 → 委派链监控平台，客单价在 50-200 万区间。

4.2 第二层：作用域令牌——OAuth 2.0 的 Agent 扩展

IETF 在 2026 年发布了 draft-oauth-ai-agents-on-behalf-of-user-01，正式将 OAuth 2.0 Token Exchange（RFC 8693）扩展到 Agent 领域。核心创新是On-Behalf-Of（OBO）流程的 Agent 语义化：

传统 OBO 用于服务间调用（Service A → Service B），而 Agent OBO 需要表达更丰富的语义：谁委派了谁、委派了什么权限、委派了几层、期望的意图是什么。

WorkOS 在其技术博客中给出了 Agent OBO 的具体流程： 1. 用户 X 向编排器 Agent 颁发一个作用域令牌（Scoped Token），scope 限定为"读取日历" 2. 编排器 Agent 需要委派给"会议调度 Agent"时，通过 Token Exchange 换取一个新的下游令牌 3. 下游令牌的 scope 更窄——只有"查询空闲时段"，不包括"创建/删除事件" 4. 每次交换都记录委派链（delegation_chain claim）

AAP（Agent Authorization Profile）协议进一步扩展了 OAuth 2.0，引入了结构化 Claims 来描述 Agent 的身份、意图和作用域。AAP 的核心贡献是定义了 agent_intent claim——Agent 声明它打算做什么，而不仅仅是它能做什么。这使得授权服务器可以在颁发令牌时就进行意图层面的访问控制。

关键代码片段：

{
  "token_type": "Bearer",
  "access_token": "eyJ...",
  "scope": "calendar:read:freebusy",
  "claims": {
    "sub": "agent://scheduler-abc",
    "act": { "sub": "user://[email protected]" },
    "agent_intent": "query_free_busy_slots",
    "del_chain": [
      {"agent": "orchestrator", "scope": "calendar:read"},
      {"agent": "scheduler-abc", "scope": "calendar:read:freebusy"}
    ],
    "del_depth": 2,
    "exp": 1716518400
  }
}

4.3 第三层：权限递减——Authority Narrowing 原则

CSA 在其"Fixing AI Agent Delegation for Secure Chains"指南中提出了权限递减原则（Authority Narrowing Principle）：委派链中的每个 Agent 的权限必须严格小于等于其上游 Agent，理想情况下是严格小于。

这听起来简单，实现起来极其困难。主要挑战有三个：

挑战一：权限模型不一致。 Agent A 有"读写数据库"权限，委派给 Agent B 时需要拆解为"读数据库"。但 Agent B 又需要调用"发送邮件"这个 Agent A 本身没有的权限——这违反了权限递减原则，却可能是合法的业务需求。CSA 的解决方案是引入权限预算（Permission Budget）概念：每个 Agent 有一个总权限预算，委派时从预算中"支出"权限给下游，不能超支。

挑战二：动态权限膨胀。 Agent 在运行时可能通过工具调用获取新能力（比如安装新工具），这会导致超出初始委派范围的权限膨胀。Microsoft AGT 通过运行时策略引擎解决这个问题：任何新能力的获取都必须通过策略检查点。

挑战三：隐式权限通道。 两个 Agent 之间可能存在隐式的权限通道——比如共享的内存区域、环境变量、文件系统。ATR-2026-00074 规则描述了跨 Agent 权限升级的攻击方式：一个被攻陷的低权限 Agent 通过重写另一个 Agent 的配置文件来实现提权。

# 权限递减验证伪代码
def verify_authority_narrowing(delegation_chain):
    for i in range(1, len(delegation_chain)):
        parent = delegation_chain[i-1]
        child = delegation_chain[i]

        # 严格子集检查
        if not child.permissions.issubset(parent.permissions):
            raise AuthorityEscalationError(
                f"Agent {child.id} permissions {child.permissions} "
                f"exceed parent {parent.id} permissions {parent.permissions}"
            )

        # 预算检查
        spent = sum(c.permission_budget for c in delegation_chain[i:])
        if spent > parent.permission_budget:
            raise BudgetExceededError(
                f"Total child budget {spent} exceeds parent budget {parent.permission_budget}"
            )

4.4 第四层：意图验证——SentinelAgent 的 DCC 框架

SentinelAgent（arXiv:2604.02767）是 2026 年最引人注目的 Agent 委派安全论文。它提出了一个核心问题：当 Agent A 委派给 Agent B，Agent B 调用工具 C 代表用户 X——谁验证 B 的行为确实符合 X 的原始意图？

传统方案只验证"权限是否足够"，不验证"行为是否符合意图"。SentinelAgent 引入了委派链证书（Delegation Chain Certificate, DCC）：

DCC 的核心思想是每一步委派都生成一个意图证明，下游 Agent 必须证明其行为与上游意图一致才能获得执行授权。具体流程：

1. 用户 X 向 Agent A 表达意图："帮我安排下周和 Y 的会议"
2. Agent A 生成 DCC₁ = {intent: "安排会议", scope: "下周", participants: [X, Y], signed_by: X}
3. Agent A 委派给 Agent B 时，附上 DCC₁，并声明子意图："查询 Y 下周空闲时间"
4. Agent B 生成 DCC₂ = {parent: DCC₁, sub_intent: "查询空闲时间", scope: "Y的日历", signed_by: A}
5. Agent B 调用日历 API 时，出示 DCC₂ 链，API 网关验证：DCC₂ 的 sub_intent 是否是 DCC₁ intent 的合法细分

如果 Agent B 突然试图删除 Y 的日历事件，DCC 验证会立即失败——因为"删除事件"不是"查询空闲时间"的合法细分。

变现评估：DCC 框架目前仍是学术阶段，但其思想直接影响了 CSA 指南和 IETF 草案。预计在 2026 Q3-Q4 会出现首批商业化实现，切入方向是"委派链安全网关"——作为 Agent 框架与后端 API 之间的安全中间层。

4.5 第五层：链式审计——不可篡改的委派追踪

当安全事件发生时，最关键的问题是"谁通过什么链路做了什么"。链式审计层的核心是委派链的完整、不可篡改记录。

Microsoft AGT 在这一层提供了最完整的工程实现。其审计日志包含：

• 每次委派事件的完整上下文（谁→谁、权限范围、时间戳、意图声明）
• 每次工具调用的参数快照与返回值摘要
• 每次人工审批的决策记录
• 凭证使用与轮换事件

Okta 在其 Agent Session Smuggling 分析中揭示了一个重要攻击面：如果审计日志不包含委派深度信息，攻击者可以通过"会话走私"在链上某个节点注入额外的委派层，使恶意行为看起来合法。防护方案是在每次审计记录中嵌入委派链的 Merkle Root——任何链路的篡改都会导致 Root 不匹配。

# 链式审计的 Merkle 验证
import hashlib, json

class DelegationAuditNode:
    def __init__(self, delegator, delegate, scope, timestamp, parent_hash=None):
        self.delegator = delegator
        self.delegate = delegate
        self.scope = scope
        self.timestamp = timestamp
        self.parent_hash = parent_hash

    @property
    def hash(self):
        data = json.dumps({
            "delegator": self.delegator,
            "delegate": self.delegate,
            "scope": self.scope,
            "ts": self.timestamp,
            "parent": self.parent_hash
        }, sort_keys=True)
        return hashlib.sha256(data.encode()).hexdigest()

# 验证链完整性
def verify_chain(audit_nodes):
    for i in range(1, len(audit_nodes)):
        if audit_nodes[i].parent_hash != audit_nodes[i-1].hash:
            return False, f"Chain broken at node {i}"
    return True, "Chain intact"

4.6 第六层：运行时沙箱——Microsoft AGT 的七包防线

Microsoft 在 2026 年 4 月 2 日开源了 Agent Governance Toolkit（AGT），这是目前生产就绪度最高的 Agent 委派链安全方案。AGT 是一个七包 monorepo，MIT 协议：

AGT 的核心设计理念是"Hypervisor 模型"：AGT 作为 Agent 与外部世界之间的强制中间层，所有出站调用（工具调用、API 调用、Agent 间通信）都必须经过策略引擎检查。这类似于虚拟化中的 Hypervisor——Guest OS 无法绕过 Hypervisor 直接访问硬件。

关键特性： - 声明式策略 DSL：用 YAML 定义 Agent 的行为边界 - 实时权限收窄：运行时动态调整 Agent 的权限范围 - 委派深度限制：可配置最大委派层数，防止无限递归 - 人工审批网关：高风险操作触发人工审批流程

上手评估：从安装到第一个受管控 Agent 约 2-3 小时。需要 Docker 环境和基本的 OAuth 2.0 知识。适用场景是企业级 Agent 生产部署。

4.7 攻击面全景：已披露的委派链攻击

2026 年已披露的与委派链直接相关的攻击事件和漏洞：

CVE-2026-2256（MS-Agent）：ModelScope MS-Agent 框架中的命令注入漏洞。攻击者通过精心构造的 prompt 让 Agent 执行任意命令，因为 Agent 以用户完整权限运行（冒用模式）。CVSS 评分 9.8。这个漏洞是冒用模式危险性的完美例证——如果 Agent 使用受托委派模式且权限被限定为"查询模型库"，命令注入的影响范围将大幅缩小。

ATR-2026-00074（跨 Agent 提权）：一个被攻陷的低权限 Agent 通过重写另一个高权限 Agent 的配置文件来实现跨 Agent 权限升级。Johann Rehberger 在 2025 年 9 月首次披露了这一攻击模式，2026 年被正式收录为 Agent Threat Rule。防护方案是每个 Agent 的配置文件只能由创建者修改，且修改操作需要通过委派链验证。

Agent Session Smuggling：Okta 披露的攻击方式。攻击者在委派链的某个节点注入额外的委派层，使恶意行为隐藏在合法的委派链路中。核心原因是审计日志缺少委派深度信息。

权限预算耗尽攻击：Aviatrix 的 2026 企业安全报告中记录了一种新型攻击——攻击者通过大量微小的委派请求耗尽 Agent 的"权限预算"，迫使系统在权限预算耗尽后授予超出预期的权限（降级到冒用模式作为 fallback）。这暴露了一个设计缺陷：权限预算耗尽时的 fallback 策略不应是"放开权限"，而应是"停止执行"。

4.8 产业趋势：从分散方案到标准栈

2026 年 Q1-Q2 的产业动态呈现三条清晰的主线：

主线一：冒用模式正在被抛弃。 Red Hat、CSA、CoSAI 三大机构在 2026 年上半年同时发文强调委派优于冒用。这不是巧合——生产环境中的安全事件已经证明冒用模式不可持续。IBM 在 Think 2026 大会上将"Agent 身份"列为独立议题，Okta 发布了 Agent 专用安全指南。

主线二：OAuth 2.0 正在成为 Agent 委派的标准协议层。 IETF 草案、AAP 协议、WorkOS 方案都基于 OAuth 2.0 扩展。这意味着企业已有的 OAuth 基础设施可以复用，降低了落地门槛。但需要注意：传统 OAuth 实现通常不支持 del_depth、agent_intent 等 Agent 特有 claim，需要升级。

主线三：运行时治理与协议标准化正在融合。 Microsoft AGT 代表了运行时治理方向，IETF/AAP 代表了协议标准化方向。两者的融合点在于：协议层定义"应该怎样传递信任"，运行时层确保"实际传递过程不偏离"。预计 2026 年下半年会出现基于 AAP 协议的 AGT 插件。

五、委派链零信任架构图

sequenceDiagram
    participant User as 用户 X
    participant IAM as 身份服务
    participant Orch as 编排器 Agent
    participant Worker as 执行 Agent
    participant Policy as 策略引擎
    participant Tool as 工具/API
    participant Audit as 审计服务

    User->>IAM: 1. 委托请求（意图+范围）
    IAM->>IAM: 2. 生成三元绑定身份
    IAM-->>Orch: 3. 颁发 Scoped Token（scope=研究+写码）

    Orch->>Policy: 4. 请求委派（子意图=写码）
    Policy->>Policy: 5. 权限递减检查
    Policy->>Policy: 6. 意图验证（DCC）
    Policy-->>Orch: 7. 下游 Scoped Token（scope=写码）

    Orch->>Audit: 8. 记录委派事件
    Orch->>Worker: 9. 委派任务 + 下游Token

    Worker->>Policy: 10. 请求工具调用（git push）
    Policy->>Policy: 11. 策略检查（git push在范围内？）
    Policy->>Policy: 12. 委派深度检查（depth≤3？）
    Policy-->>Worker: 13. 授权通过

    Worker->>Tool: 14. 执行 git push（带完整DCC链）
    Tool->>Audit: 15. 记录执行结果
    Audit->>Audit: 16. 更新 Merkle Root
    Audit-->>User: 17. 异常告警（如有）

六、生产落地推荐

场景一：企业内部 Agent 平台（推荐 Microsoft AGT）

如果你们的企业已经或即将部署多个 Agent，AGT 是当前最务实的选择。七包结构提供了从身份到审计的完整覆盖，MIT 协议意味着没有许可证风险。建议先从 agent-policy 和 agent-sandbox 开始，将现有 Agent 包裹在策略引擎和沙箱中，再逐步引入身份管理和审计。

场景二：SaaS 产品中的 Agent 功能（推荐 OAuth 2.0 OBO + AAP）

如果你的产品需要让用户的 Agent 调用你的 API，IETF OAuth OBO 扩展和 AAP 协议是正确的协议层选择。实现路径：先在 Token 颁发时增加 act claim 和 agent_intent claim，再在 API 网关层增加委派深度和意图验证逻辑。

场景三：高安全场景（推荐 SentinelAgent DCC + 零信任网络）

对于金融、政务、军事等高安全场景，权限递减和意图验证缺一不可。SentinelAgent 的 DCC 框架虽然目前只有学术论文，但其核心思想可以自行实现：在每次委派时生成意图证明，在每次工具调用时验证意图链完整性。结合零信任网络（如 Red Hat 推荐的 SPIFFE/SPIRE），可以实现从网络层到应用层的全栈零信任。

场景四：快速原型验证（推荐 CSA 指南 + 手动实现）

如果是小团队或 PoC 阶段，直接实现 CSA 指南中的"权限递减原则"即可。核心就三步：每个 Agent 有自己的 scope、委派时 scope 必须严格缩减、所有委派操作写入审计日志。不需要复杂的框架，一个 Python 装饰器就能实现基本的权限递减检查。

七、核心洞察

委派链零信任不是"Agent 安全"的一个子话题，而是 Agent 进入企业生产的必经门槛。 就像微服务架构中的服务间认证（mTLS）不是可选的装饰品，Agent 间的委派信任也必须从第一天就内置。2026 年上半年的产业共识已经形成：冒用模式是技术债，受托委派是正道。六层信任栈给出了从身份到沙箱的完整路线图——关键是不要试图一次实现全部六层，而是根据你的场景选择合适的起点，逐层叠加。

参考来源

1. Zero Trust for AI Agents: Why Delegation Beats Impersonation — Red Hat — Red Hat 2026年5月最新文章，阐述委派模式优于冒用模式的核心论点与权限继承模型
2. SentinelAgent: Intent-Verified Delegation Chains — arXiv — 提出 DCC 委派链证书框架，解决多 Agent 委派中的意图验证问题
3. Fixing AI Agent Delegation for Secure Chains — CSA — CSA 安全联盟发布的 Agent 委派链安全指南，定义权限递减原则
4. Microsoft Agent Governance Toolkit — GitHub — 微软开源的七包 Agent 运行时治理框架，MIT 协议
5. OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents — IETF — IETF OAuth 2.0 Agent 委派扩展草案
6. CoSAI Agentic Identity and Access Management — Coalition for Secure AI — RSAC 2026 发布的 Agentic IAM 框架
7. ATR-2026-00074: Cross-Agent Privilege Escalation — Agent Threat Rule — 跨 Agent 权限升级攻击的正式威胁规则
8. Zero Trust Authorization for Multi-Agent Systems — Deepak Gupta — 多 Agent 系统零信任授权技术指南

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。