OWASP ASI03 解析:AI Agent的身份与权限

zealynx 发布于 2026-06-10 阅读 75

OWASP ASI03(身份和权限滥用)是OWASP 2026年AI Agent应用Top 10中的第三项,涵盖AI Agent因缺乏独立身份治理而导致的权限滥用、未授权委托或跨边界访问。真实案例包括Asana MCP跨租户绕过(2025年6月)和CVE-2025-49596(MCP Inspector因机制)以及多个MCP服务器继承开发者UID和凭据的重复模式。缓解措施要求独立的代理身份、范围限定的委托以及每次权限转换时的显式授权,而非“代理继承了我的会话,这没问题”。

TL;DR

  • OWASP ASI03("身份与权限滥用")是 OWASP Agentic 应用 Top 10 (2026 版) 中的第 3 项。它涵盖了因 AI Agent 缺乏独立的身份治理而导致的攻击,包括权限误用、未授权的委托或跨边界访问。
  • 当 Agent 在用户或租户之间共享身份、当工具继承过多主机权限、当委托链未被审计、以及当认证机制将"本地连接"等同于"已认证主体"时,就会触发此类风险。
  • 真实世界中 ASI03 事件包括 Asana MCP 跨租户访问绕过(2025 年 6 月)、CVE-2025-49596(MCP Inspector) 的机制层面问题,以及一种反复出现的模式——MCP 服务器以开发者完整 UID 和凭据存储运行。
  • ASI03 与 ASI02(工具误用) 在权限过高的工具方面存在重叠,也与 ASI04(Agentic 供应链) 在连接器导入其安装者身份方面存在重叠。但修复层次不同。
  • 缓解措施要求使用独立的 Agent 身份、限定范围的委托,以及在每次权限转换时进行显式授权——而不是"Agent 继承了我会话,没关系"。

ASI03 实际内容

OWASP ASI03 指出了 AI Agent 在没有适当治理的情况下使用、共享或升级身份与权限的威胁类别。标准表述:Agent 越来越多地被授予对真实系统(文件系统、网络、凭证、签名密钥、链上资产)的权限,而在生产部署中对这种权限的建模往往不足。Agent 默认继承用户身份,它们在多用户上下文中共享会话 Token,它们委托给子代理却不记录委托关系,它们跨越底层系统本应隔离的租户边界。

该类别下的三种主要失败模式:

跨用户共享身份。 多租户 Agent 平台在不同用户之间共享连接状态、缓存 Token 或上下文——导致用户 A 的权限渗入用户 B 的会话。Asana MCP 跨租户案例是典型例子。

继承主机权限。 MCP 服务器以主机的 UID、环境变量和凭据存储运行。因此 Agent 的实际权限是所有工具权限与主机完整身份的并集。操作者原本以为只授予了工具一组狭窄的能力,但实际情况往往不为他们所知。

隐式委托。 Agent 以自身持有的相同权限调用子 Agent、子工具和外部服务,却不记录委托链。审计变得不可能,因为无论链中哪个 Agent 实际决定采取该操作,每个操作看起来都像来自同一个身份。


真实世界的 ASI03 事件

根据 MCP 安全事件索引 2025–2026,2025–2026 年披露的事件记录中包含几项完全符合 ASI03 的发现:

Asana MCP 跨租户访问绕过(2025 年 6 月)

Asana MCP 服务器的工具权限过于宽泛:单个连接可以读取原本应在工具层面隔离的多个租户边界。这是教科书式的 ASI03 案例——身份治理失效,因为 Agent 继承了跨越客户边界的权限。修复措施是在服务端缩小范围,但一个架构设计良好的主机本应独立于连接器的声明,强制实施按租户的身份治理。

CVE-2025-49596(MCP Inspector,机制层面)

MCP Inspector RCE 详细分析 中描述的 Anthropic MCP Inspector 漏洞,从影响(RCE)来看主要是 ASI05 的发现,但其机制则纯粹是 ASI03:Inspector 将"本地网络连接"视为认证,混淆了可达性与身份。每个遵循本地网络信任假设模式的 CVE 都包含 ASI03 的成分。

继承开发者凭据模式(多个)

在已披露的 CVE 记录中,反复出现的一种模式是 MCP 服务器以开发者 UID 运行,并继承其 Git 凭据、AWS Token、签名密钥和活动会话 Token。因此,任何此类服务器中的 RCE 都会同时造成凭据泄露和等同于操作员的执行权限。这不是单个 CVE——而是结构性的 ASI03 失败,它使得 RCE 类 CVE 比在良好隔离部署中严重得多。


为什么 MCP 使 ASI03 更糟

MCP 架构的三种特性放大了 ASI03 风险:

通过 STDIO 创建的服务器默认继承主机身份。 官方 MCP SDK 创建子进程,这些子进程共享主机的 UID、环境和文件系统权限。连接服务器的操作者通常没有意识到他们授予了服务器完整的主机身份,而不是一个范围限定的工具权限。

跨服务器连接共享。 当多个 MCP 服务器连接到同一个 Agent 主机时,它们经常共享会话状态、缓存 Token 和配置上下文。一个服务器权限的泄露可能通过共享上下文渗入另一个服务器。

隐式的用户级身份。 大多数 Agent 运行时没有区分"Agent 代表用户行事"和"Agent 以用户身份行事"。两者在操作上截然不同——第一种是应被审计和约束的委托;第二种是绝不应发生的身份共享。


检测与缓解

防御 ASI03 需要在每次权限转换时实施显式的身份治理。以下四个运营控制措施涵盖了已披露的事件记录:

  1. 独立的 Agent 身份。 Agent 应拥有与用户不同的独立身份。工具授权的是 Agent 的身份,而不是用户的身份。当 Agent 的操作影响用户数据时,这种访问应是一种可撤销、可审计、范围限定的委托。

  2. 受限的主机继承。 MCP 服务器应仅具备所需的最小凭证和环境。使用专用 UID、限定范围的环境变量,默认不继承 Git Token 或凭据存储。例外情况(开发者明确希望服务器使用其凭据)应显式声明、限定范围并记录。

  3. 显式的委托记录。 每次调用子 Agent、每次工具调用、每次外部 API 调用都应记录身份链。谁决定采取此操作?基于什么权限?在 Agent 推理的哪个环节?

  4. 主机级别的按租户身份。 多租户部署应在主机级别强制实施租户隔离,而不是信任连接器的声明。Asana MCP 绕过本可以被主机级别的按租户身份治理所阻止,无论服务器自身如何实施。

对于 Web3 部署,规则是无条件的:持有交易签名权限的 Agent 必须拥有与用户不同的身份,并且每次签名操作都必须记录委托链。将"Agent 曾因用户一次授权而签名"视为持续授权,是一种 ASI03 失效,会在 Agent 首次被劫持时导致资金损失。


Zealynx 如何审计 ASI03

Zealynx 的 MCP 安全审计 将 ASI03 视为身份治理审计。五项重点测试:

  1. 身份图谱枚举。 对于部署中的每个角色(用户、Agent、子 Agent、工具、MCP 服务器),它持有什么身份?该身份授予什么权限?
  2. 权限继承审计。 对于每个 MCP 服务器和连接的工具,它实际从主机继承了哪些权限?操作者是否知晓?
  3. 委托链追踪。 对于一组代表性的 Agent 操作,审计追踪能否重建谁决定、基于什么权限、在哪个环节?
  4. 多租户边界测试。 在多租户部署中,单个连接能否跨越底层系统本应隔离的租户边界进行读写?
  5. 认证 vs 可达性测试。 对于每个本地端口、IPC 通道或信任假设面,"可达性"是否被等同于"认证"?

发现结果会映射到 ASI03 及相关下游条目。


常见问题

  1. 用一句话概括 OWASP ASI03 是什么?

    OWASP ASI03(身份与权限滥用)是 OWASP Agentic 应用 Top 10 中的第 3 项,涵盖 AI Agent 缺乏独立身份治理的攻击——在用户或租户之间共享身份、继承过多主机权限、未经审计的隐式委托,或将"本地连接"等同于"已认证主体"。

  2. 哪些真实世界的事件符合 ASI03?

    MCP 安全事件索引 2025–2026 中记载的 ASI03 事件包括 2025 年 6 月的 Asana MCP 跨租户访问绕过(典型的多租户身份失效)以及 CVE-2025-49596(MCP Inspector)的机制层面(将"本地网络连接"视为认证)。此外,广泛存在于以开发者 UID 运行的 MCP 服务器中的继承开发者凭据模式,是一种反复出现的结构性 ASI03 失效,使得 RCE 类 CVE 显著恶化。

  3. 为什么 MCP 服务器通常以开发者凭据运行?

    MCP 服务器通常以开发者凭据运行,因为官方 MCP SDK 通过 STDIO 传输创建子进程,默认继承主机的 UID、环境变量和凭据存储。安装服务器的操作者通常没有意识到他们授予了服务器完整的主机身份,而不是限定的工具权限。修复措施需要显式配置以约束服务器环境——例如专用 UID、限定环境变量、不自动继承 Git Token 或 AWS 凭据。

  4. ASI03 与 ASI02(工具误用)有何不同?

    ASI02 关注运行时工具的使用——权限过高的工具、模糊的描述符、不安全的组合。ASI03 关注身份——Agent 是谁、工具认为它是谁、该身份授予了什么权限。它们在权限过高的工具上重叠(ASI02 指出运行时问题,ASI03 指出导致权限过高的身份治理失效)。完整的审计会在两者均适用时,将发现结果同时归入两个条目。

  5. 如何防止多租户身份泄露?

    为防止多租户身份泄露,应在主机级别强制实施按租户范围限定,而不是信任连接器级别的执行;确保 Agent 身份与用户身份不同;在 Agent 跨越每个租户边界时要求显式的重新授权;并根据预期边界审计每个已连接工具的实际跨租户可访问性。2025 年 6 月的 Asana MCP 绕过本可以被主机级别的按租户身份治理所阻止,无论连接器如何声明。

  6. 什么是 Agent 上下文中的"隐式委托"?

    隐式委托是指 Agent 以自身持有的相同权限调用子 Agent、子工具或外部服务,而不记录委托链的模式。审计问题在于:无论链中哪个 Agent 决定采取操作,每个下游操作都看起来来自原始身份。事后事件重建变得不可能。修复措施是记录委托图——谁决定采取此操作、基于什么权限、在推理链的哪个环节——并且显式地约束委托,而不是允许无限制的权限传播。

  7. 对于 ASI03,Web3 部署的规则是什么?

    对于 Web3 部署,ASI03 的无条件规则是:持有交易签名权限的 Agent 必须拥有与用户不同的身份,并且每次签名操作都必须记录委托链。将"Agent 曾因用户一次授权而签名"视为持续授权,是一种结构性失效,会在 Agent 首次被劫持时导致资金损失。每次签名操作都需要显式、逐操作的授权,并让用户了解交易的完整影响。

  8. Zealynx 如何审计 ASI03?

    Zealynx 的 MCP 安全审计 从五个维度测试 ASI03:身份图谱枚举(映射每个角色及其持有的权限)、权限继承审计(验证每个 MCP 服务器的实际继承权限)、委托链追踪(确认审计追踪能重建谁决定了什么)、多租户边界测试(验证租户隔离有效)、以及认证 vs 可达性测试(捕获将"本地连接"等同于"已认证主体"的情况)。


术语表

术语 定义
身份继承 MCP 服务器或 AI Agent 组件自动接收其父进程或安装者的身份、凭据和权限的模式——通常操作者并未显式授予该权限。
隐式委托 AI Agent 以自身持有的相同权限调用子 Agent、子工具或外部服务,而不记录委托链的模式。使得事后事件重建不可能,且无限制的权限传播不可见。
多租户边界 共享系统中不同客户或用户租户之间的安全边界。在 MCP 连接的 Agent 中,该边界必须在主机级别强制实施,而不是信任连接器级别的实施,因为一个被攻破的连接器不可信其自身的范围限定。

查看完整术语表 →

  • 原文链接: zealynx.io/blogs/owasp-a...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

相关文章

0 条评论