用 Okta Cross App Access 与 Amazon Bedrock AgentCore 治理 AI 智能体访问（第二部分）

这是 Okta Cross App Access（XAA）与 Amazon Bedrock AgentCore 系列的第二部分。第一部分搭建了一个任务智能体，运行在 AgentCore runtime 上，通过 Okta XAA 代表已登录用户行动，由 AgentCore Identity 在智能体内部兑换 Okta 的授权。但那套拓扑只有一个智能体、两个 MCP 服务器，授权检查写在各服务器代码里，规模一大就难以为继：N 个智能体对 M 个服务器形成布线矩阵，每个智能体都要持有令牌交换权限和密钥读取权限，同一套分组校验复制到成千上万个服务器后无法统一审计和修改。 第二部分保留第一部分的 Okta 配置、AgentCore Identity 凭证提供程序和 MCP 服务器，新增 AgentCore Gateway 作为唯一前门。用户登录后，BFF 用 ID token 换取签发给任务智能体（agent A）的 ID-JAG，agent A 把 ID-JAG 作为 MCP 会话的 bearer token 转发给 Gateway；Gateway 的入站授权器只接受签发给 agent A 的 ID-JAG，其 issuer 为 Okta 组织授权服务器，audience 为自定义授权服务器，allowedClients 锁定单个智能体。Cedar 策略在每次工具列举和工具调用前于 Gateway 上评估，被拒绝的调用不会去 Okta 兑换 ID-JAG；被允许的调用由 Gateway 通过第一部分的凭证提供程序，以 TOKEN_EXCHANGE 方式为每个目标兑换。智能体执行角色因此不再需要令牌交换或密钥权限。 实现上有几个细节：目标的作用域必须与 ID-JAG 一致；每个目标要配置静态工具 schema（listingMode 设为 DEFAULT 并内联 mcpToolSchema），因为测试中引用工具名的策略无法挂到动态列举的目标上；Gateway 按目标分页返回 tools/list，客户端必须跟随分页游标。AgentCore Identity 会保留 Gateway 兑换得到的令牌，因此一个一次性 ID-JAG 可服务会话内所有工具调用，测试中在其 5 分钟有效期内还能开启第二个会话。由于一个凭证提供程序只能以一个 Okta 智能体身份认证，每个智能体需要自己的 Gateway 和提供程序。 Cedar 策略以 ENFORCE 模式挂到 Gateway，只写 permit 策略，并用 hasTag 保护每个标签读取：读取缺失标签的策略会报错并被跳过，被跳过的 permit 不授予任何权限，默认拒绝依然成立。作用域标签保存 ID-JAG 中以空格分隔的 scope 声明，因此用四个条件确保 xaa:write 作为完整条目匹配，xaa:write-admin 不会命中。挂载前需确认所有策略为 ACTIVE，否则 Gateway 会拒绝所有调用。 第二个智能体（报告智能体 agent B）运行在 Amazon EKS 上，拥有自己的 Okta 注册、Gateway 和凭证提供程序，资源连接只允许 xaa:read，通过 EKS Pod Identity 获得仅能调用模型和写自身日志追踪的 IAM 角色，用 ADOT SDK 导出追踪。由于 Pod 前没有授权器，agent B 在调用模型前自行校验 ID-JAG 的签名、issuer、audience、token 类型 oauth-id-jag+jwt、有效期和 client_id。两个坑：EKS Auto Mode 通用节点池只跑 amd64，需构建多架构镜像；AgentCore Python SDK 除非设置 DOCKER_CONTAINER=true，否则绑定 localhos…