当 On-Behalf-Of 悄然变成 Act-As：你的智能体继承的 OAuth 作用域陷阱

安全审查称智能体（Agent）“代表”（on behalf of）用户操作。OAuth 令牌却有不同的说法，而审计日志也支持令牌的说法。

语言上的一点微小差别，在架构层面起到了意想不到的作用。“代表”（On behalf of）是安全审查在试图描述一种委派安排时使用的语言，即智能体是一个可识别的委派对象，并受此身份约束。“作为”（Act as）则是运行时的行为，此时智能体持有的令牌与用户本人的令牌完全一致，因此在任何下游系统看来，智能体就是用户。这两个短语描述了完全不同的威胁模型。典型的企业级 OAuth 集成交付的是后者，但宣传的却是前者。

鸿沟在第一次出问题时显现。一段提示词注入（Prompt-injected）指令通过一封要求智能体总结的邮件传达。智能体执行了注入指令中的操作。审计日志将该用户记录为作者。调查最初会针对该用户进行人事审查，然后才会有人质疑是否有智能体参与其中，因为运行时的踪迹中没有任何信息表明存在智能体。

审查批准了委派，令牌批准了冒充

在我见过的所有集成中，这种模式都是一致的。产品团队搭建了一个 OAuth 流程，向智能体授予了一个限定在用户身份范围内的令牌。安全审查阅读了集成规范，看到了“智能体代表用户操作”，并基于下游系统能够区分委派操作和直接操作的假设批准了它。但从 IdP 返回的令牌是一个用户形态的令牌，其形状与用户直接登录时持有的令牌完全一致。

下游系统并不在对话范围内。日历服务、邮件服务、文档存储——它们每一个都会验证令牌，将持票人识别为用户，然后继续执行。令牌上没有任何字段说明“此操作是由智能体发起的”。下游服务也不需要读取任何特定的请求头。审计追踪按用户 ID 记录操作，因为这是请求携带的唯一身份。安全审查批准的架构意图只存在于设计文档中，而没有体现在任何传输格式里。

这正是 RFC 8693 的 actor (act) 声明（claim）旨在弥补的差距。该规范定义了一个 JWT 字段，旨在“在 JWT 中提供一种方式来表达已发生委派，并识别获得授权的执行方”。委派链可以嵌套——最外层的 act 是当前的执行者，内部的声明则保留委派链。针对 AI 智能体的 OAuth “代表”扩展的 IETF 草案以此为基础，增加了将智能体身份贯穿授权屏幕并进入所颁发令牌的参数。但这些机制只有在下游系统读取它们时才起作用，而 2026 年的大多数生产环境服务并不会读取。

实际后果是，除非令牌机制强制执行，否则“代表”只是一个安全主张，而非技术现实。一个向智能体授予用户形态令牌的团队，实际上是将用户的全部身份交给了一个运行时，而该运行时的决策是由一个并不知道自己在冒充他人的模型做出的。

提示词注入将冒充演变为安全事件

当集成运行良好时，这种差距是隐形的。智能体按照用户的要求行事，审计追踪看起来也像是用户做的，这在广义上是准确的。架构的失效模式在智能体第一次执行用户未要求的操作时显现——而在 2026 年，触发这种模式最可靠的方式就是提示词注入。

这种威胁模型已广为人知。智能体在工作中读取不可信的内容——邮件正文、文档、日历邀请或网页。内容中包含一条指令。模型将该指令视为其工作上下文的一部分并遵循它。指令可以要求智能体发送邮件、共享文档、安排会议，或者调用该智能体令牌作用域内的任何其他工具。由于智能体的令牌是用户形态的，它会毫无障碍地授权所有这些操作。

三个步骤接踵而至：

1. 智能体利用用户的身份执行注入的操作。
2. 下游系统将该操作记录为用户发起的。
3. 用户的经理或安全团队查看审计追踪，并将用户视为执行者。

加载中…