Zalando开源Agentic Identity Broker，用OAuth委托、令牌保险库和工具审批机制，让AI Agent代表用户办事，却不直接接触用户凭证。

Zalando给AI Agent装上权限闸门

Zalando近日开源了Agentic Identity Broker（AIB），试图解决企业部署AI Agent时最棘手、也最容易被低估的问题：当Agent代表员工访问GitHub、Google、Databricks或Linear时，怎样证明它代表谁、能做什么，以及如何在不交出用户凭证的前提下随时收回权限。

**Agentic Identity Broker是一个面向AI Agent的OAuth 2.0委托与同意管理组件。**它记录“哪个用户把哪些权限委托给了哪个Agent”，集中保存加密后的第三方会话，并在Agent真正调用工具时按需交换令牌，而不是把GitHub、Google等服务的访问令牌直接塞进Agent的上下文、配置文件或运行环境。

这个项目采用MIT许可证，目前仍处于v0.1和活跃开发阶段。OpenAI Hub在2026年11月6日查看其GitHub主页时，项目已有262次提交、34个Star和5个Fork；规模不算大，但代码、架构文档、Helm Chart、OpenAPI契约、数据库迁移和端到端测试已经相当完整。Zalando还明确表示，AIB已经用于内部多个MCP服务器，而不只是停留在概念验证阶段。(github.com)

Agentic Identity Broker架构示意图，展示用户、AI Agent、网关、身份代理、MCP服务器与第三方OAuth服务之间的令牌交换关系

Agent真正缺的不是更多工具，而是一张受约束的工作证

**Agent身份是用于区分AI执行主体、用户主体和服务主体的一组可验证身份信息。**传统应用里，一个请求通常来自用户或后端服务；Agent系统里，一次操作可能经过“用户—聊天应用—主Agent—子Agent—MCP服务器—第三方API”六七个环节，任何一环丢掉委托关系，审计日志里就只剩下一个模糊的服务账号。

很多Agent产品目前采用的办法，是让用户完成一次OAuth登录，然后把长期有效的访问令牌交给Agent运行时。这个方案实现最简单，却等于把办公室门禁卡交给一个会自主规划、会读取外部内容、还可能被提示词注入影响的程序。

问题不只在于令牌可能泄露。更现实的风险是，Agent拿到的权限往往远高于当前任务需要的权限：用户只是让它总结一个GitHub Issue，它却可能同时拥有读取私有仓库、创建分支、合并代码甚至管理Webhook的能力。

AIB的思路是把Agent从“凭证持有者”降级成“权限申请者”。Agent只携带能够证明自身身份和当前用户上下文的令牌，真正访问GitHub、Google等服务所需的第三方令牌由Broker保管，并在调用发生时完成OAuth 2.0 Token Exchange。

**OAuth 2.0 Token Exchange是一种用现有令牌换取受众、权限和有效期更受限制的新令牌的标准机制。**它类似公司前台根据员工证和来访事项，临时签发一张只能进入特定楼层的访客卡，而不是复制员工的整张门禁卡。

权限不是用户权限，而是用户与Agent权限的交集

**有效权限是用户被允许执行的操作与Agent被设计允许执行的操作之间的交集。**这是AIB最关键的设计判断，也是它区别于普通令牌保险库的地方。

假设一名工程师有权合并GitHub主分支，但“代码审查Agent”只被允许读取Pull Request并发表评论，那么即便该工程师本人权限更高，Agent最终拿到的权限也不应包含合并代码。反过来，如果Agent配置允许访问十个仓库，而当前用户只能访问其中两个，它也只能在这两个仓库内行动。

可以把三种常见实现方式放在一起看：

| 访问方式 | Agent持有什么 | 权限边界 | 撤销与审计 | 主要问题 | |---|---|---|---|---| | 直接保存用户令牌 | 第三方Access Token或Refresh Token | 通常等同用户权限 | 分散在各Agent应用中 | 凭证泄露后影响面大，难以识别具体Agent | | 共享服务账号 | 固定机器账号凭证 | 由服务账号角色决定 | 能审计账号，难定位真实用户 | 多人共用身份，容易形成超级账号 | | AIB委托模式 | Agent身份与用户上下文 | 用户权限∩Agent权限∩同意范围 | 集中记录、可撤销、可关联工具调用 | 增加基础设施复杂度与调用链路 |

AIB因此不是简单替用户保存密码，也不是给每个Agent生成一套万能凭证。它维护的是一条委托链：谁发起任务、哪个Agent接手、允许访问哪个服务、同意了哪些Scope，以及令牌最终被换给了谁。

这套机制尤其适合半自主Agent。例如用户在Google Chat里要求Agent更新Linear工单，聊天机器人可以作为受信任的桥接应用传递用户身份；下游Agent仍以该用户的有效权限操作Linear，而不是统一使用聊天机器人的服务账号。(github.com)

AIB把OAuth的复杂度从每个MCP服务器里抽了出来

**MCP服务器是向AI Agent暴露工具、资源和提示模板的标准化服务端组件。**按照较完整的安全实现，每个MCP服务器都要处理授权服务器发现、OAuth跳转、Scope管理、令牌验证、会话保存和刷新等工作。

这在只有两个MCP服务器时尚可接受，但企业内部可能很快出现几十甚至上百个MCP服务。如果每个团队都实现一套OAuth流程，结果大概率是配置不一致、令牌存储方式各异、安全补丁无法同步，最终形成大量小型授权服务器。

AIB选择把这些工作集中到Broker和网关层。Zalando的设想是，Agent通过统一网关访问多个MCP服务器，OAuth仪式、第三方会话保存、令牌转换以及同意记录由中央组件处理，MCP服务器只需要聚焦自己真正提供的工具。

根据当前架构文档，AIB后端使用Go，用户同意界面使用React和TypeScript，生产持久化采用PostgreSQL；Broker与网关之间可以通过独立的ExtProc服务协作，ExtProc再调用Broker的令牌交换和工具审批接口。项目还提供Helm部署目录，明显是按照Kubernetes平台组件而不是单机开发工具来设计的。(raw.githubusercontent.com)

它支持三种OAuth授权服务器模式：

| 模式 | Broker角色 | 适合场景 | |---|---|---| | Proxy | 将授权与令牌请求转发到现有授权服务器 | 企业已经部署成熟的OAuth/OIDC基础设施 | | Local | AIB自身充当授权服务器并签发JWT | 隔离环境、试验平台或缺少上游授权服务器的团队 | | Hybrid | 根据Agent类型选择本地签发或上游代理 | 同时管理内部Agent和外部Agent的平台 |

**AIB不是身份提供商的替代品。**它可以复用企业已有的登录系统，依赖受信任的反向代理完成用户认证，也可以代理现有OAuth授权服务器；它真正补上的，是用户身份、Agent身份和第三方服务会话之间的委托层。

只有令牌交换还不够，危险动作必须在工具层拦截

**工具级授权是针对Agent每一次具体工具调用做出的允许、拒绝或人工确认决策。**OAuth Scope通常只能表达“允许访问邮件”或“允许写入代码仓库”，却很难表达“可以起草邮件，但发送邮件前必须确认”这种更细的业务规则。

AIB已经加入工具审批域。当Agent准备调用高风险工具时，系统可以创建待审批记录，阻塞本次调用，并把工具名称和参数展示给用户。用户可以选择仅允许一次、在当前会话中允许，或设置持续授权；永久拒绝也能阻断特定用户与Agent组合下的工具调用。

这比在Agent聊天界面里弹一个“是否继续”更可靠。聊天界面的确认逻辑通常由Agent应用自己实现，一旦用户换了Agent客户端，审批记录和执行规则可能一起消失；AIB把审批放在网关调用链上，无论Agent运行在本地、Zalando平台还是第三方平台，工具调用都要经过同一个检查点。

项目当前还为审批接口设置了按“用户—Agent”组合计算的速率限制，并使用PostgreSQL的LISTEN/NOTIFY同步多个Broker实例之间的审批状态。这些细节说明，Zalando考虑的不是演示环境里的单用户确认按钮，而是多实例、高并发和可审计的生产执行链。(raw.githubusercontent.com)

当然，人工确认不是万能方案。审批过多会产生典型的“同意疲劳”：用户连续点击十几次允许后，已经不会认真看Agent到底准备发送什么、删除什么。Zalando也把更高风险操作的带外认证、意图授权和集中策略执行列为后续方向。

Broker、网关和策略引擎不是三选一

**身份代理负责建立委托上下文，网关负责拦截流量，策略引擎负责判断某个动作是否符合规则。**这三类组件解决的不是同一个问题，企业不能部署一个API网关就认为Agent权限已经安全。

| 组件 | 回答的问题 | 不能单独解决的问题 | |---|---|---| | 身份提供商 | 用户或机器是谁 | 用户是否把某项权限委托给某个Agent | | Agentic Identity Broker | 谁代表谁、委托了什么权限 | 每个具体业务动作是否符合公司策略 | | Agent/API网关 | 请求经过哪里、如何路由和拦截 | 委托关系是否真实、用户是否同意 | | OPA等策略引擎 | 当前动作是否满足规则 | 第三方OAuth会话如何保存和交换 | | 凭证保险库 | 密钥如何加密保存 | Agent为什么有权使用这把密钥 |

Zalando自己的平台组合也体现了这种分工：kagent负责Kubernetes上的Agent运行，agentgateway位于Agent和MCP服务器之间，AIB负责委托与令牌交换，Open Policy Agent则用于工具调用授权。AIB不是替代所有安全组件的“大一统产品”，而是给现有基础设施补上一块长期缺失的身份拼图。

这是一个重要组件，但还不是即插即用的企业答案

**AIB当前更适合有平台工程和身份基础设施能力的企业团队，而不是个人开发者的一键安全插件。**它需要反向代理、数据库、加密设施、OAuth服务配置、网关集成和权限模型设计，部署成本显然高于把令牌放进环境变量。

它的第一个风险是中心化。Broker保存大量第三方会话，一旦被攻破，攻击者可能获得跨GitHub、Google和其他SaaS系统的访问能力。AIB通过敏感信息脱敏、密码学验证、失败关闭、加密存储以及管理接口隔离降低风险，但“集中治理”与“集中攻击面”本来就是一体两面。

它的第二个问题是性能。每次工具调用都经过网关、外部处理器、Broker和第三方服务，严格的逐跳令牌交换会增加网络延迟。对于需要连续调用几十次工具的Agent，身份服务可能从后台组件变成关键路径上的性能瓶颈。

它的第三个问题是成熟度。截至2026年11月6日，仓库版本文件仍标记为v0.1，README也明确写着项目处于活跃开发阶段。Agent到Agent的正式令牌交换、基于意图的授权和面向用户的活动日志仍在路线图上，这意味着企业现在可以试点和参与设计，但不宜把它当作已经定型的行业标准。(github.com)

真正有价值的地方，是让Agent权限从“配置”变成“可治理对象”

**AIB的核心价值不是发令牌，而是把Agent的权限委托变成可查看、可限制、可撤销和可审计的数据。**过去开发者在配置文件里写一个Scope列表，就认为权限设计已经结束；但对Agent来说，Scope只是最大范围，真正的授权还必须包含用户、Agent、任务、工具和参数等上下文。

这一点会决定企业Agent能否从“只读助手”走向真正执行任务的数字员工。总结文档时，身份问题可以被忽略；当Agent开始合并代码、发送邮件、创建采购单或修改生产配置时，企业必须能回答五个问题：是谁发起的、哪个Agent执行的、代表谁执行、被允许做什么，以及出了问题如何立即撤销。

AIB给出的答案并不新潮：继续使用OAuth、令牌交换、反向代理、网关和策略引擎这些成熟技术，只是重新按照Agent的调用链组合起来。相比再发明一套“AI原生身份协议”，这种保守路线反而更有落地价值，因为企业可以复用已经部署多年的身份系统和访问控制体系。

OpenAI Hub的判断是，Agentic Identity Broker不是一个会立刻改变普通用户体验的明星项目，却可能成为企业Agent平台里非常关键的底层组件。它把安全团队一直追问的“Agent凭什么做这件事”，从一条写在Prompt里的要求，变成网关和身份系统真正能够执行的权限边界。

对于只连接一个服务、由单个用户运行的个人Agent，部署AIB可能明显过重；对于需要接入几十个MCP服务器、多个Agent平台和大量内部用户的企业，它提供的委托模型值得认真研究。尤其是在Agent开始拥有员工级权限之后，继续让它们直接保存用户令牌，已经不是工程上的捷径，而是在积累迟早要偿还的安全债务。