Uber 升级 AI Agent 身份体系：解决代理身份与权限传递难题

Uber 工程团队近日发布博文，披露其 2025 年在 AI Agent 身份与访问控制技术栈上的主要改造，并展望 2026 年的路线图。随着公司内部 Agent 平台上线、数千个微服务接入 MCP（Model Context Protocol），「谁在什么时间、以什么身份执行了什么操作」成为审计、合规和高层信任的关键问题。旧的身份模型以人或工作负载为中心，Agent 作为「代为行事的实体」既不是单纯的服务账户，也难以保留原始调用者信息，导致跨 Agent 调用的责任链条断裂。

核心问题：代理身份与来源传递缺失

Uber 将实际遇到的痛点归纳为两个核心问题。

• 身份模型未描述"代理性"：现有非人身份（NHI）体系以服务账户或 API Key 描述工作负载，不能表达 Agent「代表某人行事」这一语义。
• 原始来源在跨 Agent 传递中丢失：从发起人经过多跳 Agent 再到下游系统，原始用户与中间决策上下文被丢弃，审计日志难以拼接，精细化的下游访问策略也无法生效。

文章对比了 Agent 工作流与传统自动化的差异：委托是默认模式、工作流是可组合的、行为是动态的。这些特性要求身份基础设施从"静态凭据"转向"贯穿会话的传播链"。

架构方案：基于零信任的 Agent 身份栈

Uber 选择在现有零信任架构之上扩展 AI Agent 能力，围绕「可验证的加密身份」与「下游访问授权」两条主线设计。整体架构包含五个核心组件。

• Agent Registry：作为代理身份的注册中心，由 Michelangelo 平台将 Agent 与底层 Kubernetes 工作负载建立关联，供 STS 校验。
• AI Agent Mesh：类比服务网格的数据平面，Agent 之间通信以及调用外部 MCP 工具时均使用 JWT 令牌鉴权。
• STS（Security Token Service）：动态信任代理，每次跳转都签发短时、限定范围的令牌，替代宽泛长生命周期的服务凭据。
• MCP Gateway：所有 Agent 到 Uber 内部系统的 MCP 工具调用经由此策略点统一鉴权与转发。
• Downstream Systems：实际执行变更或数据检索的微服务 API 与数据存储。

该方案的核心思想是让每一次 Agent 跳转都携带「原始发起人 + 中间 Agent」的完整上下文，下游系统既能审计到人，也能执行已配置的精细化策略。

落地案例与下一步

博文以"Oncall Agent"为例：当值班工程师触发 Agent 处理告警时，调查 Agent 判断告警本身配置错误后，将任务交给监控 Agent 调阈值，新生成 PR 不应只显示「Monitoring Agent 提交」，而应能追溯到具体的人和前序决策。改造后，PR 与审计日志中可还原完整责任链。

Uber 表示，将在 2026 年继续围绕 Agent 身份推进工作，包括更细粒度的策略编排、跨平台的互操作性以及与行业标准的对接。Uber 同时提醒，其架构与性能特征基于内部生产环境，其他组织在参考时应结合自身的部署上下文进行评估。