智能体授权委托（Agentic Auth）

传统方案在智能体场景暴露两类缺陷。静态长期 API Key 不携带「替谁执行」的信息：一旦泄露或被提示注入攻击劫持，攻击面是智能体可访问的全部资源，且无法按任务收敛。复用人类会话 Cookie 则制造身份混同：审计日志显示的是用户在操作，看不到智能体这一中介，出事后无法区分是用户意图还是智能体自主行为。

更隐蔽的风险是权限放大：智能体往往被授予用户的全量权限，而实际任务只需要其中一个很小的交集。若上游资源服务器只校验智能体的 API Key 而不感知发起任务的人类用户，访问控制就退化为「有 Key 即通过」。

IETF 草案 draft-klrc-aiagent-auth 于 2026 年 3 月提交，其立场是智能体授权不需要新协议：OAuth 2.0 本身就是委托授权框架。智能体在用户委托场景下充当 OAuth 客户端，走授权码流程获得用户明确批准的有限授权；智能体以自身（或所属系统）名义行动时，走客户端凭证流程或 JWT 授权，并明确要求不用静态长期密钥认证。

访问令牌以 JWT 形式承载授权语义：client_id 声明智能体身份，sub 声明被代理的用户或系统，配合 aud、scope 与其他上下文声明，资源服务器据此判定是否放行。对不透明令牌则通过令牌内省端点获取等效属性。草案同时标注：策略与合规部分仍在完善中。

委托令牌的关键是把完整的执行上下文写进声明：sub 标识发起任务的人类用户（如 user:alice），act 标识执行调用的智能体（如 agent:support-copilot），aud 把令牌绑定到特定资源服务器（如 gmail-api），scope 限定具体动作（如 email.draft 而非 email.send），exp 压缩到 5 至 30 分钟，另附租户声明与任务标识把调用挂回原始任务。

这套结构以密码学方式强制「用户、智能体、上下文」三者交集：资源服务器在放行前校验全部三项。配套的 RFC 组合补足边界——RFC 8707 资源指示符确保为日历服务签发的令牌不能重放到 CRM；RFC 8693 令牌交换让宽泛的用户令牌被逐跳兑换为降权的智能体令牌；RFC 9449 DPoP 发送方约束使被截获的令牌在没有客户端私钥时无法使用。

行业讨论正在收敛出两层身份模型：工作负载身份（如 SPIFFE 的 SVID 凭证）证明「这个智能体是谁、属于哪个信任域」，且短时效、自动轮换；委托授权（OAuth 令牌）证明「它此刻被允许做什么、替谁做」。智能体用工件身份去获取委托令牌，两层各答一个问题。

围绕这一模型，IETF 相关工作组（如 WIMSE）在推进智能体场景的工作负载凭证格式；跨域身份链、事务令牌等上层件尚处草案阶段。行业共识是：先用已生产化的两层（SPIFFE 加 OAuth）落地安全的主干，上层的跨域与策略件保持观察、暂不作为地基。

综合身份厂商与安全团队的实践建议，智能体授权委托的控制基线包括六条：其一，在运行时的每一次调用中同时建模用户、智能体与上下文三元组；其二，OIDC 登录与 OAuth 工具授权严格分离，防止身份混同；其三，令牌短时效、限范围、绑受众，并经令牌金库按用户、按服务商隔离存储与自动刷新；其四，读取与起草类低风险动作同步执行，发送、删除、提交等不可逆动作走带外人工审批；其五，每次工具调用前经集中策略引擎在毫秒级完成用户、智能体、租户、动作、资源、任务的交集判定；其六，全链路审计日志记录委托链与每一次批准。

与本站其他词条的分工：非人类身份治理（NHI）关注智能体身份的清单、责任人与企业级治理流程；MCP 安全关注工具协议层的鉴权机制；提示注入关注攻击路径本身。本词条聚焦逐次调用的授权协议机制，四者共同构成智能体访问安全的完整拼图。

智能体授权委托的标准化正在加速：IETF 草案明确了复用 OAuth 的主干路线，SPIFFE 与 WIMSE 补齐工作负载身份层，跨域身份链与事务令牌等上层件仍在草案阶段。与此同时，MCP 等工具协议的授权模型、支付领域的委托意图机制与本词条的授权协议栈正在相互借鉴。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。