agent 授权的含义
agent 授权是关于 AI agent 可以做什么的决策: 它可以调用哪些 route，可以读取哪些数据，可以采取哪些操作，以及操作频率有多高。它不同于 agent 身份，后者是要确认发起请求的是哪个 agent，或者是哪个操作者的 agent。
这两者很容易混淆，因为它们经常同时出现。已签名的请求会告诉你是谁发出的，但不会告诉你这个发送方是否应该被允许修改账户、下单或导出数据。身份是证据; 授权是 policy。我们关于已签名的 AI agent 请求能证明什么，以及不能证明什么的文章详细解释了这一差异。
为什么这种区分很重要
应用在面向人类用户时，通常已经把身份验证和授权分开: 登录可以证明你是谁，而角色和权限决定你可以做什么。agent 也需要同样的分离，只是还要多一层谨慎:
- 身份可以很强，但权限可能不存在。 一个带有完全有效HTTP message signature的爬虫，并不天然有权调用写入端点。
- 权限可以存在，但身份并不充分。 使用客户 API key 的 agent 由该 key 授权，即使没有任何信息能识别持有它的具体 agent 软件。
- agent 背后的人很重要。 当 agent 代表某个人行动时，问题就变成这个人是否授予了它权限(参见委托权限)。
把这些合并成一次检查会导致两种失败模式: 因为缺少人类登录而阻止合法自动化，或者信任一个身份明确的 agent 去执行它本不该执行的操作。
授权通常如何表达
大多数应用会用它们已有的机制来给 agent 授权:
- 凭证和范围。 具有仅限于集成所需范围的 API key 或OAuth 2.0 token。MCP server 采用同样的模型: MCP authorization specification把受保护的 server 视为 OAuth 2.1 资源 server。
- route 级 policy。 已知 agent 可访问只读 route; 写入 route 需要绑定到账户的凭证。
- 风险分级。 低影响操作广泛允许，高影响操作需要更强的凭证、确认或审核。
- 速率限制和配额，按操作者、凭证或 route 维度设置。
agent 身份证据会作为这些决策的一个输入。更完整的做法见为人类和 AI agent 设计应用级 policy。它让你可以对已验证的操作者和匿名客户端区别对待，但权限本身仍然来自你的 policy。
常见误解
- “已验证的 agent 就意味着被允许。” 验证只是在归属一次请求。你的 policy 仍然决定这个被归属的主体可以做什么。
- “除非证明是人类，否则 agent 都应被阻止。” 许多 agent 都是合法参与者。更好的问题是不同类型的 actor 应该在每条 route 上被允许做什么。
- “可以根据行为推断出授权。” 行为可以提高或降低对当前 actor 类型的信心，但不应单独赋予权限。
Proof of Actor 如何处理这件事
Proof of Actor 回答的是证据问题: 当前是什么类型的 actor，依据是什么(Verified、Declared、Inferred 或 Unknown)，以及已知什么、未知什么。它刻意不决定权限。即使是 Agent 结果，哪怕是已验证的结果，也绝不意味着授权。在 Route 中，你的应用会把 actor 结果与自己的凭证、范围和风险分级结合起来，对每次交互执行 allow、adapt、challenge、review 或 rate-limit，并且先以 observation 模式开始，这样你就可以在真正 enforce 之前检查结果。
进一步了解决策如何融入你的 app，查看 APIs 和 MCP servers 的使用场景，或申请早期访问。
来源
- RFC 6749: The OAuth 2.0 Authorization Framework: 面向客户端的范围限定 token
- MCP specification 2026-07-28: Authorization: 面向 MCP server 的基于 OAuth 的授权
- RFC 9421: HTTP Message Signatures: 已签名请求所建立的内容