最近Uber 描述了一种用于在多智能体 AI 工作流中传播智能体身份的内部架构。该设计的目标是在智能体委派任务并调用内部工具时能够保留原始的用户上下文、智能体的来源信息以及限定范围的访问权限。Uber 的案例研究印证了 Auth0 的观点AI 智能体需要权限模型基于授权委托、范围限定凭证以及明确的人工审批边界而非传统的服务账户或宽泛的 OAuth 权限范围。问题在于AI 智能体无法完美地融入为人类用户或后端服务构建的访问控制模型中。在 Auth0 的一篇文章中Cameron Pavey 指出用户通常受会话和用户界面的限制。相比之下后端服务通常是确定性的而且可以通过静态代码路径进行审计。智能体可能会执行多步骤任务、调用工具、将任务委托给其他智能体并代表用户采取行动而这些行动并非全部由该用户直接做出选择。正如 Pavey 所言“AI 智能体不属于上述任何一类。”Uber 的实现方案将其“零信任”架构扩展到了智能体系统。Uber 工程师介绍了一种架构其中包括智能体注册表、AI 智能体网格、安全令牌服务、模型上下文协议MCP网关、下游系统以及 AI 网关/AI 守护程序。智能体注册表存储了智能体与其被允许托管的工作负载之间的关联关系。安全令牌服务会验证该关联关系并为智能体工作流中的每个跳点签发短效的 JSON Web TokenJWT。随后MCP 网关负责协调智能体网格对内部系统的访问执行工具访问检查并在必要时对敏感数据进行脱敏处理。Uber 的智能体身份架构将智能体注册、令牌交换、网关执行以及下游系统访问连接了起来一个关键的设计选择是Uber 并不依赖单一的用户凭证或长期有效的服务账户来处理工作流。每个智能体都会利用本地元数据、传入上下文、目标受众以及由 SPIRE 签发的工作负载身份向安全令牌服务Security Token Service请求新的令牌。Uber 表示在概念上该方法基于 OAuth 2.0 令牌交换机制但为了满足内部审计和性能要求做过定制能够携带智能体身份和来源信息。生成的令牌为单跳、短效令牌其中包含特定的受众声明Audience claim其生存时间TTL以分钟为单位。这种来源信息被记录在 Uber 所说的“参与者链”中。在 Uber 的多跳调查示例中一名值班工程师可能会要求一个值班智能体调查某个问题。该智能体随后可能会将任务委派给一个调查智能体然后通过 MCP 网关调用内部工具。提交给网关的令牌中包含参与者链www.ycsjb.com而不仅仅是直接调用者。这使得下游系统在做出授权决策时能够同时评估发起请求的人员身份和执行操作的智能体身份。示例Uber 的多跳调查在智能体调用和智能体工具调用过程中传播参与者链声明Auth0 的框架与 Uber 的实现相辅相成他们提出了生产环境智能体架构的三种模式基于能力的权限、基于任务的凭证以及分层执行。其目标是限制 AI 智能体出错后的影响范围同时又不会削弱让 AI 智能体具备实用价值的自主决策能力。在 Uber 的架构中类似的控制措施包括按跳交换令牌、受众范围限定、基于注册表的智能体验证、网关策略检查以及在必要时对敏感数据进行脱敏处理。Uber 还强调了该设计在开发体验方面的优势。最初该公司曾考虑在智能体间调用中使用外部智能体但发现要保留端到端执行上下文而这需要应用层提供支持。因此Uber 构建了一个标准的 A2A 客户端用于实现令牌交换和参与者链传播的自动化。Uber 将其定义为“默认安全”的开发体验将身份传播纳入标准客户端路径而非让每个智能体团队独立实现。Uber 表示该系统已经被数千个内部智能体采用。该公司表示其生产环境指标显示安全令牌服务Security Token Service令牌交换 API 的 P99 延迟始终低于 40 毫秒。这消除了人们对“每跳令牌交换可能会在涉及大量工具调用和委托的工作流中增加过多开销”这一潜在的担忧。Uber 还表示随着工作负载和智能体身份相关的标准活动的不断发展他们正在关注 IETF WIMSE 工作组及相关草案包括《AI 智能体身份验证与授权》。该模式与 InfoQ 一篇文章中提到的关注点相吻合。该文介绍了如何使用 MCP、OPA 和临时运行器构建最小权限的 AI 智能体网关以网关边界作为工具访问、策略评估和可审计性的控制点。Uber 的案例提供了一个生产环境中的实例展示了如何将该边界与智能体身份传播及逐跳委托相结合。对于架构师而言更广泛的启示是智能体系统需要采用能够在整个工作流中保留发起用户上下文、智能体身份以及工具级授权的访问模型而不是将智能体视为普通的客户端或服务。
