智能体身份与委托授权：智能体操作的 OAuth 模式

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

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

"代表他人行事"的真正要求

传统的 OAuth 假设存在一个向应用程序授予其资源访问权限的人类用户。当 AI 智能体进入这条链时，你面对的是更复杂的主体层级：委托授权的用户、执行任务的智能体进程、证明授权的令牌，以及可能存在的一系列子智能体——每个子智能体都从父级接收了更窄范围的委托。

RFC 8693（OAuth 2.0 令牌交换）正式确立了这里的语义。"代表"（OBO）流程创建的令牌具有以下特征：

• sub 声明标识委托授权的用户
• act 声明标识执行操作的智能体

两种身份都编码在每个令牌中。这种双重身份结构是归因的基础——没有它，事后就无法回答"谁授权了这个操作"。每一个只记录了服务账户主体的智能体操作日志，都是归因债务。

IETF 的现行标准化工作正在追赶这些需求。针对 AI 智能体的草案扩展为 OAuth 2.0 授权请求引入了 requested_actor 和 actor_token 参数，允许授权服务器签发的令牌同时明确编码智能体身份和委托用户。结合 MCP 授权规范（将 OAuth 2.1 定为强制要求），这正迅速向一个连贯的标准收敛——但你需要现在就设计双重身份，而不是等到 RFC 最终确定。

范围设计：预先设计的难题

对于人类用户，最小权限原则意在限制他们在系统中可以做的事情。对于智能体，挑战则不同：智能体在运行时进行推理和自适应，这意味着同一个智能体在一次执行中可能读取数据，在另一次执行中根据目标和中间结果进行写入。传统的最小权限原则假设访问是"预先设计"的，而智能体打破了这一假设。

解决方案是按操作而非按智能体来限定范围。与其授予智能体 calendar:all 或 email:all，不如在操作层面定义范围：

• calendar:create_event — 可以创建事件，但不能读取已有事件
• email:send — 可以发送，但不能读取收件箱
• drive:write:folder/reports — 写入访问范围限定在特定路径

当智能体尝试需要更高权限范围的操作时，服务器会返回带有 WWW-Authenticate 头（标识所需范围）的 HTTP 403 响应。这就是逐步授权模式：系统不是静默失败或预先广泛授权，而是在需要点暴露约束，并在值得授予范围时触发明确的用户同意。

这里还有另一个结构性要求：委托合约只能缩小，不能扩大。如果父编排智能体拥有读写权限并派生了一个子智能体来执行子任务，该子智能体只能获得父级范围的子集——绝不能超过。这防止了能力洗白，即一个权限极少的智能体委托链以某种方式积累了整条链本不应拥有的权限。

凭证生命周期：事件驱动，而非日历驱动

永久有效的智能体令牌是大敌。凭证存在的时间越长，它出现在日志中、流经受损环境或在用户早已改变意图时仍然有效的可能性就越大。

智能体凭证的正确生命周期模型是：

• 默认短暂有效：大多数智能体操作的令牌有效期为 5-15 分钟。智能体在短任务窗口内运行；没有理由让凭证的有效期超过任务本身。
• 即时供给：特定操作的凭证仅在需要时注入，并在之后立即过期。正在写入日历事件的智能体不应同时持有电子邮件凭证。
• 事件驱动轮换，而非日历驱动：在部署更新、配置更改、范围修改或能力扩展（向智能体添加新工具）时进行轮换。基于日历的轮换会造成旧凭证和新凭证不必要地共存的窗口期。

这能防范一种微妙的失败模式：团队通常假设，因为上个月正确签发了智能体令牌，授权模型就仍然有效。但未经权限审查的能力扩展，正是智能体随时间积累常备访问权限的方式。每向智能体添加一个新工具，都是一次可能绕过原始授权审查的潜在范围扩展。

将短令牌有效期与刷新令牌轮换（OAuth 2.1 对公共客户端的强制要求）结合起来，你还会获得一个额外的安全属性：攻击者对刷新令牌的重复使用立即可被检测，因为授权服务器会识别之前已使用过的刷新令牌并使整个授权失效。

撤销：需要即时生效

撤销是授权系统成败的关键。可能需要撤销智能体访问权限的主体有三方：

• 委托授权的用户（他们改变了主意，或智能体行为不当）
• 安全团队（事件响应，检测到违规行为）
• 服务提供商（可疑活动，安全漏洞）

架构要求是集中式令牌验证。每个智能体操作必须针对单一授权服务器验证其令牌，而非针对本地缓存或分布式凭证存储。当撤销发生时，它会立即传播，因为只有一个真实来源。

"用户撤销智能体访问"的流程应该看起来像标准的 OAuth"已连接应用"管理——用户看到智能体可以做什么，点击断开连接，令牌立即失效。没有延迟，没有手动清理，不用等待下一个轮换周期。

对于策略触发的撤销（智能体超越了其权限，检测到异常行为），你需要同样即时的路径。实时异常检测层应监控：

• 异常数据量（智能体导出的记录远超任务需要）
• 非工作时间活动（自动化在委托用户不活跃时运行）
• 范围升级请求（智能体请求以前从未需要过的权限）

当任何这些触发条件触发时，立即撤销。不正确撤销的代价是用户需要重新授权。遗漏撤销的代价是你没能及时发现的数据泄露。

审计跟踪：记录归因，而非仅为合规

智能体操作的审计跟踪比人类用户操作更复杂，因为单个智能体操作涉及多个主体。考虑一个代表用户发送电子邮件的智能体：

• 谁触发了该操作？（说"发送这个"的用户）
• 谁执行了代码？（智能体进程）
• 谁的凭证执行了 API 调用？（OAuth 令牌主体）
• 谁部署和管理了智能体？（组织机构）

只记录 OAuth 令牌主体的日志遗漏了触发用户。只记录智能体进程的日志遗漏了使用的凭证。完整的审计跟踪需要捕获所有四者。

实用的模式是将连接 ID 作为联接键：

• 授权服务器跟踪 OAuth 连接、令牌签发、范围授予和撤销时间戳
• 应用程序以连接 ID 为外键记录智能体端事件（请求了什么操作、访问了什么数据、结果是什么）
• 合规审计连接这两个日志以重建完整的授权链

这对企业部署中最常见的四个合规框架至关重要：

• SOC 2 CC6.1 要求归因到授权主体——双重身份日志满足此要求
• SOC 2 CC6.2 要求带有撤销时间戳的访问移除——授权服务器日志提供了这一点
• GDPR 第 7(3) 条要求具有证据的撤销能力——连接生命周期日志就是这一证据
• HIPAA 要求对任何接触健康数据的智能体进行 6 年的 ePHI 日志保留

除合规外，审计跟踪是你在出错后理解智能体行为的方式。"对账智能体数据泄露"失败模式——智能体被诱骗导出所有匹配某个模式的记录——只有在事后拥有完整操作日志时才能诊断。没有这些日志，你知道数据离开了系统，但不知道它是如何被授权的。

连接 MCP：新兴标准

模型上下文协议授权规范正迅速成为智能体连接外部服务的权威参考。其授权模型值得直接理解：

• OAuth 2.1 对 MCP 实现是强制要求（非可选）
• 令牌必须通过资源指示符（RFC 8707）绑定到特定的 MCP 服务器——MCP 服务器会拒绝未明确为其签发的令牌
• 明确禁止令牌透传——作为上游 API 代理的 MCP 服务器必须为该 API 获取新凭证，而不是转发客户端的令牌
• 服务器通过知名 URI（RFC 9728）发布其授权要求，实现无需预建关系的动态客户端注册

最后一点在架构上意义重大。传统 OAuth 假设客户端已提前在授权服务器上注册。MCP 使用基于 URL 的客户端标识符（客户端元数据从 URL 获取而非预注册），启用了零信任模式：任何 MCP 客户端都可以连接到任何 MCP 服务器，信任通过授权服务器动态建立，而非通过带外协调。

实际含义：如果你在构建连接 MCP 服务器的智能体，你需要一个支持动态服务器元数据发现、令牌请求中的资源指示符和每服务器令牌绑定的 OAuth 2.1 客户端。通用 OAuth 库可以使用，但需要仔细配置以满足所有这些要求。

最小可行授权架构

对于首次正确处理这个问题的团队，组件包括：

身份层：每个智能体拥有自己的服务账户和唯一标识符。智能体之间不共享凭证。这对于归因来说是不可妥协的。

授权服务器：集中式服务器（Auth0、Okta、WorkOS 或自托管），签发短期令牌、在每次请求时验证它们，并维护撤销列表。分布式令牌验证会使即时撤销失效。

范围注册表：可用范围的机器可读目录，哪些智能体可以请求哪些范围，以及提升操作所需的逐步授权是什么。

委托链执行：父级智能体不能授予子智能体自己不持有的范围。授权服务器在令牌交换时强制执行这一点，而不是通过应用逻辑。

双重身份日志：每个令牌携带 sub（委托用户）和 act（执行智能体）声明。每个日志条目捕获两者。

撤销界面：用户可以看到哪些智能体被授权代表他们行事，并一键撤销该授权。这是产品需求，不仅仅是合规复选框。

这比大多数团队为他们的第一个智能体构建的基础设施要多。诱惑在于从 API 密钥和长期服务令牌开始，因为它们更容易实现。作为原型这没问题，但一旦智能体投入生产，这是昂贵的技术债务——因为你没有构建的审计跟踪已经消失，你没有正确限定范围的凭证已经接触了真实数据。

授权不是构建智能体中有趣的部分。但它决定了你是否能够安全地大规模运营它们——而现在，随着智能体 AI 从原型走向生产，从一开始就正确设计授权模型是你能做的最高杠杆的事情。