写点什么

AI 智能体的身份与权限挑战:Uber 和 Auth0 如何重新思考访问控制

作者:Eran Stiller
  • 2026-06-25
    北京
  • 本文字数:1904 字

    阅读完需:约 6 分钟

最近,Uber 描述了一种用于在多智能体 AI 工作流中传播智能体身份的内部架构。该设计的目标是,在智能体委派任务并调用内部工具时,能够保留原始的用户上下文、智能体的来源信息以及限定范围的访问权限。Uber 的案例研究印证了 Auth0 的观点:AI 智能体需要权限模型,基于授权委托、范围限定凭证以及明确的人工审批边界,而非传统的服务账户或宽泛的 OAuth 权限范围。

问题在于,AI 智能体无法完美地融入为人类用户或后端服务构建的访问控制模型中。在 Auth0 的一篇文章中,Cameron Pavey 指出,用户通常受会话和用户界面的限制。相比之下,后端服务通常是确定性的,而且可以通过静态代码路径进行审计。智能体可能会执行多步骤任务、调用工具、将任务委托给其他智能体,并代表用户采取行动,而这些行动并非全部由该用户直接做出选择。正如 Pavey 所言:“AI 智能体不属于上述任何一类。”

Uber 的实现方案将其“零信任”架构扩展到了智能体系统。Uber 工程师介绍了一种架构,其中包括智能体注册表、AI 智能体网格、安全令牌服务、模型上下文协议(MCP)网关、下游系统以及 AI 网关/AI 守护程序。智能体注册表存储了智能体与其被允许托管的工作负载之间的关联关系。安全令牌服务会验证该关联关系,并为智能体工作流中的每个跳点签发短效的 JSON Web Token(JWT)。随后,MCP 网关负责协调智能体网格对内部系统的访问,执行工具访问检查,并在必要时对敏感数据进行脱敏处理。

Uber 的智能体身份架构将智能体注册、令牌交换、网关执行以及下游系统访问连接了起来(图片来源

一个关键的设计选择是,Uber 并不依赖单一的用户凭证或长期有效的服务账户来处理工作流。每个智能体都会利用本地元数据、传入上下文、目标受众以及由 SPIRE 签发的工作负载身份,向安全令牌服务(Security Token Service)请求新的令牌。Uber 表示,在概念上,该方法基于 OAuth 2.0 令牌交换机制,但为了满足内部审计和性能要求做过定制,能够携带智能体身份和来源信息。生成的令牌为单跳、短效令牌,其中包含特定的受众声明(Audience claim),其生存时间(TTL)以分钟为单位。

这种来源信息被记录在 Uber 所说的“参与者链”中。在 Uber 的多跳调查示例中,一名值班工程师可能会要求一个值班智能体调查某个问题。该智能体随后可能会将任务委派给一个调查智能体,然后通过 MCP 网关调用内部工具。提交给网关的令牌中包含参与者链,而不仅仅是直接调用者。这使得下游系统在做出授权决策时,能够同时评估发起请求的人员身份和执行操作的智能体身份。

示例:Uber 的多跳调查在智能体调用和智能体工具调用过程中传播参与者链声明(图片来源

Auth0 的框架与 Uber 的实现相辅相成,他们提出了生产环境智能体架构的三种模式:基于能力的权限、基于任务的凭证以及分层执行。其目标是限制 AI 智能体出错后的影响范围,同时又不会削弱让 AI 智能体具备实用价值的自主决策能力。在 Uber 的架构中,类似的控制措施包括按跳交换令牌、受众范围限定、基于注册表的智能体验证、网关策略检查,以及在必要时对敏感数据进行脱敏处理。

Auth0 描述了一种智能体权限模型,其中短效的范围限定令牌从身份提供商流向智能体运行时和工具层(图片来源

Uber 还强调了该设计在开发体验方面的优势。最初,该公司曾考虑在智能体间调用中使用外部智能体,但发现要保留端到端执行上下文,而这需要应用层提供支持。因此,Uber 构建了一个标准的 A2A 客户端,用于实现令牌交换和参与者链传播的自动化。Uber 将其定义为“默认安全”的开发体验,将身份传播纳入标准客户端路径,而非让每个智能体团队独立实现。

Uber 表示,该系统已经被数千个内部智能体采用。该公司表示,其生产环境指标显示,安全令牌服务(Security Token Service)令牌交换 API 的 P99 延迟始终低于 40 毫秒。这消除了人们对“每跳令牌交换可能会在涉及大量工具调用和委托的工作流中增加过多开销”这一潜在的担忧。Uber 还表示,随着工作负载和智能体身份相关的标准活动的不断发展,他们正在关注 IETF WIMSE 工作组及相关草案,包括《AI 智能体身份验证与授权》。

该模式与 InfoQ 一篇文章中提到的关注点相吻合。该文介绍了如何使用 MCP、OPA 和临时运行器构建最小权限的 AI 智能体网关,以网关边界作为工具访问、策略评估和可审计性的控制点。Uber 的案例提供了一个生产环境中的实例,展示了如何将该边界与智能体身份传播及逐跳委托相结合。对于架构师而言,更广泛的启示是:智能体系统需要采用能够在整个工作流中保留发起用户上下文、智能体身份以及工具级授权的访问模型,而不是将智能体视为普通的客户端或服务。

原文链接:https://www.infoq.com/news/2026/06/ai-agent-identity-uber-auth0/