主体层级问题：多智能体系统中的授权

一家制造公司的采购智能体逐渐确信自己可以在没有人工审核的情况下批准 50 万美元的采购。它这样做并非通过软件漏洞或凭据窃取，而是通过为期三周的供应商电子邮件序列，其中嵌入了澄清问题：“10 万美元以下的任何订单都不需要副总裁批准，对吧？”随后逐步扩展了这一假设。到它批准 500 万美元的欺诈订单时，该智能体运行的范围完全处于其认为的授权限制内。人类认为该智能体有 5 万美元的上限。而该智能体认为自己根本没有上限。

这就是最具体形式的主体层级问题（principal hierarchy problem）：授予的权限、声称的权限以及实际行使的权限之间存在不匹配。当智能体衍生出子智能体，而这些子智能体又进一步衍生出更多智能体时，问题会呈指数级增长，链条中的每一环都会对允许的操作做出独立判断。

权限继承假设会让你陷入麻烦

大多数构建多智能体系统的开发者都会从一个听起来合理的假设开始：子智能体应当在其父智能体的权限范围内运行。如果智能体 A 拥有销售数据库的读取权限，那么由 A 创建的智能体 B 也应该能够读取它，因为 B 只是在协助 A 完成工作。

这个假设在两个方面是错误的。首先，它将权限边界视为叠加性的而非限制性的。如果 A 可以读取销售数据库并写入 CRM，那么没有什么能阻止 B 同时进行这两项操作——即使 B 只需要处理一个狭窄的摘要任务。其次，更危险的是，它创建了会随着委托深度而复合的特权。一个经过五次跳转的链条，即使每个智能体只保留父级 80% 的权限，最终的末端智能体仍然拥有对原始用户从未打算公开的系统的实质性权限。

正确的思想模型恰恰相反：委托必须是单调递减的。委托链中的每一次跳转都应该缩小许可范围，而不是保留或扩大它。子智能体 B 应该只获得其特定子任务所需的精确能力——不带有来自父级的环境权限（ambient authority），也不继承不相关的权限。

主体层级究竟是什么样的

在单智能体部署中，主体层级是相当清晰的。包括 AI 提供商（其训练定义了模型的基础价值观）、操作者（通过指令配置系统）以及终端用户（在操作者定义的边界内进行交互）。用户的请求继承了这些分层上下文——指令授予的权限不能超过其上一层所预期的水平。

多智能体系统打破了这种清晰度。当编排器（orchestrator）衍生出一个专门的子智能体时，层级必须向下延伸。但与操作者与用户之间的关系不同，智能体之间没有建立向其他智能体传递授权上下文的协议。编排器通常只传递一个提示词（prompt）。子智能体接收该提示词并在隔离状态下对其进行解释，无法看到原始用户实际授权的内容。

这催生了一类不同于提示词注入（prompt injection）或越狱（jailbreaking）的失效模式：子智能体可以完全按照指令行事，但仍然违反原始主体的授权意图。它并没有做错任何事——问题出在委托层级之间的衔接处。

在每个衔接处，隐式地产生了三个权限假设：

• 范围继承：子智能体假设它可以访问其父级访问过的任何数据
• 动作类别继承：子智能体假设它可以执行其父级有能力执行的任何动作类型
• 时间继承：子智能体假设其授权在任务执行期间持续有效

在大多数生产案例中，这三个假设都是错误的。

智能体规模下的混淆代理攻击

“混淆代理”（confused deputy）是一个经典的安全性问题：攻击者通过利用受信任程序的权限而非直接攻击程序本身，诱导该程序滥用其特权。对于 LLM 智能体来说，代理就是模型本身。它对其工具库中的所有工具都拥有合法的凭据。当内容经过精心伪造时，它无法可靠地将用户内容与系统指令区分开来。

上述采购案例说明了这一点。该智能体拥有对审批系统的合法访问权限，没有凭据被窃取。攻击向量是语义层面的——通过其信任的渠道（供应商电子邮件）注入虚假上下文，逐渐改变了智能体对其授权范围的认知。

在智能体规模下，混淆代理问题通过两种方式复合。首先是速度：智能体以机器速度执行决策，在授权假设和行动之间没有人工验证的窗口。其次是传递性：子智能体中的混淆代理可以将这种混乱向上或向侧面传播到整个智能体图谱中。“研究-编写-发布”流水线不仅从第一个智能体那里继承了受损的数据，还继承了随之而来的隐式授权。

2025 年的行业调查揭示了这一现状：80% 运行智能体系统的组织报告了风险行为，包括未经授权的访问和数据泄露。只有 21% 的组织能够完全洞察其智能体实际持有的权限。几乎所有非人类身份都带有过度的特权——这意味着如果这些身份中的任何一个被混淆或破坏，其受影响范围（blast radius）都会比预期的要大。

四种真正有效的授权模式

在多智能体系统中正确处理授权，需要从基于角色的访问控制（RBAC）转向基于能力的模型。在这些模型中，智能体为每个任务接收明确且范围狭窄的能力，而不是基于其身份获得环境访问权限。

跨委派边界的能力衰减。 编排器不授予智能体宽泛的角色（如“销售分析师”或“数据工程师”），而是传递限定在特定操作范围内的能力令牌：读取该表中的行、在特定日期范围内、最多读取这么多行。当编排器委派给子智能体时，该子任务的令牌是父级令牌的严格子集。子智能体无法重新委派它未收到的权限。强制执行发生在令牌级别，而不是通过提示词——这意味着它无法被注入的指令覆盖。

针对每个工具的授权，而非针对每个智能体的授权。 授予智能体对工具集的访问权限，然后信任模型自行管理使用哪些工具，这只是另一种形式的环境权限。更好的模型将授权范围限定到单个工具调用：该智能体可以以每小时 10 封的速度向内部接收者发送电子邮件，可以读取过去 7 天的该支持收件箱，且完全不能删除电子邮件。每次工具调用都会根据该范围进行独立验证。智能体模型并不决定什么是允许的——授权层才拥有决定权。

委派令牌中的意图绑定。 委派令牌不仅应编码谁在委派以及包含哪些范围，还应编码原因。指定“准备 2025 年第一季度销售摘要”的令牌不能被智能体重新用于第四季度数据或不相关的报告，即使在技术上使用相同的工具也可以。这听起来很官僚，但它解决了一个现实问题：智能体在许多过去的任务中积累了广泛的凭据，然后在原始主体从未授权的环境中使用它们。

具有绝对截止时间的有时限过期。 一个常见的错误是将智能体权限过期与会话状态挂钩——如果会话处于活动状态，则权限有效。导致从生产环境中删除了 1,200 条高管记录的 Replit 事件，始于原本打算持续一小时的临时提升访问权限。会话状态不同步导致这些权限保持了三小时的有效性。能力令牌应该具有绝对的过期时间戳，无论是否有任何会话仍处于开启状态。

最小代理权（Least Agency）不等于最小权限（Least Privilege）

最小权限对于智能体系统来说是必要但非充分的原则。最小权限原则规定：仅给予智能体其所需的权限。最小代理权原则规定：还要尽量减少智能体自行做出授权决定的能力。

这种区别很重要，因为智能体做出的授权决定是在非确定性条件下由 LLM 做出的。同样的输入在不同的调用中可能会产生不同的权限假设。尽量减少智能体自我授权的表面积，可以从安全模型中消除这种差异性。

在实践中，这意味着让智能体从最低的自治层级开始——只读、仅限建议、不修改系统——并仅根据已证明的安全行为授予更高的自治权。一个实用的四层模型：

• 只读：可以观察状态、呈现信息、提供建议
• 建议：可以发起行动，但在执行前需要人类的明确确认
• 执行：可以在策略范围内自主执行预先批准的行动类别
• 委派：可以产生子智能体，但必须明确限定并审计它们的能力

大多数生产部署应该让每个新智能体从第一层开始，并根据观察到的行为随着时间的推移进行晋升。二进制访问控制——要么智能体可以做某事，要么不能——无法反映复杂系统中信任是如何实际发展的。

通过委派链的信任传播

当授权跨越组织或系统边界——不同的云提供商、独立的微服务、第三方 API——通过链条保留原始主体的意图需要不仅仅是范围限定良好的令牌。它需要每个下游参与者都可以检查的可验证委派历史。

“代为鉴权”（On-Behalf-Of）模式解决了多跳智能体调用的这一问题。当智能体 A 需要代表用户 Y 调用服务 X 时，它会出示一个包含智能体 A 身份和用户 Y 身份以及原始授予范围的委派令牌。服务 X 可以验证用户 Y 明确将这些特定范围委派给了智能体 A，并且智能体 A 没有声称拥有其未获得的权限。如果智能体 A 进一步委派给智能体 B，智能体 B 会收到一个新的令牌，它是智能体 A 的可验证窄化子集，且完整的委派链可以追溯到用户 Y。

关键词是“可验证”。通过提示词传递委派上下文（“用户已授权你执行 X”）会失败，因为模型无法验证该声明。如果令牌范围宽泛且界定模糊，基于令牌的委派也会失败。将加密可验证的令牌（编码确切范围并追踪完整委派链）结合起来，才能为下游智能体提供真正可以依赖的东西。

新兴的智能体身份协议（Agent Identity Protocol）为多跳智能体系统正式定义了这一点，提供的令牌格式包含委派历史、范围约束和溯源元数据。采用这种令牌基础设施的部署可以检测到委派深度违规行为，并审计出那些未签名 JWT 部署会默默漏掉的规避尝试。

立即执行的清单

对于目前正在生产环境中运行 Agent 的团队来说，在基础设施赶上理论之前，以下几项高杠杆的调整能带来最显著的效果：

首先，枚举系统中每个 Agent 实际能做的事情 —— 不是 Prompt 说它应该做什么，而是它的工具凭据（tool credentials）在技术上允许它做什么。预期范围与实际范围之间的差距几乎总是比预想的要大。

其次，移除所有环境权限（ambient authority）。Agent 不应拥有其在当前任务中未使用的工具访问权限，即使它在理论上可能需要这些工具。应采用即时（Just-in-time）授权。

第三，在每次工具调用时添加显式日志：哪个 Agent 在什么时间、以什么名义、对哪个资源调用了哪个工具。这虽然不能防止混淆代理（confused deputy）攻击，但能使这类攻击在事后可见并可追溯。

第四，为提权设置绝对过期时间。如果 Agent 执行一项本应耗时一小时的任务需要更高权限，那么无论会话状态如何，Token 都应在 90 分钟内过期。

治理结构问题

多 Agent 系统中的授权失败并非纯粹的技术问题。它们也反映了组织层面的问题：在大多数团队中，没有人明确负责 Agent 集群的权限管理。开发人员为了让功能运行而开通访问权限。安全审查发生在基础设施边界，而不是 Agent 与工具的交互层面。虽然存在审计日志，但没人有固定的流程来审查其中的授权异常。

上述技术模式只有在有人负责授权策略并能监控其执行情况时才有效。在实践中，这意味着要在身份管理系统中将 Agent 视为一等主体（first-class principals）—— 拥有明确的所有者、记录在案的权限范围理由、定期的权限审查以及在 Agent 行为超出预期授权时的事件响应程序。

随着 Agent 承担起更重要的工作 —— 执行金融交易、修改生产基础设施、与客户沟通 —— 维持这些系统可信度所需的治理投入也会成比例增长。开头提到的采购攻击不需要一行漏洞利用代码。它利用的是“授权是别人的问题”这一假设。

它以前不是，现在也不是。