Zalando开源AIB：为AI智能体提供可撤销OAuth委托

摘要：Zalando Incubator以MIT许可证开源Agentic Identity Broker（AIB），用于为AI智能体提供范围受限、可撤销的MCP服务访问权限。AIB由用户按智能体与服务粒度完成授权，加密保存第三方令牌，并在网关侧依据RFC 8693执行令牌交换，使智能体无法直接取得用户令牌。v0.1版本已用于连接数百个智能体和数十个内部及外部MCP服务器；项目下一步计划支持无头智能体与基于意图的授权。

---

AIB解决的核心问题：不要把用户令牌交给智能体

Zalando Incubator开源了Agentic Identity Broker（AIB），这是一套面向AI智能体的OAuth 2委托层。用户可针对某个智能体和某项服务完成一次授权，让智能体以受限身份访问MCP工具；智能体本身不会接触用户用于访问第三方服务的原始令牌。

这一设计针对的是智能体工具调用中的典型权限放大问题：若直接把Bearer Token交给模型或智能体运行时，一旦提示注入、恶意工具、供应链缺陷或上下文泄露影响调用链，暴露范围往往覆盖该令牌的完整权限。AIB把权限边界放在模型之外，由独立代理保存长期凭据、执行令牌交换并记录调用审计。

项目采用MIT许可证，v0.1版本已在Zalando内部生产环境运行，据项目作者称已连接数百个智能体和数十个内部、外部MCP服务器。

工作机制：OAuth委托、加密存储与RFC 8693交换

AIB的典型调用链由四个角色组成：

1. 用户为指定智能体和服务授予同意。
2. AIB加密保存第三方OAuth令牌，将授权与具体智能体、目标服务及允许的权限范围绑定。
3. 网关在智能体发起请求时执行RFC 8693 OAuth 2.0 Token Exchange，将用户授权转换为适合下游使用的访问令牌。
4. MCP服务器只实现工具逻辑，无须自行处理完整的OAuth 2.1授权流程；AIB或网关负责令牌交换与审计。

关键安全属性不是“智能体拥有更少权限”这一句口号，而是原始第三方令牌不进入智能体的可见执行环境。即便智能体能够诱导网关调用高风险工具，它也无法自行读取或导出AIB保存的长期凭据。

不过，隔离令牌并不等于完全消除权限滥用。令牌交换后的访问令牌仍可能被恶意工具记录或滥用，因此授权粒度、审批策略、目标MCP服务器行为及审计日志仍决定最终风险边界。

为什么采用OBO模型

AIB当前主要支持On-Behalf-of（OBO）模式：人类用户将某项任务委托给智能体，由智能体代表用户访问下游服务。这一模式适合企业助手、客服流程、内部自动化等场景，因为授权链中仍然存在明确的人类委托者。

其工程优势在于能够把用户身份、具体智能体和具体工具调用关联起来，并在撤销授权后阻断后续委托。相应代价是系统必须处理授权生命周期：令牌刷新、权限撤销、用户离职、角色变化、凭据轮换以及审计记录留存都不能只依赖智能体自身的配置。

项目下一步计划支持由机器调用智能体的无头代理模式。这会引入另一组问题：机器身份应代表哪个组织主体，谁有权授予它下游权限，以及任务链中的委托如何传递。届时，基于工作负载身份或SPIFFE等可验证工作负载身份的方案，可能比静态客户端凭证更适合作为上游信任锚点。

工程权衡：安全边界、集中审计与运维复杂度

AIB的核心价值是把散落在每个MCP服务中的授权逻辑收敛到统一代理，但也把系统变成了新的高价值控制点：

• 凭据集中化降低泄露面，但提高爆炸半径。 智能体不再持有原始令牌，但AIB一旦被攻破，可能影响大量服务，密钥隔离、分区、轮换和最小化数据库权限不可省略。
• 令牌交换增加一次网络与处理开销。 网关需要验证交换请求、选择目标受众并获取短期令牌；高并发智能体负载下，应对刷新风暴、缓存和限流成为关键问题。
• 可撤销性依赖状态一致性。 用户撤销授权后，缓存中的交换令牌、已签发令牌和下游会话是否同步失效，需要跨组件明确传播。
• 审计集中化提高可观测性，也可能记录敏感数据。 日志应记录主体、智能体、工具、目标服务和决策结果，但必须避免写入原始令牌、敏感参数或完整请求内容。
• OAuth 2.1仍需落地到每个资源服务器。 AIB可以避免MCP工具实现认证细节，却不能替代资源服务器对scope、受众、受众限制令牌和最小权限的严格执行。

项目还计划加入基于意图的授权。其方向是把“允许调用某工具”进一步提升为“允许在满足某业务意图、上下文和约束时调用”。不过，意图识别本身可能由模型判断，若缺少确定性策略约束，便会形成新的间接提示注入面。更稳妥的落地方式是把意图识别结果作为策略输入，再由可审计的规则引擎决定是否签发或交换令牌。

部署建议与适用边界

开发者可在本地克隆项目后执行just compose-up-detached启动环境，但生产接入至少需要补齐以下能力：

• 为每个智能体、服务和工具定义独立scope，避免共享宽权限客户端；
• 使用外部密钥管理系统或信封加密保护第三方令牌，并对交换密钥实施轮换；
• 在网关侧验证RFC 8693请求、目标audience与防混淆参数，防止令牌被重定向到其他服务；
• 对高风险工具设置人工审批或策略门控，并使审批具备时效性与单次绑定属性；
• 将授权撤销传播至令牌缓存、在途请求和下游会话；
• 对审计日志实施脱敏、访问控制、留存周期和不可篡改存储；
• 为刷新失败、用户撤权、下游不可用和部分授权建立明确的失败关闭策略。

AIB最适合已有多个MCP服务、需要让智能体代表用户调用外部系统，同时又不愿自行搭建OAuth委托层的团队。它不能替代身份提供商，也不能天然解决提示注入、工具输出污染或MCP服务器自身的漏洞。

成熟度判断

AIB的亮点不是提出了新的OAuth协议，而是把现有OAuth 2.1和RFC 8693机制组合成一个可部署的智能体身份代理，并已通过内部生产环境使用验证工程可行性。不过，当前版本仍为v0.1，公开材料没有披露吞吐量、令牌交换延迟、故障恢复、撤销传播时延、密钥轮换机制和安全评测结果。

因此，这是一项值得企业智能体平台团队试点的开源基础设施，而不是已经完成标准化的通用身份层。随着IETF相关智能体身份标准收敛，AIB的协议接口仍可能调整；当前采用时，应避免把其内部数据模型和流程绑定写死到业务代码中。

---

消息来源：Hacker News AI Feed (2026-11-06)

—— 完 ——

主题标签： #AIB 关注 #OAuth 2.1 关注 #RFC 8693 关注 #MCP 关注 #智能体身份 关注