一句话看懂：Uber 公开了其为数千个内部 AI 智能体设计的身份与权限架构，核心是在多跳任务委托中保留原始用户上下文并逐跳签发短效令牌。这与 Auth0 提出的“智能体需要专属权限模型”的观点相互印证，表明生产环境中的 AI 智能体无法简单套用人类用户或后端服务的访问控制逻辑。
事件核心：发生了什么
Uber 工程师在 InfoQ 的技术分享中详细介绍了其“零信任”架构在智能体系统中的扩展方案。该方案包含智能体注册表、AI 智能体网格、安全令牌服务（STS）、MCP 网关和 AI 网关等组件。关键设计是：每个智能体在委派任务时，会向安全令牌服务申请新的短效 JWT，令牌中不仅包含当前调用者身份，还通过“参与者链”记录了发起请求的原始人员身份。这种令牌为单跳、有效期仅几分钟，并包含特定的受众声明。Uber 称，该系统已被数千个内部智能体采用，生产环境中令牌交换 API 的 P99 延迟低于 40 毫秒。
与此同时，身份管理平台 Auth0 的工程师 Cameron Pavey 撰文指出，AI 智能体的行为模式——多步骤任务、工具调用、跨智能体委托、非用户直接选择的行动——使其既不属于受会话约束的人类用户，也不属于确定性强的后端服务。Auth0 提出了生产环境智能体权限的三种模式：基于能力的权限、基于任务的凭证和分层执行。
为什么重要
AI 智能体从演示走向生产面临的核心难题之一，就是权限边界如何划定。传统方案中，用单一长期有效的服务账户给智能体授权，会导致权限过大，一旦被滥用或误操作，影响范围难以控制；完全依赖用户凭证又无法应对多跳委托场景。Uber 的“逐跳令牌交换+参与者链”方案提供了一个可验证的工程参考：它在不显著增加延迟（P99 < 40ms）的前提下，实现了最小权限原则和端到端审计。这一案例意味着，智能体安全架构正在从理论讨论进入可复制的工程实践，同时引发了行业对 OAuth 2.0 令牌交换、IETF WIMSE 工作组等标准化方向的关注。
对用户/开发者/创作者的影响
对于开发智能体应用的工程师，Uber 的架构启示在于：设计智能体系统时，不应将智能体简单视为“高级 API 客户端”，而应将其视为需要身份传播和权限隔离的多跳参与者。建议关注 MCP 协议网关、短效令牌机制和参与者链的实现方法。对于企业决策者，该案例表明，引入 AI 智能体时，原有的身份和访问控制体系可能需要重新设计，而不是直接复用现有的服务账户体系。对于普通用户，目前这些变化主要在后台，但长期看，更严格的权限控制意味着 AI 助手在代执行敏感操作（如支付、数据删除）时，可能会引入额外的人机确认环节。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
第一，Uber 提到的 IETF WIMSE 工作组正在推动《AI 智能体身份验证与授权》草案，若该标准成型，将为跨平台智能体协作提供基础。第二，Auth0 提出的三种权限模式是否有对应的 SDK 或产品落地，将影响中小开发者能否低成本复用该能力。第三，MCP 网关作为工具访问的控制点，是否会成为类似 API 网关的标准化组件，值得跟踪其开源生态进展。
来源：InfoQ CN
