用 Okta Cross App Access 与 Amazon Bedrock AgentCore 管控 AI 智能体访问（上篇）

该方案把治理与执行分成两层：Okta 作为治理平面，决定哪个智能体可以代表哪个用户、访问哪个资源；Amazon Bedrock AgentCore Identity 作为执行平面，保管智能体凭据，把 Okta 的决策换成资源可接受的短期访问 token，并在 token 中同时保留用户与智能体两个身份。智能体与它调用的两个 MCP 服务器都运行在 AgentCore runtime 上。 每个请求携带三种 token，各自记录不同决策：ID token 表明用户身份，Identity Assertion JWT Authorization Grant（ID-JAG）是 Okta 的授权决定，访问 token 则是资源实际接受的凭证。流程上，用户通过 OpenID Connect 登录前端 BFF，BFF 以智能体身份在 Okta 组织授权服务器用 RFC 8693 token exchange 把用户 ID token 换成 ID-JAG；Okta 校验智能体处于激活状态、用户已分配给它、管理员已将其连接到目标授权服务器且覆盖所请求的 scope。ID-JAG 一次性使用，5 分钟过期。 BFF 以 ID-JAG 为 bearer token 调用 AgentCore runtime，runtime 的 JWT authorizer 只接受 Okta 签发给该智能体的 ID-JAG。runtime 从 AgentCore Identity 取得绑定智能体工作负载身份与用户的工作负载访问 token，该 token 为 AWS 内部绑定凭证，Okta 与资源都看不到。随后 AgentCore Identity 以智能体身份在资源的 Okta 自定义授权服务器用 RFC 7523 JWT authorization grant 兑换 ID-JAG，得到 5 分钟访问 token，其中同时标明用户与智能体并携带用户组信息，智能体用它调用 MCP 服务器，任务管理器再校验 token 来源、用户组与 scope。 配置侧需要在 Okta 为资源创建自定义授权服务器（audience 为 api://task-manager，自定义 scope 为 xaa:read 与 xaa:write），并在访问 token 中加入以 xaa- 开头的组声明；注册 AI 智能体并创建关联的 OpenID Connect 应用，二者共享同一 client ID，且必须由该应用完成用户登录。自定义授权服务器还需添加允许智能体 JWT Bearer grant 的访问策略规则，访问 token 生命周期设为 5 分钟，该时长决定了撤销授权后仍可继续工作的上限。 AgentCore Identity 侧需创建 OAuth2 凭据提供方，指向自定义授权服务器，以智能体身份认证，并将 on-behalf-of grant 设为 JWT_AUTHORIZATION_GRANT。由于 Okta 将两次交换都绑定到 ID-JAG 中的 client，每个 Okta 智能体都需要独立提供方。client secret 存放在服务托管的 AWS Secrets Manager 中，也可引用自有 secret 的 ARN 以便轮换；还可用私钥 JWT 替代共享密钥。文中提到，最初版本在请求头中查找工作负载访问 token 未果，21 个请求全部回退到另一次调用，正确做法是从 BedrockAgentCoreContext 读取。该文为上篇，下篇将把同样的治理放到 AgentCore Gateway 上，配合 Cedar 策略、运行在 Amazon EKS 上的第二个智能体以及 CloudWatch 审计轨迹。