谁授权了？多智能体AI中的委托问题

你的AI智能体预订了会议、总结了财务报告，并将要点通过电子邮件发送给了三位利益相关者。为此，它调用了日历智能体、文档分析智能体和邮件智能体。每个智能体都访问了内部系统，做出了关于包含哪些内容的决策，并代表你采取了行动。

你的安全团队无法回答的问题是：谁授权邮件智能体读取那份财务报告？在大多数当前架构中，诚实回答是：没有人明确授权。日志可能显示某个服务调用了另一个服务，但无法证明委托本身是被授权的。授权并没有响亮地失败，而是悄然通过链泄露。

这就是多智能体AI中的委托问题。随着企业通过MCP和A2A等协议连接智能体，它们解决连接问题的速度远快于解决权限问题的速度。结果是一个新的安全边界，大多数企业架构尚未建模，因为大多数组织仍然将其视为编排而非授权。

智能体的连接速度超过了授权的适应速度

过去两年，智能体生态系统发展迅速。Anthropic的MCP为模型驱动的应用程序提供了连接工具、数据源和服务的标准方式。谷歌的A2A协议为智能体提供了跨系统通信和协调的标准方式。LangChain、CrewAI和谷歌的ADK等框架和SDK使构建一个智能体编排多个其他智能体的多智能体工作流变得更加容易。

这些协议尚未提供（至少作为一个成熟的通用层）的是一个委托感知的授权模型。

MCP将受保护的服务器描述为OAuth 2.0资源服务器，MCP客户端作为代表资源所有者发出请求的OAuth客户端。这是一个熟悉且易于理解的模式，但它是为人类点击“允许”且单个客户端获得作用域令牌的世界设计的。它没有解决当智能体A收到该令牌、将子任务委托给智能体B、然后智能体B产生智能体C处理部分任务时会发生什么。链中的每一跳要么重用原始令牌（权限过大），要么根本没有令牌（无法追踪）。

A2A是为了互操作性而构建的：独立的、可能不透明的智能体系统在企业平台上通信和协调行动。这是正确的问题。但通信和委托治理是不同的层次。A2A帮助智能体发现、描述和相互通信。这是必要的基础设施，但不等同于委托权限。它无法告诉你某个特定下游操作是否合法地源自上游指令。

静态API密钥对于这个问题甚至更弱。密钥授予对服务的访问权限，但没有说明谁在使用它、用于什么目的，或者出示密钥的实体是否与颁发给它的实体相同。服务账户标识一个工作负载，而不是一个意图。当三个智能体共享一个服务账户时，每个操作在你的日志中看起来都一样。

这些工具都没有坏。它们解决不同的问题。差距是结构性的。身份验证回答是哪个智能体在调用。授权定义该智能体可以访问什么。更难的问题（也是大多数企业架构尚未设计来回答的）是：某个特定下游操作是否合法地源自上游指令，在缩小的约束下，具有可验证的链回溯到人类决策。这就是委托问题，它位于当今堆栈中尚未存在的层次。

在这种情况的干净版本中，权限应该只属于与外部世界接触的智能体。如果付款人（A）要求簿记员智能体（B）进行支付，而簿记员要求银行智能体（C）执行转账，那么只有银行智能体需要银行权限。簿记员不需要移动资金。它只需要知道请求来自授权的付款人。银行智能体只需要知道请求来自授权的簿记员。这是最小权限原则（安全社区已经实践了几十年）应用于委托链。困难在于，当今的智能体堆栈使得强制执行变得困难。

链中出了什么问题

考虑一个受监管银行中的财务报告工作流。一个规划智能体被允许读取流动性预测并为高级财务用户生成每日摘要。为了完成任务，它将图表生成委托给可视化智能体，将叙述审查委托给通信智能体。可视化智能体不需要访问原始账户级数据。通信智能体不需要访问底层流动性模型。然而，除非委托层衰减权限，否则两者都可能接收到比任务所需更多的上下文。结果不是戏剧性的泄露，而是访问的悄然扩展，访问控制模型从未明确批准过。

风险不仅限于面向互联网的智能体。许多委托失败完全发生在企业边界内部。一个内部智能体可能调用另一个内部智能体，后者调用一个内部工具，该工具将数据发送到批准的SaaS服务。每个单独的步骤看起来都可以接受。风险出现在组合中：最终的数据移动或操作可能超出原始授权的意图。

这种模式产生了三类可能迫使企业向监管机构、审计师或客户解释的失败。

幽灵权限。一个财务分析师助手被授予访问客户交易数据库的权限以支持季度报告。它调用一个摘要智能体：“总结这些账户的近期交易。”摘要智能体现在对客户记录进行操作，尽管没有策略引擎授予它该访问权限。分析师助手的权限有效地随请求传播。权限是幽灵——在实践中存在，但在任何授权系统中都不存在。

作用域漂移。即使智能体开始时具有狭窄的权限，委托也倾向于扩大而非缩小范围。一个被授权读取第一季度收入数据的智能体委托给一个图表智能体，图表智能体调用一个外部渲染API，该API现在拥有收入数据。数据通过三跳隐式信任离开了组织。每个智能体都在其理解的作用域内行动。汇总结果超出了任何人类会批准的范围。

破碎的审计追踪。受监管行业需要能够回答“谁做了什么以及为什么”对于任何重要行动。在单智能体系统中，这是可管理的。在多智能体链中，审计追踪碎片化地分布在智能体、协议和服务之间。当合规团队询问为什么发送了某个特定客户通信时，答案可能涉及两个协议中的四个智能体，没有一个记录了委托链。行动可追溯到系统，但不可追溯到决策。

这些不是边缘情况。它们是当委托没有被显式建模时的常见结果。委托问题不是任何特定框架中的错误。它是它们之间层中的空白。

委托感知模型需要什么

一个委托感知的授权模型必须同时解决四个问题，这也是为什么没有现有层能干净地覆盖它的部分原因。

第一个是身份。下游智能体需要一个接收系统可以独立验证的加密凭据，而不仅仅是主机名或API密钥。主机名可能说谎。API密钥会传播。真实身份是调用系统无法伪造的。

第二个是衰减。当一个智能体委托任务时，子智能体应获得严格少于父智能体的权限——绝不能相同，当然也不能更多。这是应用于委托链的最小权限原则，几乎没有任何现有工具默认强制执行。

第三个是目的。“读取这份报告以总结流动性风险给CFO”与“读取这份报告并将选定数据发送给外部图表服务”是不同的授权。可能是相同的数据和相同的智能体，但它们是两个截然不同的风险概况。没有目的绑定，授权层无法区分它们。

第四个是审计。组织应该能够在事后重建谁委托了什么、在哪些约束下、每个智能体在完成时产生了什么证据。不仅调用了哪些系统，而且做出了哪些决定以及基于谁的权威。

智能体即使没有可问责的权威也可以成功认证。它们可以证明自己是谁，但仍然执行从未经人类授权的操作。

新兴方法

有几项努力解决了这个问题的部分：工作负载身份标准、令牌中的智能体元数据、基于OAuth的MCP授权、A2A认证模式以及智能体身份框架。这些都是有用的构建块，但身份不等于委托权限。签名的智能体卡片可以帮助建立智能体的声明身份和能力。OAuth令牌可以告诉你客户端可以访问什么。两者本身都不能证明特定下游操作是由特定上游决策在缩小的约束下授权的。

一种新兴模式是委托绑定能力令牌：短期凭据，将调用绑定到智能体身份、受约束的权限集和来源记录。一个例子是Agent Identity Protocol（AIP），我一直在互联网草案和开源实现中工作。AIP仍然早期，但它说明了可能答案的形状：调用绑定的令牌，携带身份、衰减的权限和通过委托链的来源。令牌链本身成为审计证据的一部分，而不是事后从碎片化日志中重建。

补充方法也在出现。行为凭据——智能体应根据运行时行为而不是仅初始权限不断被重新授权的想法——解决了一个相关但不同的问题。委托令牌告诉你谁授权了什么。行为监控告诉你智能体是否仍在行动在其授权的配置文件内。完整的解决方案可能两者都需要。

这些方法都没有达到主流采用。但它们同时从行业不同角落出现的事实表明，委托差距是真实且被认识的。

企业团队现在应该做什么

你不需要等待标准成熟再解决委托问题。安全、平台和架构团队今天可以采取具体步骤。

绘制你的委托链。大多数部署多智能体工作流的团队没有记录哪些智能体调用哪些其他智能体、具有哪些权限、通过哪些协议。从那里开始。如果你不能画出图，就无法保护它。

审计隐式权限。对于每个智能体到智能体的交互，问：这个访问是明确授予的，还是下游智能体通过邻近性继承权限？如果答案是继承，你就有一个幽灵权限，需要策略决策。

要求作用域衰减。建立一个架构规则：当一个智能体委托任务时，子智能体必须获得少于父智能体的权限，绝不更多。当前工具不会自动强制执行这一点，但可以在你的编排层中强制执行。

在审计师询问之前建立审计追踪。如果你的组织在受监管行业，问题“谁授权了这个智能体行动？”最终会被问到。在问题到来之前就装备委托日志记录，而不是之后。记录完整链：哪个智能体发起了任务，每个步骤中的权限是什么，以及人类最终如何负责。