4 篇博文 含有标签「oauth」

Bearer Token 模型有一个智能体正在悄然违反的假设：调用者在发起请求时知道自己想要什么。OAuth 作用域、IAM 角色和 API 密钥都是围绕一个在身份验证开始前意图就已经确定的主体设计的。你的 CI 运行器意图稳定。你的微服务意图稳定。智能体则不然。智能体的意图是在请求时，由用户提示词、系统提示词、检索到的文档以及可能由攻击者编写的工具输出共同组装而成的。当智能体去获取令牌时，IAM 层必须做的策略决策实际上已经做出了——而决策依据的输入，IAM 层从未见过。

这就是为什么在服务间通信中行之有效的身份验证模式，现在正引发一类没人能准确描述的事故。提示词注入窃取了长效的 Bearer Token。智能体在不同会话间“记住”了权限，因为令牌的寿命超过了用户的意图。一个理应需要三个作用域的多步任务，在整个会话期间都持有所有权限，而不是按步骤获取和释放。严格来说，这些都不是 OAuth 的 bug。它们是试图将假设静态意图的模型扩展到覆盖一个每轮对话都在重构意图的调用者所导致的后果。

安全部门花了十年时间才彻底终结了“全能服务账号”。分限令牌、短期凭据、JIT 访问、逐操作审计——这整套最小权限方案终于落地并稳固下来。然而，AI 团队接入了一个智能体，提示词要求提供工具目录，于是工程师请求了平台所能发放的最广泛的 OAuth 作用域。已被弃用的模式换了一身新衣服又回来了，而这次调用 API 的主体是一个没人确定该如何限定作用域的随机循环。

这个智能体拥有日历、文件存储、CRM 和部署流水线的读写权限，因为 API 表面无法预先枚举。令牌是长效的，因为没人接入刷新路径。审计日志记录的是持有者，而非具体操作。IAM 负责管理人类和服务的身份，平台团队负责工作负载身份，AI 团队负责智能体的实际权限，而这三方集合的交集却无人管辖。

当一个生产环境中的 Agent 首次运行 40 分钟，并在 40 个步骤中的第 27 步遇到 401 错误时，故障复盘的情形几乎总是如出一辙。房间里有人会问为什么令牌没有刷新。另一个人指出刷新逻辑是存在的，但它存在于 HTTP 客户端中，而 Agent 的工具封装层（tool wrapper）从未与之对接。第三个人注意到，即使触发了刷新，Agent 的两个并行工具调用也会尝试在同一瞬间轮换同一个刷新令牌，从而导致会话崩溃。大家纷纷点头。然后，团队在接下来的一周里，为一个假设请求会在 800 毫秒内完成的架构苦哈哈地补齐凭据生命周期管理。

OAuth 的设计初衷是让访问令牌（access token）的寿命长于使用它的请求。长运行 Agent 颠覆了这一假设。现在的请求——实际上是在数分钟或数小时内编排的数十次或数百次工具调用链——比令牌活得更久。整个行业花了十年时间围绕“短请求”假设构建库、代理和刷新流，而这些几乎都无法干净地移植到 Agent 循环中。

当 AI 智能体预订日历事件、发送电子邮件或提交表单时，它并非以自己的身份行事——而是在某个说"去做这件事"的人类的委托授权下行事。这一区别听起来很哲学，直到某个智能体泄露了敏感数据、执行了用户并不打算执行的不可逆操作，或者遭到入侵。到那时，问题不再是发生了什么，而是谁授权的、何时授权的，以及能否撤销。

权限范围设置不当的智能体凭证所带来的波及范围，远超大多数团队的预期。拥有广泛 API 访问权限的智能体不是单一故障点——而是一个长期开放的后门。2025 年，智能体 AI 的 CVE 数量同比增长了 255%，大多数事件都可以追溯到权限过宽、有效期过长或无法彻底撤销的凭证。正确构建智能体，意味着在投入生产之前就设计好授权层。