企业 Agent 的 OAuth 难题：同意、会话绑定与令牌金库必须是一条链
2026 年 9 月 14 日，AWS 发布 Amazon Bedrock AgentCore 的终端用户 OAuth 同意管理：用户通过企业身份提供方登录，在托管 Consent Portal 中对 GitHub、Slack 等资源授权，AgentCore Gateway 再从 Token Vault 获取该用户的令牌调用工具。
这项更新的价值不只是少写一个 OAuth 回调页面。它把企业 Agent 的真实身份链暴露出来：服务负责运行 Agent，用户决定可以访问什么，外部 SaaS 签发委托，而一次会话必须证明自己仍代表当初授权的人。任何一环模糊，Agent 都可能从“代用户办事”滑向“持共享超级账号办事”。
用户同意不是永久通行证；它必须绑定主体、资源、范围、会话和有效期。
三种身份不能折叠
第一种是 workload identity，回答“哪个部署或 Agent 正在请求”；第二种是 user identity，回答“它代表谁”；第三种是 tool authorization，回答“外部系统允许这个用户做什么”。模型本身不应持有任何长期凭证，只接收工具执行结果。
网关应在每次调用时校验 (agent, user, session, provider, scopes)。即使用户曾授权 GitHub，也不代表所有 Agent、所有会话都能复用。尤其在 IDE 与 MCP 场景中，一个客户端可能同时打开多个仓库；授权若只绑定浏览器 cookie，很容易发生跨项目串权。
Session Binding 是防止“借来的同意”
OAuth 的 state、PKCE 和回调验证只能保证授权流程没有被简单劫持，还需要把授权结果绑定到发起会话。可靠流程会生成一次性 challenge，将会话 ID、用户主体与目标 provider 写入服务端状态；回调完成后，只有原会话可以兑换令牌引用。
令牌引用也不能直接进入 prompt 或轨迹。Token Vault 保存实际 access/refresh token，运行时只拿不可逆句柄；网关在策略通过后代为注入。撤销用户、终止会话或缩减 scope 时，句柄应立即失效，而不是等待缓存过期。
Consent UX 需要解释动作而非协议名
“允许访问 GitHub”太宽泛。用户需要看到 Agent 将读取哪些仓库、是否创建 PR、是否代表用户发表评论，以及授权持续多久。高风险写操作最好采用渐进式同意：首次只读，真正提交代码时再请求写权限；支付、删除和对外发送则在每次动作前确认。
同意页面还应展示触发 Agent 的业务任务与所属组织，防止用户只因为熟悉 OAuth 页面就机械点击。对无人值守 Agent，则不应伪造“用户同意”，而要走服务账号、预批准策略和变更窗口。
审计必须能重建授权链
官方方案提到 GetResourceOauth2Token、CompleteResourceTokenAuth 和 GetWorkloadAccessTokenForJWT 等 CloudTrail 事件。企业还应把它们与 Agent 运行、策略决策和具体工具调用关联。事故调查时要能回答：谁在何时授权了哪些 scope，哪个会话兑换了令牌，哪次工具调用实际使用了它，用户何时撤销。
最小验收包括跨用户、跨会话、过期刷新、撤销后重放和并发授权五类测试。OAuth 页面能够打开只是功能完成；只有身份传播、会话绑定、最小权限、令牌隔离和审计全部闭环，企业 Agent 才真正具备“代表用户”的资格。