Amazon Bedrock AgentCore 联合 Okta XAA 实现 AI 代理访问治理与统一授权

一句话结论

亚马逊云科技（AWS）发布基于 Okta 跨应用访问（Cross App Access，XAA）的 AgentCore 架构，通过 Gateway 统一治理 AI 代理的访问权限与身份链路。

关键要点

• 新架构引入 Amazon Bedrock AgentCore Gateway 作为统一入口，替代代理直接持有模型上下文协议（MCP）服务器运行时 ARN 的方式，并执行令牌交换与持有目标注册表。
• Gateway 采用默认拒绝的 Cedar 策略集评估授权，取代了此前复制在多个服务中的 groupscheck 逻辑；策略以 ENFORCE 模式附加在 AgentCore 引擎上，仅编写 permit-only 策略，并需用 hasTag 保护标签。
• 入站授权器颁发者为 Okta 组织授权服务器，受众为自定义授权服务器，通过 allowedClients 绑定特定代理；出站授权通过 TOKEN_EXCHANGE 机制使用凭证提供商，目标 scopes 必须与 ID-JAG 相等。
• 测试数据显示，Gateway A 在 24 小时数据中，身份与策略检查 p50 总和约 0.2 秒，MCP 服务器 authz.check 少于 1 毫秒；Gateway B 的 GetResourceOauth2Token p50 为 408 毫秒。
• 前置条件包括 eksctl、kubectl、Docker 及特定 IAM 权限，配置耗时约 90 分钟；成本包括 EKS 控制平面每小时 0.10 美元及节点费用。

背景与事实

亚马逊云科技（AWS）机器学习教育博客（AWS Machine Learning Blog）发布了关于使用 Okta 跨应用访问（Cross App Access，XAA）治理人工智能代理访问权限的第二部分实战指南。该架构核心在于通过 Amazon Bedrock AgentCore Gateway 实现任务代理签署用户行动，拓扑包含代理、两个模型上下文协议（MCP）服务器，且授权检查写入每个服务器。Gateway 的引入取代了代理直接持有 MCP 服务器运行时 ARN 的方式，它作为统一入口执行令牌交换并持有目标注册表。在授权逻辑上，Gateway 使用默认拒绝的 Cedar 策略集评估授权，替代了此前在多个服务中复制的 groupscheck 逻辑。

该架构新增了运行在亚马逊弹性 Kubernetes 服务（Amazon EKS）上的代理 B，该代理使用独立 Okta 身份通过 Gateway 接入。Agent A 转发 ID-JAG 到 Gateway，其角色不再持有令牌交换权限；Agent B 拥有独立 Okta 注册，资源连接仅允许 xaa:read。EKS Pod Identity 授予 IAM 角色，并使用亚马逊云科技针对 OpenTelemetry 的发行版（AWS Distro for OpenTelemetry，ADOT）导出跟踪。AgentCore Observability 位于代理与 CloudWatch 之间，无需代码变更即可发出 OpenTelemetry span，工具调用产生 span 链，记录 Gateway、Policy、Identity 及 MCP 服务器决策。此外，Okta System Log 需导入以记录 AWS 无法发出的数据。

在实施细节上，MCP 服务器作为 Gateway 目标，出站授权通过 TOKEN_EXCHANGE 机制使用凭证提供商。目标 scopes 必须与 ID-JAG 相等，每个目标需设置静态工具架构，listingMode 设为 DEFAULT 并包含内联 mcpToolSchema。Gateway 按目标分页 tools/list，客户端需跟随游标。AgentCore Identity 保留交换令牌，单次 ID-JAG 服务于会话所有工具调用，5 分钟有效期内可开启第二个会话。测试结果显示，用户 Alice 和 Carol 在 Gateway A 下 create_task 被拒，Bob 成功；Bob 在 Gateway B 下因 Cedar 策略拒绝。错误请求返回 HTTP 403 或 401。

该架构基于 GitHub 示例 08-okta-xaa-delegation-chain，代码为生产环境外示例。前置条件包括 eksctl、kubectl、Docker 及特定 IAM 权限，配置耗时约 90 分钟。成本包括 EKS 控制平面每小时 0.10 美元及节点费用。技术清理需删除第 2 部分资源并执行 eksctl delete cluster。该架构适用于媒体娱乐、金融、医疗等行业，旨在确保大量 AI 代理受同等治理。

影响分析

对于中文开发者与从业者而言，这一架构的落地意味着 AI 代理的治理模式从“分散式令牌持有”向“集中式网关授权”转变。在实际影响上，开发者不再需要为每个 MCP 服务器维护独立的 groupscheck 逻辑，而是通过 Gateway 的 Cedar 策略实现统一管控。这种变化降低了多代理环境下的安全审计复杂度，特别是当企业需要让不同代理（如 Agent A 和 Agent B）访问同一组工具但拥有不同权限时，Gateway 的默认拒绝机制提供了更清晰的安全边界。

此外，AgentCore Observability 的集成使得追踪链路更加透明。开发者无需修改代码即可通过 OpenTelemetry span 查看 Gateway、策略、身份及 MCP 服务器的决策日志，这对于排查 401/403 错误至关重要。结合测试数据中 Gateway A 身份与策略检查 p50 总和约 0.2 秒、MCP 服务器 authz.check 少于 1 毫秒的表现，开发者可以在保证安全性的同时接受较低的延迟开销。然而，配置前置条件（eksctl、kubectl、Docker 及 IAM 权限）耗时约 90 分钟，且涉及 EKS 控制平面每小时 0.10 美元的成本，这要求团队在引入该架构前评估运维成本与人力投入。

适用边界

该结论主要适用于已采用 Okta 作为身份提供商、并使用 Amazon Bedrock AgentCore 构建多代理系统的中大型企业场景。它不适用于尚未部署 Okta 或无法使用 Amazon EKS 的环境，因为架构强依赖于 EKS Pod Identity 授予 IAM 角色以及 ADOT 导出跟踪。此外，文中代码基于 GitHub 示例 08-okta-xaa-delegation-chain，明确标注为生产环境外示例，直接用于生产系统需自行补充安全加固与高可用设计。对于单体代理或无需复杂跨应用授权的场景，引入 Gateway 与 Cedar 策略可能增加不必要的复杂度。

孤本观察

基于本次发布，可以判断 AWS 正试图通过 Gateway 与 Cedar 策略的组合，将传统 IAM 精细化权限控制的理念延伸至 AI 代理工具调用层面。编辑认为，这种“默认拒绝”加“静态工具架构”的设计，旨在解决多代理环境下权限蔓延与令牌滥用问题，但 90 分钟的配置耗时表明其部署门槛仍高于单服务应用。

来源：AWS Machine Learning Blog