解决 AI 智能体的身份危机

简介

Uber 处于利用 AI 的前沿，赋能工程师构建 AI 解决方案以提升生产力。2025 年初，该公司构建了一个内部 Agent 平台，使团队能够大规模地组合、部署和运行生产级 Agent。此外，Uber 由数千个服务组成的微服务技术栈通过在现有服务 API 上启用 MCP®（模型上下文协议）支持，已为 AI 做好准备。

随着 Agent 自主性不断增强，需要对 Agent 及其执行的操作进行严格监督。问责能力，即回答“谁在何时因何做了什么”的能力，对于审计、合规和高管信任至关重要。没有明确的归属，安全控制可能更难执行，事件响应可能变慢，信任也可能受到影响。

本博客概述了 Uber 身份与访问技术栈在 2025 年为适应 AI Agent 所做的重大更新。为了在 AI 采用加速之际保持主动姿态，我们还在此技术领域展望了 2026 年的战略路线图。

所述系统和方法反映了 Uber 的内部架构和受控生产环境。设计选择、性能特性和安全控制可能因组织、用例和部署环境而异。

动机

想象一位值班工程师使用 Oncall Agent 来管理和解决系统警报。在此场景中，Investigation Agent 确定系统运行正常，警报本身配置有误。随后，Investigation Agent 无缝地将任务传递给 Monitoring Agent，通过 PR（拉取请求）调整警报的阈值。该拉取请求显示由 Monitoring Agent 引入了更改，但负责的值班工程师的身份却无法追溯。

图 1：Agentic AI 示例。

我们开始在多个用例中观察到这种模式：一个 Agent 会通过多步路径来完成工作，但它交互的系统在每一跳中只能看到一个通用的服务身份。而且，工具调用在下游系统看来只是“某个服务调用了 API”，尽管真正的执行者是一个代表特定用户的特定 Agent。

随着 Agentic 工作流扩展到涵盖更多 Agent、工具和系统，这一挑战变得日益突出。我们将其提炼为以下两个核心问题。

问题 1：当前身份模型无法描述代理关系 

当今的身份模型围绕人类和工作负载（通常称为非人类身份或 NHI，通过服务账户或 API 密钥等凭据支持）构建。Agent 最佳的定义是被授权代表或代替另一个实体行事的实体。AI Agent 通常作为工作负载运行，代表人类执行任务。在上面的例子中，Oncall Agent 代表值班工程师启动了一个会话，以调查并修复一个特定问题。

问题 2：原始来源信息未能在 Agent 之间有效传递到系统

执行上下文（发起用户、中间代理）在代理跳转过程中被丢弃。这导致整个系统的审计不完整，并限制了我们一致地利用下游系统已配置的细粒度访问策略的能力。在缺乏完整审计跟踪的情况下，事件响应将需要将各系统的部分审计日志拼接在一起。监控代理（Monitoring Agent）提交的 PR 应该表明值班工程师请求解决某个特定问题，以及导致该 PR 的先前代理决策的相关上下文。

很明显，代理式工作流的行为与传统自动化不同：

• 委派是默认模式——代理代表他人工作
• 工作流是组合式的——代理调用其他代理、工具和系统
• 行为是动态的——随着会话的进行，计划会根据中间结果不断演进

这为我们需要构建的内容指明了方向：代理身份及其在代理间传播的基础，以解决上述问题。

架构

随着 AI 工作流规模的扩大，自主代理与内部系统之间的交互变得极其复杂。为了在不抑制开发者速度的情况下保护这一生态系统，我们决定扩展现有的零信任架构以适用于 AI 代理。我们的架构专注于在代理生态系统内建立可验证的加密身份，并强制执行对下游系统的访问授权。

图 2：架构。

该架构包含以下核心组件。

代理注册表

在 Uber，AI 代理通常作为工作负载部署，通常由 Kubernetes® 管理。Michelangelo 平台将 AI 代理与工作负载关联。代理注册表作为事实来源，存储此注册信息。之后，安全令牌服务（Security Token Service）会使用它来验证代理。

AI 代理网格

类似于流行的 service mesh（服务网格）一词，AI 代理网格是数据平面，AI 代理在此相互通信以完成分配给它们的任务。在代理网格内以及对外调用（例如调用 MCP 工具）时，AI 代理依赖于安全令牌服务签发的 JWT 令牌进行身份验证。

STS（安全令牌服务）

AI 代理的令牌签发由 STS 处理。STS 不依赖广泛、长期的服务凭据，而是充当动态信任中介，为每一次跳转签发短期、有范围限制的令牌。

MCP 网关

MCP 网关是一个中心系统，用于中介来自 AI 代理网格对 Uber 系统的调用。这种设计使 MCP 网关能够成为 MCP 工具调用的策略执行点。

下游系统

一旦 MCP 网关成功验证调用方身份并授权工具调用，它就会将请求安全地代理到相应的下游服务。这些主要是执行实际变更或数据检索的微服务 API 和数据存储。

AI 网关

除了这些组件之外，AI 网关（AI Gateway）负责中介 AI 智能体向 AI 模型发出的所有出站调用。这作为 Uber 与 OpenAI®、Anthropic® 等外部 API 集成的中心点。AI 网关与安全护栏集成，用于检测和处理提示词注入、越狱、内容安全、PII 脱敏等。有关 Uber AI Guard 的更多信息，请参阅我们最近的会议演讲此处。

为了赋能工程师和运营团队构建智能体解决方案，Michelangelo AI 平台提供了两种选择：

• 代码方式：使用 Uber 的内部生产级 SDK 用 Python 编写智能体。该 SDK 与编排框架无关，支持常见的智能体编程模式（规划循环、工具使用、状态和记忆），同时为生产部署提供标准化的脚手架、中间件钩子、可观测性和评估工具。
• 无代码方式：通过 UI 创建智能体，无需编写任何代码。这降低了入门门槛，并将构建智能体的能力开放给工程师之外的整个公司。

无论选择哪种方式，生成的 AI 智能体都将部署在 Uber 的 Kubernetes 基础设施内。

最初我们考虑构建/采用 agentgateway 来代理 AI 智能体之间的调用。随着 Uber 的智能体 AI 生态系统在 SDK 上高度标准化，我们转而将该解决方案直接集成到 SDK 中。我们还发现，要完全解决问题 2，需要在智能体应用层获得支持——执行上下文在该层被创建并端到端传播，而不是仅依赖外部代理。

提供智能体身份

与微服务类似，AI 智能体在工作负载内运行。需要解决的根本挑战是如何为每个单独的智能体分配一个可验证的身份。图 3 展示了我们的智能体身份模型以及为智能体铸造 JWT 令牌的过程：

图 3：为智能体提供其身份。

我们更新了 SDK，添加了在运行时获取 AI 智能体身份的代码。

1. 每个工作负载首先从 SPIRE 获取其自身经过加密签名的工作负载 SVID（SPIFFE 可验证 ID）。这证明了底层计算环境的合法性，但尚未识别智能体。
2. SDK 使用其本地可用的元数据（如智能体配置）、来自入站调用的 JWT 以及出站目标受众，向 STS 请求新的 JWT 令牌，该请求使用工作负载 SVID 进行身份验证。只有 STS 被允许为 AI 智能体铸造令牌。通过集中化这一过程，我们确保行为者链携带请求中涉及的每个实体的加密记录。
3. STS 与智能体注册表集成，以验证请求的 agent_id 是否被明确授权在该特定工作负载（来自步骤 1）上运行。这可防止工作负载试图冒充其未被授权托管的智能体。
4. STS 铸造一个 JWT 令牌并将其返回给请求的智能体。该 JWT 用于智能体流程下一跳的请求。

以下是该设计的一些关键特性：

• 单跳、短生命周期的令牌。STS 签发的每个 JWT 都设计为仅用于单跳，带有特定的 Audience 声明，以及以分钟计的短生存时间。为 Agent A 调用 Agent B 而签发的令牌无法被拦截并重放以调用数据库或其他服务；它仅对特定目标有效。
• 完整的上下文归因。 STS 在每一步管理令牌交换，并将经过完全认证的参与者链嵌入令牌中。这使得 MCP Gateway 或下游系统能够拥有请求的完整上下文；我们能看到血缘关系中的每个参与者（例如工程师到 Oncall Agent 到 Investigation Agent……），而不仅仅是直接调用者。这种可见性支持全面的审计日志和高级工作流授权，能够考虑完整的请求血缘。
• 可扩展的上下文。JWT 结构设计为可扩展的；我们可以在未来无缝添加额外的声明，例如会话标识符和与请求意图相关的声明，为策略决策提供更丰富的上下文。这种高保真可见性确保工具的执行不仅可以由最后一跳授权，还可以由整条链的已验证意图来授权。

通过将每个代理身份锚定在 SPIRE 支持的工作负载凭据上并集中化令牌交换，我们能够在保持端到端可追溯性的同时提供短生命周期的令牌。

代理身份的实际应用

要理解代理身份如何在真实工作流中体现，让我们追踪一个典型的请求路径。由于 agentic AI 工作流涉及调用多个专门的代理来完成复杂的用户请求，身份必须在每个边界上演化而不丢失其原始上下文。图 4 展示了一个多跳调查流程，从最初的用户查询到最终的安全工具调用：

图 4：Agentic AI 会话生命周期。

1. 一位值班工程师（user1）与 Oncall Agent 发起会话。在这个入口点，请求由用户自己的人员身份锚定。
2. Oncall Agent 不能重用用户的原始凭据来调用下游服务。相反，它联系安全令牌服务。它出示其 SPIRE 签发的身份（Workload-1）和用户上下文，以请求一个专门限定为下一跳受众 Investigation Agent 的新 JWT。STS 向 Oncall Agent 返回一个 JWT。这种逐跳交换令牌的机制在概念上基于 OAuth 2.0 令牌交换（RFC 8693），但经过定制，以精简的方式传输代理身份和来源信息，并与 Uber 的内部审计和性能要求集成。

图 5：Oncall Agent 即将调用 Workload-2 的 JWT。

1. Oncall Agent 将上述 JWT 发送给 Investigation Agent（托管在 Workload-2 内）。
2. Investigation Agent 验证签名和受众。为了调用 MCP Gateway，Investigation Agent 以 MCP Gateway 作为 STS 受众执行自己的令牌交换。此步骤与上面的步骤 2 相同。新签发的 JWT 携带了所有参与者的可验证历史：[user1, oncall-agent, investigation-agent]。
   

   

   图 6：Investigation Agent 调用 MCP Gateway 的 JWT。

   
   
3. MCP 网关接收并验证 JWT。验证通过后，网关会强制执行工具级策略，包括工具访问检查以及在需要时对敏感数据进行脱敏（这也由我们在架构部分提到的 AI Guard 提供支持）。策略基于内部风险分类定义，并强制适用于我们认定为高风险的系统。

在整个请求调用链中建立身份，使系统能够执行足够灵活的策略，同时评估人员身份（人类发起者）和代理身份（执行逻辑）。随着我们不断演进 IAM 系统以支持 AI 代理，我们正在密切关注新兴标准，特别是 IETF WIMSE 工作组草案，以及相关个人草案，如“AI Agent Authentication and Authorization”（draft-klrc-aiagent-auth-01），以保持与行业大方向的一致。

建立标准化路径

在架构实施之前，已经构建了若干代理。这带来了一个挑战：确保每个代理都一致地执行 STS 令牌交换并保留 actor 链。为了消除这些差距，我们从手动合规转向了自动化、默认安全的开发者体验。

我们在 A2A 协议之上开发了标准化的 A2A（代理对代理）客户端。该客户端自动执行 STS JWT 交换和 actor 链的传播，确保安全路径同时也是开发者实现 A2A 调用的最便捷路径。

图 7：A2A 客户端请求 JWT 令牌。

此外，我们正与利益相关者合作，将现有用例迁移到使用 A2A 客户端。这涉及分阶段识别遗留的代理间调用，并将其重构为使用标准 A2A 客户端。通过提供专门的支持和测试指南，我们确保这些现有代理获得完整的血缘归因和集中可审计性，同时不干扰其当前功能。

可观测性与采用

我们的可观测性系统提供了对代理流量的实时端到端视图，使复杂的多代理工作流变得透明且可审计。通过捕获 actor 链中的每一跳——从发起用户经过多个代理再到下游工具调用——它能够精确归因操作，以及相关的授权决策和安全上下文。在零信任环境中，这种可见性是首要任务，因为每一次交互都应经过认证、授权和持续监控。

图 8：Actor 链追踪可观测性。

该系统已被数千个内部代理采用。引入逐跳令牌交换时，一个常见的担忧是延迟可能增加。在 Uber 这样的大规模环境中，单个代理任务可能涉及数十次工具调用和代理委派，即使几毫秒的开销也会迅速累积。我们的生产指标显示，在当前负载条件下，该安全模型保持了低延迟。下图展示了 STS Token Exchange API 的 P99 延迟持续低于 40 毫秒。我们计划随着 Uber 上代理式 AI 采用的增长，继续扩展该系统。

图 9：Agent 令牌交换 p99 延迟。

在生产环境中，Agent 交互受标准安全和治理控制的约束，包括策略执行、监控和审计日志记录，以确保安全合规的运行。

结论

在思考 AI 身份与访问的未来时，我们以图 10 所示的三个层次来构建我们的方向。

图 10：Agentic IAM 方向。

第一层是身份与信任基础（Identity & Trust Foundation）——为每个 Agent 建立可验证的加密身份，并保留从用户到 Agent 再到工具的完整委托链。这是本篇博客主要关注的层次。

在该基础之上是动态访问控制（Dynamic Access Control），随后是统一策略执行平面（Unified Policy Enforcement Plane），它能够实现可观测性，并在工具、会话和协议之间一致地表达业务级控制。在 Agent 驱动的世界中，静态的人工管理权限和分散的执行方式无法扩展。

我们的长期愿景是一个协同的架构，其中身份、风险和策略无缝协作——使人类和 AI Agent 能够以机器速度协作，同时保持强大的信任和安全控制。

致谢

Anthropic 是 Anthropic, PBC 的注册商标。

Kubernetes®、Model Context Protocol (MCP)  及其标志是 The Linux Foundation® 在美国和其他国家的注册商标。使用这些标志并不意味着 The Linux Foundation 的认可。

OpenAI® 及其标志是 OpenAI® 的注册商标。

封面图片来源：由 ChatGPT 创建的图像

及时获取 Uber Engineering 的最新动态——在 LinkedIn 上关注我们，获取我们最新的博客文章和见解。