委派授权的含义
委派授权是一个人（或组织）授予 AI 代理代表其行事的权限。当助手在你的日历中预订会议、以你的名义提交支持工单，或从供应商门户检索发票时，它行使的是源自你的授权。
良好的委派有三个特征: 它是有范围限制的（代理可以做某些事情，但不是所有事情），有时间边界的（会过期或可以撤销）并且可归因的（接收应用可以判断正在行使的是谁的授权）。
为什么它对应用很重要
从应用的角度看，代理请求会引出最多三个独立问题:
- 这是谁发送的客户端？ 这就是代理身份，已签名请求可以证明这一点（参见 HTTP Message Signatures）。
- 它是以谁的授权在行事？ 这就是委派。
- 这项授权是否足以执行该操作？ 这就是授权，由应用自身的策略决定。
来自知名助手运营方的已签名请求可以很好地回答第一个问题。它本身并不能说明第二个问题。该助手可能是在为你的某个用户、为并非你的用户的人，或者完全基于自身发起的行动。把客户端身份当作某个人同意的证明，是面向代理设计中最常见的错误之一。参见已签名的 AI 代理请求能证明什么，不能证明什么。
委派通常如何表达
- OAuth 风格的授权。 个人登录你的应用，并授予代理一个作用域受限的 token，具体由 OAuth 2.0 (RFC 6749) 定义。这样你的应用就能准确知道这个 token 携带的是谁的授权，而且该授权可以被撤销（RFC 7009）。
- 账户范围内的 API keys，由用户为某个特定集成创建，理想情况下权限应尽量收窄。
- 应用内确认，用于高影响操作，由个人批准代理准备执行的具体动作。
- token 级委派声明。 OAuth 2.0 Token Exchange（RFC 8693）定义了一个
act（actor）声明，用于记录一方代表另一方行事。关于在请求中表达代理委派的更新工作仍在发展中，应用应将任何委派声明与自身记录进行核验，而不是直接按表面含义接受。
常见误解
- “如果代理已验证，说明用户批准了它。” 验证的是客户端。批准必须来自个人，并通过你的应用信任的渠道完成。
- “代理使用我用户的 session 是可以的。” 也许可以，但该 session 是为交互式人工使用而签发的。许多应用更倾向于为自动化使用专门的、作用域受限的授权，这样操作才可归因且可撤销。
- “委派不是全有就是全无。” 最安全的委派是窄范围的: 广泛开放读取权限，仅对特定操作开放写入权限，并对任何不可逆操作要求确认。
Proof of Actor 与它的关系
Proof of Actor 帮助你看清一次交互是否由代理驱动或由 AI 辅助，以及其依据是什么: Verified、Declared、Inferred 或 Unknown。这个上下文能告诉你委派问题会在哪里出现，例如一个autonomous agent在人工账户会话中运行。Proof of Actor 不会签发或验证委派凭证，而 Agent 结果也绝不意味着某个人授权了该操作。这个判断由应用自身的授权、作用域和确认机制决定，而在你观察到真实流量之后，Route 让你可以针对每条 route 应用合适的策略。有关策略模式，参见为人类和 AI 代理设计应用层策略。
阅读证据能证明什么，不能证明什么，或申请提前访问。
来源
- RFC 6749: The OAuth 2.0 Authorization Framework: 从资源所有者到客户端的作用域授权
- RFC 7009: OAuth 2.0 Token Revocation: 撤销委派 token
- RFC 8693: OAuth 2.0 Token Exchange: 用于委派的
act（actor）声明