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

在 第 1 部分中，你在 Amazon Bedrock AgentCore（一个可用任意框架或模型大规模构建、连接和优化智能体的平台）上构建了一个任务智能体。该智能体运行于 Amazon Bedrock AgentCore runtime（Amazon Bedrock AgentCore 的一项能力），并通过 Okta Cross App Access（XAA）代表已登录用户执行操作。Okta 决定哪个智能体可以代表哪个用户，而 Amazon Bedrock AgentCore Identity（Amazon Bedrock AgentCore 的一项能力）在智能体内部兑换 Okta 的授权。这证明了治理机制的有效性，而且它运行在一个刻意保持精简的拓扑上：一个智能体、两个 Model Context Protocol（MCP）服务器，以及写入每个服务器代码中的授权检查。

这套机制可以扩展，但拓扑不能。对于单个智能体和两个工具来说还算轻松的三件事，在拥有数百个智能体和数千个工具的企业中就成了繁重的工作：

在本文中，你将在第 1 部分的解决方案上完成这一转变。Amazon Bedrock AgentCore Gateway（Amazon Bedrock AgentCore 的一项能力）将成为唯一的统一入口，并为每个目标兑换 Okta 的授权。Amazon Bedrock AgentCore 中的策略功能会评估 Cedar 策略，将每个工具与智能体以及 Okta 委派的范围绑定。第二个运行在 Amazon Elastic Kubernetes Service（Amazon EKS）上的智能体以其自身的 Okta 身份加入，以展示这个统一入口并不关心智能体运行在哪里。此外，Amazon Bedrock AgentCore Observability（Amazon Bedrock AgentCore 的一项能力）与 Amazon CloudWatch 为你提供一个地方，可以查看每一个决策（包括 Okta 的决策）。我们还会将 XAA 与基于用户的 OAuth 同意机制进行比较，以适用于无法接受 Okta 授权的应用程序。

相对于第 1 部分的变化

第 1 部分中的 Okta 配置、AgentCore Identity 凭证提供商和 MCP 服务器保持原样。图 1 展示了加入新组件后的架构。

图 1：第 1 部分的解决方案，加入 AgentCore Gateway、Policy 和 Observability、运行在 Amazon EKS 上的第二个智能体以及审计路径，编号与后续步骤对应

1. 用户登录后，backend for frontend（BFF）将 ID 令牌交换为发给任务智能体（智能体 A）的 Identity Assertion JWT Authorization Grant（ID-JAG），与第 1 部分相同。
2. BFF 使用 ID-JAG 在 AgentCore runtime 上调用智能体 A。
3. 智能体 A 将 ID-JAG 作为其 MCP 会话的 bearer 令牌转发给其 Gateway。Gateway 的入站授权器只接受智能体 A 的 ID-JAG。
4. 在 Gateway 调用目标之前，AgentCore 中的策略功能会针对每个工具列表和每次工具调用评估 Cedar 策略。
5. 对于 Cedar 允许的调用，网关让 AgentCore Identity 通过第 1 部分的凭证提供程序，在 Okta 的自定义授权服务器上为每个目标兑换 ID-JAG。被 Cedar 拒绝的调用则不会兑换 ID-JAG。
6. MCP 服务器像第 1 部分那样检查用户的组和作用域，并将每项决策记录为一个 authz.check span。
7. 每一跳都会向 AgentCore Observability 发送 OpenTelemetry span，由 CloudWatch Transaction Search 采集；Okta 则通过 Amazon EventBridge 将其 System Log 流式传输到 CloudWatch。

报告智能体（即智能体 B）运行在 Amazon EKS 上，并经由自己的网关遵循相同的路径。

先决条件

除了第 1 部分的解决方案之外，你还需要以下内容：

这些新增内容大约需要 90 分钟。EKS 控制平面每小时收费 $0.10，另有节点费用和 Amazon EKS Auto Mode 管理费，AgentCore 功能按使用量计费。请参阅 Amazon EKS 定价和 Amazon Bedrock AgentCore 定价。

与第 1 部分一样，本解决方案的基础是 GitHub 上的 AWS 示例 08-okta-xaa-delegation-chain，你可以在此基础上构建第 2 部分的新增内容。除该示例外，本文中的代码片段和配置仅从概念上展示该模式，并不是完整可部署的解决方案。代码是供非生产用途使用的示例代码，因此在部署之前，请与你的安全和法务团队合作，以满足组织的安全、监管和合规要求。

创建一个接受 ID-JAG 的网关

网关的入站授权器的工作方式与第 1 部分中的运行时授权器类似。其签发者是 Okta 的组织授权服务器，其受众是自定义授权服务器，并且 allowedClients 将其固定到单个智能体：

authorizer = {"customJWTAuthorizer": {
    "discoveryUrl": f"{OKTA_ORG}/.well-known/openid-configuration",  # the ID-JAG's issuer
    "allowedAudience": [f"{OKTA_ORG}/oauth2/{CUSTOM_AS_ID}"],         # the resource's authorization server
    "allowedClients": [AGENT_CLIENT_ID],                               # only this agent's ID-JAGs
    "allowedScopes": ["xaa:read", "xaa:write"],
}}

图 2 展示了最终的入站授权器。

图 2：网关只接受 Okta 为该资源的授权服务器签发给智能体的 ID-JAG

每个 MCP 服务器都成为一个网关目标，其出站授权通过第 1 部分的凭证提供程序使用 TOKEN_EXCHANGE，因此网关会执行第二次交换：

"credentialProviderConfigurations": [{
    "credentialProviderType": "OAUTH",
    "credentialProvider": {"oauthCredentialProvider": {
        "providerArn": provider_arn,          # the JWT_AUTHORIZATION_GRANT provider from Part 1
        "scopes": ["xaa:read", "xaa:write"],  # must equal the ID-JAG's scopes
        "grantType": "TOKEN_EXCHANGE",
    }},
}]

图 3 展示了按此方式配置的目标。

图 3：task manager 目标通过第 1 部分的凭证提供程序兑换 ID-JAG

这里有三个细节很重要。第一，与第 1 部分一样，目标的作用域必须与 ID-JAG 的作用域一致。第二，为每个目标提供一个静态工具架构（将 listingMode 设置为 DEFAULT，并使用内联的 mcpToolSchema），这样在编写 Cedar 策略时，策略所引用的工具名称就已固定。在我们的测试中，引用了工具名称的策略也无法附加到动态列出的目标上。第三，网关按目标对 tools/list 进行分页，因此你的客户端必须跟随分页游标，否则后面目标的工具将会消失。AgentCore Identity 会保留网关交换得到的令牌，因此一个单次使用的 ID-JAG 可服务于会话中的每一次工具调用。在我们的测试中，它还能在其 5 分钟的有效期内开启第二个会话。

由于一个凭证提供程序以单个 Okta 智能体的身份进行身份验证，因此要为每个智能体分配自己的网关和提供程序。示例 08-okta-xaa-delegation-chain 采取了另一种方式，即由网关拦截器自己执行两次交换。

用 Cedar 将工具绑定到智能体

在 AgentCore 引擎上为处于 ENFORCE 模式的网关附加策略，并编写仅允许（permit-only）策略。Cedar 将 JWT 声明暴露为标签。读取缺失标签的策略会报错并被跳过。被跳过的 permit 不授予任何权限，因此默认拒绝仍然成立，但被跳过的 forbid 不会阻止任何操作。用 hasTag 保护每个标签：

permit(
  principal is AgentCore::OAuthUser,
  action in [AgentCore::Action::"taskmanager___create_task",
             AgentCore::Action::"taskmanager___update_task_status"],
  resource == AgentCore::Gateway::"<gateway-arn>"
) when {
  principal.hasTag("client_id") && principal.getTag("client_id") == "<agent-client-id>" &&
  principal.hasTag("scope") &&
  (principal.getTag("scope") == "xaa:write" ||
   principal.getTag("scope") like "xaa:write *" ||
   principal.getTag("scope") like "* xaa:write" ||
   principal.getTag("scope") like "* xaa:write *")
};

scope 标签保存 ID-JAG 的空格分隔的 scope 声明，因此四个条件只能将 xaa:write 作为整个条目进行匹配。诸如 xaa:write-admin 这样的 scope 不会匹配。以同样方式编写的匹配策略会以 xaa:read 允许读取类工具。在将引擎附加之前，检查每个策略是否为 ACTIVE：如果引擎的策略创建失败，网关将拒绝所有调用。Cedar 将工具绑定到智能体及其委托的 scope，而 MCP 服务器仍然像第 1 部分那样根据 groups 声明决定每个用户的权限。

将智能体指向网关

智能体 A 现在将其入站 ID-JAG 转发给网关，而不是直接调用 AgentCore Identity：

id_jag = context.request_headers["Authorization"].removeprefix("Bearer ")  # allowlisted header
tools = make_client(GATEWAY_URL, id_jag)  # the Gateway redeems the ID-JAG for each target

从智能体的执行角色中移除第 1 部分的 AgentCore Identity 语句。这是对该角色的唯一更改，该角色现在不持有任何令牌交换或机密权限，因为网关的角色持有交换令牌的权限。将 allowedClients 保留在运行时的授权器上。

在 Amazon EKS 上运行第二个智能体

我们的第二个智能体（一个报告智能体）在 Amazon EKS 上运行相同的代码，并拥有自己的 Okta 注册。其资源连接只允许 xaa:read，并且它拥有自己的网关和凭证提供程序。EKS Pod Identity 为 Pod 提供一个 IAM 角色，该角色可以调用模型并写入自己的日志和追踪，除此之外别无其他权限。AWS Distro for OpenTelemetry (ADOT) SDK 导出其追踪信息。agents-on-eks 示例展示了 Pod Identity 的设置。

在 AgentCore 运行时之外，Pod 前面没有授权器，因此智能体会在调用模型之前验证 ID-JAG。它会检查签名、颁发者、受众、令牌类型 oauth-id-jag+jwt、有效期，以及 client_id 是否属于自己。如果你在第 1 部分的 MCP 服务器中保留了智能体检查，请将智能体 B 的客户端 ID 添加到 REGISTERED_AGENTS 中。有两个配置让我们栽了跟头。EKS Auto Mode 的通用节点池只运行 amd64，因此要构建多架构镜像。此外，AgentCore Python SDK（Amazon Bedrock AgentCore 的一项能力）默认绑定到 localhost，除非你设置 DOCKER_CONTAINER=true。

使用 AgentCore Observability 追踪每个决策

本节中的跨度（span）来自 AgentCore Observability，即图 1 中位于智能体与 CloudWatch 之间的组件。开启 Transaction Search 和追踪传送后，Runtime、Gateway、Identity 和 Policy 会为每一跳生成 OpenTelemetry 跨度，无需更改代码。你自己的服务可以通过 AWS Distro for OpenTelemetry (ADOT) 添加它们的跨度。CloudWatch Transaction Search 收集这些跨度，AgentCore 控制台将它们读取为智能体追踪，而 Amazon CloudWatch Omni 将相同的跨度读取为 traces.default，这使得一个查询就能将它们与 Okta 的事件放在一起。

因此，一次工具调用会产生这样一条跨度链，每条跨度都指明做出决策的控制组件：

Okta 的 System Log 是 AWS 无法生成的唯一记录，因此你需要将其引入。图 4 展示了这两条路径在 Omni 中汇合。

图 4：审计路径，spans 和 Okta 的 System Log 到达 CloudWatch，一条 Omni 查询将它们关联起来

设置方法：

1. 开启 CloudWatch Transaction Search，为每个 Gateway 开启 trace 交付（参见这个示例脚本），并在 BFF 和 MCP 服务器中加入 ADOT。任务管理器将每个决策、用户和智能体写入一个 authz.check span。
2. 在 Okta 中，为 Amazon EventBridge 添加一个 Log Stream。Okta 将每个事件发送到你账户中的一个合作伙伴事件总线（partner event bus），然后由一条规则将其写入 CloudWatch Logs 日志组。在我们的测试中，事件在 Okta 发布后约 1 秒到达。每条 ID-JAG 授权事件都将智能体列为操作者，将用户列为目标，并列出被授予的 scopes 和资源连接。
3. 在账户和 AWS Region 中设置一个 Omni 空间，将 Okta 日志组添加到 CloudWatch Dataset 集成中，并保存一个视图 view.xaa_authz_decisions，覆盖这些 authz.check spans。

一条查询即可将每条 ID-JAG 授权关联到它所导致的决策：

SELECT o.okta_time, o.agent, o.user_email, o.granted, a.decision_time, a.decision, a.reason
FROM (SELECT `@timestamp` AS okta_time, detail['actor']['id'] AS agent_id,
             detail['actor']['displayName'] AS agent,
             array_element(regexp_match(`@message`, '"type"\s*:\s*"User"\s*,\s*"alternateId"\s*:\s*"([^"]+)"'), 1) AS user_email,
             detail['debugContext']['debugData']['grantedScopes'] AS granted
      FROM "logs.default"
      WHERE `@timestamp` BETWEEN NOW() - INTERVAL '1' HOUR AND NOW()
        AND detail['eventType'] = 'app.oauth2.token.grant.id_jag') o
JOIN (SELECT `@timestamp` AS decision_time, user_id, agent_client_id, decision, reason
      FROM "view.xaa_authz_decisions"
      WHERE `@timestamp` BETWEEN NOW() - INTERVAL '1' HOUR AND NOW()) a
  ON a.user_id = o.user_email AND a.agent_client_id = o.agent_id
 AND a.decision_time BETWEEN o.okta_time AND o.okta_time + INTERVAL '5' MINUTE

对于 Alice，结果显示 Okta 代表她向任务智能体授予了 xaa:read xaa:write，随后 16.7 秒后 MCP 服务器拒绝了她的 create_task，之后又允许了 list_tasks，如图 5 所示。

图 5：Omni 查询将 Okta System Log 中 Alice 的 ID-JAG 授权关联到它所导致的两个决策

每个请求也是一条 trace，从 BFF 经由智能体、Gateway 的身份和策略检查，再到 MCP 服务器的决策，如图 6 所示。由于智能体的 create_task 调用返回了拒绝，Omni 将该 trace 标记为故障。

图 6：Alice 请求的一条 trace，从智能体的工具调用，经过 Gateway 的身份和 Cedar 检查，到 MCP 服务器的拒绝

有两个插桩细节很重要。ADOT 会发现 Region 并通过 botocore 对其导出进行签名，因此请为缺少该权限的服务添加 botocore。在我们添加之前，我们的 MCP 服务器没有导出任何 span。另外，ADOT 的 agent 模式默认关闭对 requests 和 urllib3 等HTTP 客户端库的插桩，因此请在你的 BFF 中设置 OTEL_PYTHON_DISABLED_INSTRUMENTATIONS，用一个列表覆盖该默认设置，把 BFF 的 HTTP 客户端（我们的是 requests）排除在外，否则它的 trace 上下文将无法传递到智能体。

验证结果

我们使用第 1 部分中的用户，通过两个 Gateway 运行了每项检查。每个会话先列出工具，然后调用 list_tasks、create_task 和一次员工查询：

通过部署的智能体，结果一致：智能体 A 拒绝了 Alice 和 Carol，并为 Bob 创建了任务；智能体 B 告诉 Bob 它没有创建任务的工具。同一个用户通过不同的智能体获得了不同的权限，而这由 Okta 决定。

这些请求在前门就被拦下了：

对于错误的智能体和错误的令牌类型，Gateway 返回同样的通用错误，因此看到该错误时，请对照令牌的 client_id 和 aud 检查你的配置。

相比工具本身，网关在身份与策略方面的工作开销很小。以下是 Omni 中 24 小时 Gateway A 跨度的中位数和第 90 百分位数：

一次工具调用的身份与策略跨度在中位数下合计约 0.2 秒，而 MCP 服务器自身的 authz.check 跨度耗时不足 1 毫秒。Gateway B 呈现相同的模式，GetResourceOauth2Token 中位数为 408 毫秒。

跨应用访问与逐用户同意

XAA 适用于目标应用的授权服务器接受 ID-JAG 的场景。在那里，你的 Okta 管理员决定哪个智能体可以代表哪些用户行事，用户看不到同意提示，并且 Okta 在每次请求令牌时评估策略。拥有自己授权服务器的应用（如 GitHub）则依赖每个用户自己的 OAuth 同意。图 7 对比了我们所测量的这两种方式。

图 7：跨应用访问与逐用户 OAuth 同意的对比，包括我们测量到的吊销行为

我们在我们的技术栈旁部署了 AWS 示例 07-consent-portal-auth-code-flow-targets，由 Okta 让用户登录到 AgentCore Identity 同意门户，以及位于其自己网关上的 GitHub 目标。Alice 通过门户连接了一个 GitHub 测试账号，而 Bob 从未连接过。文章 Manage end-user OAuth consent for AI agents with Amazon Bedrock AgentCore 完整描述了这一路径。以下是我们观察到的结果：

这两种路径的吊销方式不同。在 XAA 中，Okta 的控制会阻止下一个 ID-JAG 的生成，已签发的令牌在约 5 分钟内过期。在同意路径中，Okta 只控制登录：存储的授权在停用后仍然存在，直到我们主动断开它。请针对每个目标应用分别选择，而不是在企业层面一次性决定。

此模式适用的场景

在媒体和娱乐行业，智能体集群会迅速扩张。一家制片公司、流媒体或游戏组织中，会有用于生产跟踪、片名与资产元数据、版权与本地化以及观众或玩家支持的智能体，每个智能体面对不同的系统，各自拥有自己的授权模型和审计方。问题不在于一个智能体能否被治理，而在于第一百个智能体是否以同样的方式被治理，以及管理员是否仍能回答哪些智能体以哪些用户身份访问哪些系统。

这里没有任何内容是该行业特有的。智能体是你 IdP 中的一个身份，目标是一个 OAuth 2.0 授权服务器，而网关是授权决策所在之处。金融服务、医疗保健和公共部门的团队将不同的资源放到同一个前门之后，并获得相同的审计轨迹。

下一步：可观测性与评估

本文使用 AgentCore Observability 只为达成一个目的：证明每一次允许和拒绝都能追溯到某项控制措施。它的功能远不止于此，且本身就是一门完整的体系。这些 span 已经携带了每项治理决策背后的模型与工具延迟，Transaction Search 可以在拒绝次数激增时发出警报，而 AgentCore evaluations 可以按照你自己的标准对智能体的行为进行评分，既可以在线针对实时流量，也可以按需针对选定的一组 span。后续的一篇文章将深入探讨：在受治理的智能体上应测量什么，哪些评估器能捕捉到在工具调用被拒后仍报告成功的智能体，以及如何运行这两者而不让你的追踪记录变成最大的一笔账单。

清理

为避免产生持续费用，请删除第 2 部分的资源，然后按照 第 1 部分 中的清理步骤操作：

1. 删除 Amazon EKS 集群（eksctl delete cluster）及其 Amazon Elastic Container Registry（Amazon ECR）仓库。
2. 删除 Gateway 及其目标，然后删除 Policy in AgentCore 引擎中的策略，最后删除智能体 B 的凭证提供程序。
3. 删除 CloudWatch Omni 空间和域、Dataset 集成、Amazon EventBridge 规则和合作伙伴事件总线，以及 CloudWatch 日志组。
4. 如果你部署了示例 07，请按照其清理步骤操作。
5. 删除你创建的 IAM 角色和策略。
6. 在 Okta 中，删除日志流，然后停用并删除智能体 B 及其关联应用。

结论

在本文中，你将 第 1 部分 的解决方案从适合少量智能体和工具的拓扑结构，迁移到能支撑大规模使用的拓扑结构。Gateway 成为了唯一的统一入口，并兑现了 Okta 的授权，因此各智能体不持有任何工具凭证。由 Policy in AgentCore 评估的 Cedar 策略取代了复制到每个服务器中的检查逻辑。Amazon EKS 上的第二个智能体以其自身的 Okta 身份加入。而 AgentCore Observability 与 CloudWatch Omni 中的 Okta System Log 并列，将每一次允许和拒绝追溯到做出决定的智能体、用户和控制措施。治理机制没有改变——这正是关键所在：改变的只是围绕它的拓扑结构。

要开始使用，请探索 AgentCore samples 和 Okta 的 Cross App Access 文档。有关通过 Gateway 进行纯令牌交换的内容，请阅读 Implement on-behalf-of token exchange for multi-tenant agents with Amazon Bedrock AgentCore Gateway。

关于作者