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

在第 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 中的 Policy 评估 Cedar 策略，将每个工具绑定到代理以及 Okta 委托的范围。Amazon Elastic Kubernetes Service (Amazon EKS) 上的第二个代理以自己的 Okta 身份加入，以表明前门并不关心代理运行在哪里。而 Amazon Bedrock AgentCore Observability（Amazon Bedrock AgentCore 的一项能力）与 Amazon CloudWatch 结合，为你提供一个读取每个决策（包括 Okta 的决策）的地方。我们还将 XAA 与针对无法接受 Okta 授权的应用程序的按用户 OAuth 同意进行比较。

与第 1 部分相比有哪些变化

第 1 部分中的 Okta 配置、AgentCore Identity 凭证提供方和 MCP 服务器保持不变。图 1 展示了新增内容后的架构。

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

1. 用户登录，前端后端 (BFF) 将 ID 令牌交换为签发给任务代理（代理 A）的 Identity Assertion JWT Authorization Grant (ID-JAG)，与第 1 部分相同。
2. BFF 使用 ID-JAG 在 AgentCore runtime 上调用代理 A。
3. 代理 A 将 ID-JAG 作为其 MCP 会话的持有者令牌转发给其 Gateway。Gateway 的入站授权器仅接受代理 A 的 ID-JAG。
4. AgentCore 中的 Policy 在 Gateway 调用目标之前，为每次工具列表和每次工具调用评估 Cedar 策略。
5. 对于 Cedar 允许的调用，Gateway 会让 AgentCore Identity 通过 Part 1 的凭证提供方，在 Okta 的自定义授权服务器上为每个目标兑换 ID-JAG。Cedar 拒绝的调用则不会兑换 ID-JAG。
6. MCP 服务器会像 Part 1 中那样检查用户的组和 scope，并将每个决策记录为一个 authz.check span。
7. 每一跳都会向 AgentCore Observability 发出 OpenTelemetry span，由 CloudWatch Transaction Search 收集，而 Okta 通过 Amazon EventBridge 将其 System Log 流式传输到 CloudWatch。

报告代理 agent B 运行在 Amazon EKS 上，并通过其自己的 Gateway 走相同的路径。

先决条件

除 Part 1 的解决方案外，你还需要以下内容：

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

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

创建一个接受 ID-JAG 的 Gateway

Gateway 的入站授权器的工作方式与 Part 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：Gateway 仅接受 Okta 为资源的授权服务器签发给该代理的 ID-JAG

每个 MCP 服务器都成为一个 Gateway 目标，其出站授权通过 Part 1 的凭证提供方使用 TOKEN_EXCHANGE，因此 Gateway 执行第二次交换：

"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：任务管理器目标通过 Part 1 的凭证提供方兑换 ID-JAG

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

由于一个凭证提供方以一个 Okta 代理的身份进行认证，请为每个代理提供其自己的 Gateway 和提供方。示例 08-okta-xaa-delegation-chain 采用了不同的路径，其中由 Gateway 拦截器自行执行两次交换。

使用 Cedar 将工具绑定到代理

在 ENFORCE 模式下，将 AgentCore 引擎中的策略附加到 Gateway，并编写仅允许（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：如果引擎的策略创建失败，Gateway 会拒绝所有调用。Cedar 将工具绑定到代理及其委托范围，而 MCP 服务器仍根据 groups 声明决定每个用户的权限，如第 1 部分所述。

将代理指向 Gateway

代理 A 现在将其入站 ID-JAG 转发给 Gateway，而不是自己调用 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 语句。这是该角色唯一的更改，现在它不持有任何令牌交换或密钥权限，因为 Gateway 的角色持有交换令牌的权限。在运行时的授权器上保留 allowedClients。

在 Amazon EKS 上运行第二个代理

我们的第二个代理是一个报告代理，它在 Amazon EKS 上运行相同的代码，并拥有自己的 Okta 注册。其资源连接仅允许 xaa:read，并且它有自己的 Gateway 和凭证提供程序。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 是否为其自身。如果你在 MCP 服务器中保留了第 1 部分的代理检查，请将代理 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 span。你自己的服务使用 AWS Distro for OpenTelemetry (ADOT) 添加它们的 span。CloudWatch Transaction Search 收集它们，AgentCore 控制台将它们作为代理跟踪读取，而 Amazon CloudWatch Omni 将相同的 span 读取为 traces.default，这使得一个查询可以将它们与 Okta 的事件放在一起。

因此，一次工具调用会产生以下 span 链，每个 span 都指明做出决策的控制组件：

Okta 的 System Log 是 AWS 无法发出的唯一记录，因此你需要将其引入。图 4 显示了两种路径在 Omni 中汇合。

图 4：审计路径，其中 span 和 Okta 的 System Log 到达 CloudWatch，并由一个 Omni 查询将它们连接起来

要进行设置：

1. 开启 CloudWatch Transaction Search，为每个 Gateway 开启 trace 投递（参见此示例脚本），并将 ADOT 添加到 BFF 和 MCP 服务器。任务管理器将每个决策、用户和 agent 写入一个 authz.check span。
2. 在 Okta 中，为 Amazon EventBridge 添加一个 Log Stream。Okta 将每个事件投递到您账户中的合作伙伴事件总线，然后由一条规则将其写入 CloudWatch Logs 日志组。在我们的测试中，事件在 Okta 发布后约 1 秒到达。每个 ID-JAG 授权事件都将 agent 指定为执行者，将用户指定为目标，并记录授予的 scope 和资源连接。
3. 在该账户和 AWS 区域中设置一个 Omni 空间，将 Okta 日志组添加到 CloudWatch Dataset 集成中，并基于 authz.check span 保存一个视图 view.xaa_authz_decisions。

然后，一个查询将每个 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 为她向任务 agent 授予了 xaa:read xaa:write，随后 MCP 服务器在 16.7 秒后拒绝了她对 create_task 的请求，之后又允许了 list_tasks，如图 5 所示。

图 5：Omni 查询将 Okta 的 System Log 中 Alice 的 ID-JAG 授权与其导致的两个决策连接起来

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

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

有两个插桩细节很重要。ADOT 通过 botocore 查找区域并对其导出进行签名，因此请将 botocore 添加到缺少它的服务中。在我们这样做之前，我们的 MCP 服务器没有导出任何 span。此外，ADOT 的 agent 模式默认会关闭对 requests 和 urllib3 等 HTTP 客户端库的插桩，因此请在 BFF 中设置 OTEL_PYTHON_DISABLED_INSTRUMENTATIONS，用一个不包含 BFF 的 HTTP 客户端（在我们的例子中是 requests）的列表来覆盖该默认值，否则其 trace 上下文将无法到达 agent。

验证结果

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

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

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

Gateway 对错误的 agent 和错误的令牌类型返回相同的通用错误，因此当您看到该错误时，请对照令牌的 client_id 和 aud 检查您的配置。

Gateway 的身份与策略工作相较于工具本身而言很小。来自 Omni 中 Gateway A 的 24 小时 span 的中位数和第 90 百分位数：

一次工具调用的身份与策略 span 在中位数上合计约 0.2 秒，而 MCP 服务器自身的 authz.check span 耗时不到 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 同意门户，并在其自己的 Gateway 上设置 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 授权服务器，而 Gateway 是做出授权决定的地方。金融服务、医疗保健和公共部门的团队将不同的资源放在同一个前门之后，并获得相同的审计跟踪。

下一步：可观测性和评估

本文使用 AgentCore Observability 的目的只有一个：证明每一次允许和拒绝都能追溯到某项控制。它的作用远不止于此，本身也是一项独立的工作成果。这些 span 已经承载了每项治理决策背后的模型和工具延迟，Transaction Search 可以对拒绝次数的激增发出告警，而 AgentCore 评估可以按照你自己的标准对 agent 的行为打分，既可以针对实时流量在线进行，也可以按需对选定的一组 span 进行。后续文章会进一步讨论：在受治理的 agent 上应该测量什么，哪些评估器能发现那种在工具调用被拒绝后仍报告成功的 agent，以及如何在不把 trace 变成你最大一笔账单的前提下同时运行这两者。

清理

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

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

结论

在本文中，你将 第 1 部分 的解决方案从适合少量 agent 和工具的拓扑，演进为可支撑大量 agent 和工具的拓扑。Gateway 成为唯一的入口，并兑换 Okta 的授权，因此 agent 不持有任何工具凭证。由 Policy in AgentCore 评估的 Cedar 策略取代了复制到每个服务器中的检查。Amazon EKS 上的第二个 agent 以自己的 Okta 身份加入。而 AgentCore Observability 与 Okta 的 System Log 一同位于 CloudWatch Omni 中，将每一次允许和拒绝都追溯到 agent、用户以及做出该决定的控制。治理机制本身没有改变，这正是关键所在：改变的只是它周围的拓扑。

要开始使用，请浏览 AgentCore 示例 和 Okta 的 Cross App Access 文档。如需通过 Gateway 进行普通令牌交换，请阅读 Implement on-behalf-of token exchange for multi-tenant agents with Amazon Bedrock AgentCore Gateway。

关于作者

Hammad Ausaf

Hammad 是媒体与娱乐领域的首席解决方案架构师。他是一位充满热情的构建者，致力于为 AWS 客户提供最佳解决方案。

Rajat Jain

Rajat 是 AWS 媒体与娱乐领域的技术客户经理，已在公司工作超过 3 年。他指导客户遵循运营最佳实践，并帮助他们充分利用 AWS 服务。

Madhu Samhitha Vangara

Madhu 是 AWS 全球生成式 AI 专家解决方案架构师，专注于 Amazon Bedrock AgentCore 和 Strands Agents 的 agentic AI 市场推广。她将新兴的 AI 能力和研究转化为客户可衡量的成果。工作之外，她是一名受过训练的印度古典舞者，也是一位艺术爱好者。