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

日程已上线 100%！6.26-27 AICon 上海站： 13大专题+1个动手实验室、近60场重磅议题，集结清华、复旦等知名高校教授及阿里、腾讯、字节、小红书、Google Cloud等头部企业技术专家，围绕Agent工程化落地等相关议题展开分享， 点击了解详情

最近，Uber 描述了一种用于

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

Uber 的实现方案将其“零信任”架构扩展到了智能体系统。Uber 工程师介绍了一种架构，其中包括智能体注册表、AI 智能体网格、安全令牌服务、

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

一个关键的设计选择是，Uber 并不依赖单一的用户凭证或长期有效的服务账户来处理工作流。每个智能体都会利用本地元数据、传入上下文、目标受众以及

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

示例：Uber 的多跳调查在智能体调用和智能体工具调用过程中传播参与者链声明（

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

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

Uber 还强调了该设计在开发体验方面的优势。最初，该公司曾考虑在智能体间调用中使用外部智能体，但发现要保留端到端执行上下文，而这需要应用层提供支持。因此，Uber 构建了一个标准的

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

该模式与 InfoQ 一篇文章中提到的关注点相吻合。该文