用 Okta 跨应用访问治理 AgentCore 上的智能体代用户操作

#用 Okta 跨应用访问治理 AgentCore 上的智能体代用户操作

一个更新工单或读取客户记录的人工智能智能体（agent），是在某个人能到达的应用里为这个人行动。身份团队随后必须回答一个问题，而按应用的 OAuth 同意和共享服务账户把这个问题留着没答：哪个智能体可能为哪个用户在哪个应用里行动，以及你如何阻止它。Okta 跨应用访问（Okta Cross App Access，XAA）在你的身份提供方（identity provider，IdP）里回答它。你在 Okta 中注册智能体，管理员批准它可能到达的应用，并且每次智能体请求为某用户行动时，Okta 都评估策略。在我们的测试中，管理员移除某用户对该智能体的分配之后，Okta 在大约 1 秒内拒绝该智能体为该用户发出的新请求，已经签发的令牌在 5 分钟内过期。

Amazon Bedrock AgentCore 是一个平台，可用任何框架或模型大规模构建、连接和优化智能体。本方案使用它的两项能力，在 AWS 上执行 Okta 的决定。Amazon Bedrock AgentCore 运行时是 Amazon Bedrock AgentCore 的一项能力，它验证 Okta 的授权。Amazon Bedrock AgentCore Identity 是 Amazon Bedrock AgentCore 的一项能力，它用你的智能体代码看不到的凭证把该授权兑换成短生命周期访问令牌，并把该令牌保存在其令牌保管库中。在我们的测试中，对一次端到端大约 30 秒的请求，AgentCore Identity 增加了大约 0.6 秒。

在本文（两篇中的第一篇）中，你在 AgentCore 运行时上构建一个任务智能体，它通过 XAA 和 AgentCore Identity 为已登录用户行动。你配置它需要的 AgentCore Identity 部分，在工具中强制每个用户的权限，并看到我们测到的内容：每项检查拒绝什么、我们落定的做法，以及 Okta 的控制生效有多快。第 2 部分随后把同一套治理放到 Amazon Bedrock AgentCore 网关后面。AgentCore 网关是 Amazon Bedrock AgentCore 的一项能力，配合策略语言（Cedar）策略、Amazon Elastic Kubernetes Service（Amazon EKS）上的第二个智能体，以及 Amazon CloudWatch 中的审计轨迹。

方案概览

Okta 是治理平面：它决定哪个智能体可能为哪个用户、针对哪个资源行动。AgentCore Identity 是执行平面：它持有智能体的凭证，把 Okta 的决定变成资源接受的令牌，并在该令牌中同时保留两种身份。在图 1 中，智能体和它调用的两台模型上下文协议（Model Context Protocol，MCP）服务器都运行在 AgentCore 运行时上。

图注：Okta 治理平面与 AgentCore Identity 执行平面，智能体和两台 MCP 服务器运行在 AgentCore 运行时上

图 1：方案架构，编号与随后的步骤对应

每个请求携带三个令牌，每个记录一项不同的决定：ID 令牌说明用户是谁，身份断言 JWT 授权许可（Identity Assertion JWT Authorization Grant，ID-JAG）是 Okta 的决定，访问令牌是资源所接受的东西。一次请求像这样流动：

• 用户通过智能体关联的 Okta 应用，用 OpenID Connect 登录到 Web 前端，即前端的后端（backend for frontend，BFF）。

• 对每个请求，BFF 在 Okta 的组织授权服务器上把用户的 ID 令牌换成 ID-JAG，并以智能体身份认证（RFC 8693 令牌交换）。Okta 检查智能体处于活动状态、用户被分配给它，以及管理员已把它连接到所请求范围的目标授权服务器。ID-JAG 是一次性的，并在 5 分钟后过期。

• BFF 以 ID-JAG 作为持有者令牌，在 AgentCore 运行时上调用智能体。运行时的 JWT 授权器只接受 Okta 签发给这个智能体的 ID-JAG。

• 运行时从 AgentCore Identity 取得一个工作负载访问令牌，把智能体的工作负载身份绑定到该用户，并把它传给智能体代码。这个工作负载访问令牌是 AWS 内部的绑定令牌：Okta 和资源都看不到它，因此它不是那三个令牌之一。

• 智能体向 AgentCore Identity 请求访问令牌。AgentCore Identity 在资源的 Okta 自定义授权服务器上，用 JWT 授权许可（RFC 7523）兑换 ID-JAG，并以智能体身份认证。Okta 返回一个 5 分钟的访问令牌，其中同时写明用户和智能体，并携带用户的组。

• 智能体用该令牌调用 MCP 服务器。任务管理器检查它是由已注册智能体取得的，并且用户的组和范围允许该工具。

图 2 把同一次请求画成序列，并标出每一方所做的检查。

图注：三令牌链的序列，展示 ID 令牌、ID-JAG 和访问令牌，以及每一方所做的检查

图 2：三令牌链以及每一方所做的检查，其中第 4 步的工作负载访问令牌留在 AWS 内部

前提条件

要跟着做，你需要以下各项：

走读大约需要 1 小时。AgentCore 按你的使用计费。见 Amazon Bedrock AgentCore 定价。

本方案的基础是 GitHub 上 AgentCore 示例仓库中的 AWS 示例 08-okta-xaa-delegation-chain，你可以在它之上构建本文中的方案。超出该示例的部分，本文中的片段和配置在概念上展示这一模式。它们不是一套完整的、可部署的方案。代码是供非生产使用的示例代码，因此在部署之前，与你的安全和法务团队合作，以满足组织的安全、监管和合规要求。

在 Okta 中注册智能体

Okta 需要一个给资源用的授权服务器、这个智能体、二者之间的连接，以及一条接纳该智能体许可的策略。在 Okta 管理控制台中完成所有这些步骤：注册智能体会创建它的关联应用，因此你不需要应用集成向导。

• 为资源应用创建一个自定义授权服务器，受众为 api://task-manager，自定义范围为 xaa:read 和 xaa:write。只请求资源的自定义范围：Okta 会拒绝包含 OpenID Connect 范围（例如 openid 或 profile）的 ID-JAG 请求（invalid_scope），因此请求至少需要一个自定义范围，并且不能有 OpenID Connect 范围。

• 向其访问令牌添加一个 groups 声明，过滤为以 xaa- 开头的组。该声明把每个用户的权限带到工具。

• 在管理控制台中，转到 Directory > AI Agents，选择 Register AI agent，然后选择 Register manually，可选地指定所有者，并创建一个关联的 OpenID Connect 应用。在 Client registration 上选择 Client secret，生成一个密钥，然后激活智能体。智能体和应用共享一个客户端 ID，并且该应用必须为你的用户登录：来自另一个应用的 ID 令牌会使交换失败，并提示“the client application is not registered for delegation to this agent.”

• 在智能体的 Resource connections 选项卡上，把它连接到授权服务器，并限制在它需要的范围，如图 3 所示。

• 向自定义授权服务器添加一条访问策略规则，允许该智能体的 JWT Bearer 许可，访问令牌生命周期为 5 分钟。没有该许可类型时，第二次交换会以 no_matching_policy 失败，而生命周期限定了被撤销的委托还能工作多久。

• 分配可能通过该智能体行动的用户或组。他们通过关联应用登录，因此给它一条应用登录策略，用他们已登记的认证器接纳他们。在我们的沙箱组织中，关联应用有自己的策略，其中有一条针对测试组的规则。对真实用户，应用你组织的策略，包括多因素认证。

图注：任务智能体的 Okta 资源连接，限制在 xaa:read 和 xaa:write 范围

图 3：Okta 中任务智能体的资源连接，限制在 xaa:read 和 xaa:write 范围

Okta 的跨应用访问指南涵盖控制台步骤，AWS 示例 08-okta-xaa-delegation-chain 用脚本配置授权服务器及其 JWT bearer 策略。然后 BFF 请求 ID-JAG，并以智能体身份认证：

POST /oauth2/v1/token HTTP/1.1
Host: YOUR-ORG.okta.com
Authorization: Basic <the agent's client ID and secret>
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:id-jag
&subject_token=<the user's ID token>
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&audience=https://YOUR-ORG.okta.com/oauth2/YOUR-CUSTOM-AS-ID
&scope=xaa:read xaa:write

AWS 示例 06-okta-xaa 用 Python 发送同一请求（agent/xaa_client.py）。BFF 以智能体身份认证，因此把智能体的客户端密钥存放在 AWS Secrets Manager 中，而不是放在代码或配置文件里。

设置 AgentCore Identity

对本方案，AgentCore Identity 持有三样东西，你的智能体代码看不到客户端密钥，也不调用 Okta 的令牌端点：

创建凭证提供方

凭证提供方执行第二次交换。把它指向自定义授权服务器，以人工智能智能体身份认证它，并把代表用户的许可设为 JWT_AUTHORIZATION_GRANT。AgentCore Identity 把它作为 jwt-bearer 发送，并以 ID-JAG 作为断言：

control = boto3.client("bedrock-agentcore-control")
provider = control.create_oauth2_credential_provider(
    name="okta-xaa-obo",
    credentialProviderVendor="CustomOauth2",
    oauth2ProviderConfigInput={"customOauth2ProviderConfig": {
        "oauthDiscovery": {"discoveryUrl": f"{OKTA_ORG}/oauth2/{CUSTOM_AS_ID}/.well-known/openid-configuration"},
        "clientId": AGENT_CLIENT_ID,          # the AI agent's Okta client ID
        "clientSecret": AGENT_CLIENT_SECRET,  # AgentCore Identity stores it in AWS Secrets Manager
        "clientAuthenticationMethod": "CLIENT_SECRET_BASIC",
        "onBehalfOfTokenExchangeConfig": {"grantType": "JWT_AUTHORIZATION_GRANT"},
    }},
)
provider_arn = provider["credentialProviderArn"]

Okta 把两次交换都绑定到 ID-JAG 中点名的客户端，因此每个 Okta 智能体需要自己的提供方：当我们用另一个智能体兑换某个智能体的 ID-JAG 时，Okta 拒绝并提示“The ‘client_id’ in the JWT Bearer Grant must match the ‘client_id’ used to authenticate the client.” AgentCore Identity 把密钥保存在服务托管的 AWS Secrets Manager 密钥中，你用 update-oauth2-credential-provider 轮换它。如果你的团队已经在 Secrets Manager 中管理客户端密钥，可以改为引用该密钥的 ARN。AgentCore Identity 从中读取客户端密钥，因此你可以轮换密钥而不更新提供方（见在 Amazon Bedrock AgentCore Identity 中引用你自己的 AWS Secrets Manager 密钥）。为避免共享密钥，改为用私钥认证。见使用 Amazon Bedrock AgentCore Identity 以私钥 JWT 认证。图 4 展示 AgentCore 控制台中的提供方。

图注：AgentCore 控制台中配置了 JWT 授权许可的凭证提供方视图

图 4：以智能体身份、用 JWT 授权许可进行认证的凭证提供方

使用 AgentCore 运行时管理的工作负载身份

AgentCore 运行时为每个智能体运行时创建并管理工作负载身份。当请求通过运行时的 JWT 授权器时，运行时为该工作负载身份以及入站令牌的签发者和主体取得工作负载访问令牌，并把它传给你的代码。AgentCore Identity 随后把其背后的 ID-JAG 用作交换的断言。

AgentCore Python SDK 把工作负载访问令牌保存在 BedrockAgentCoreContext 中，而不是在你的入口点收到的请求头里。我们的第一版在请求头里找它，什么也没找到，并回退到用第二个工作负载身份自行调用 GetWorkloadAccessTokenForJWT，我们检查的全部 21 个请求都是如此。改为从上下文读取：

from bedrock_agentcore.runtime import BedrockAgentCoreContext

identity = boto3.client("bedrock-agentcore")

def okta_access_token() -> str:
    workload_token = BedrockAgentCoreContext.get_workload_access_token()  # minted by the runtime
    return identity.get_resource_oauth2_token(
        workloadIdentityToken=workload_token,
        resourceCredentialProviderName="okta-xaa-obo",
        scopes=["xaa:read", "xaa:write"],  # must equal the ID-JAG's scopes
        oauth2Flow="ON_BEHALF_OF_TOKEN_EXCHANGE",
    )["accessToken"]

AgentCore Identity 在请求的其余时间把访问令牌保存在其令牌保管库中。在 10 个请求中，智能体的第一次调用大约在半秒内兑换 ID-JAG（见验证结果中的延迟表），第二次调用面向另一台 MCP 服务器，在中位数 58 毫秒内返回同一令牌，而没有再次兑换一次性的 ID-JAG。同一用户的新 ID-JAG 得到新令牌，因此每个请求都反映 Okta 的最新决定。示例 08-okta-xaa-delegation-chain 以同样方式读取工作负载访问令牌（agent/agent.py）。

把智能体的角色限定到其工作负载身份和提供方

AgentCore Identity 并不在同一账户内把工作负载身份绑定到凭证提供方。智能体的 IAM 角色做这件事，因此把它限定到智能体自己的工作负载身份和提供方，以及该提供方的密钥：

[
  {
    "Sid": "OktaOnBehalfOf",
    "Effect": "Allow",
    "Action": "bedrock-agentcore:GetResourceOauth2Token",
    "Resource": [
      "arn:aws:bedrock-agentcore:us-west-2:123456789012:workload-identity-directory/default",
      "arn:aws:bedrock-agentcore:us-west-2:123456789012:workload-identity-directory/default/workload-identity/RUNTIME-WORKLOAD-IDENTITY",
      "arn:aws:bedrock-agentcore:us-west-2:123456789012:token-vault/default",
      "arn:aws:bedrock-agentcore:us-west-2:123456789012:token-vault/default/oauth2credentialprovider/okta-xaa-obo"
    ]
  },
  {
    "Sid": "ReadProviderSecret",
    "Effect": "Allow",
    "Action": "secretsmanager:GetSecretValue",
    "Resource": "arn:aws:secretsmanager:us-west-2:123456789012:secret:bedrock-agentcore-identity!default/oauth2/okta-xaa-obo-*"
  }
]

从 GetAgentRuntime 的 workloadIdentityDetails 取得工作负载身份的名称，从 credentialProviderArn 取得提供方的 ARN：那段是 oauth2credentialprovider，而用带连字符的形式时，每次调用都以 AccessDeniedException 失败。该角色不需要 GetWorkloadAccessToken 权限，因为是运行时取得该令牌，而不是智能体。我们的测试只靠这两条语句就通过了。

在 AgentCore 运行时上部署智能体

把智能体运行时的入站授权器配置为只接受 Okta 签发给这个智能体的 ID-JAG。它的签发者是 Okta 的组织授权服务器，它的受众是资源的自定义授权服务器。在 agentcore.json 中：

"authorizerType": "CUSTOM_JWT",
"authorizerConfiguration": {
  "customJwtAuthorizer": {
    "discoveryUrl": "https://YOUR-ORG.okta.com/.well-known/openid-configuration",
    "allowedAudience": ["https://YOUR-ORG.okta.com/oauth2/YOUR-CUSTOM-AS-ID"],
    "allowedClients": ["YOUR_AGENT_CLIENT_ID"],
    "allowedScopes": ["xaa:read", "xaa:write"]
  }
}

allowedClients 匹配 ID-JAG 携带的 client_id 声明。没有它时，运行时以 HTTP 200 接纳了另一个智能体的 ID-JAG，请求稍后在交换处失败。有了它，运行时以 HTTP 401 拒绝该令牌。

除上一节的策略外，执行角色还需要 bedrock:InvokeModel 和 bedrock:InvokeModelWithResponseStream。它对 MCP 服务器不需要 bedrock-agentcore:InvokeAgentRuntime 权限：每一台都运行在自己的 JWT 授权器后面的 AgentCore 运行时上，签发者是自定义授权服务器，受众是 api://task-manager，因此智能体用 Okta 访问令牌作为持有者令牌调用它，而不是用 AWS 签名版本 4（SigV4）。

在 MCP 服务器中强制每个用户的权限

资源连接为智能体的每个用户设置范围，因此三个测试用户都收到了 xaa:read xaa:write，按用户的权限改为在 groups 声明中传递：Alice 的令牌携带 xaa-readers，Bob 的携带 xaa-writers，Carol 的没有。

任务管理器检查两件事：它只接受已注册智能体取得的令牌，并且只有当组和范围都存在时才允许写入：

REGISTERED_AGENTS = {"YOUR_AGENT_CLIENT_ID"}

def _require_agent() -> None:
    claims = _decode_claims()  # the runtime's JWT authorizer already validated the token
    agent = (claims.get("act") or {}).get("sub")
    if agent in REGISTERED_AGENTS and claims.get("cid") == agent:
        return
    raise ToolError("insufficient_privileges: this server accepts only tokens that a registered "
                    "AI agent obtained through Okta Cross App Access")

def _require_write() -> None:
    _require_agent()
    if WRITERS_GROUP in _groups() and "xaa:write" in _scopes():
        return
    raise ToolError(f"insufficient_privileges: this tool requires membership in '{WRITERS_GROUP}'")

两项检查都堵住了我们发现的缺口：允许没有 groups 声明的令牌的写入检查，让不属于任何一组的 Carol 创建了任务；在 _require_agent 之前，一个签发给没有 act 声明的服务应用的普通令牌交换令牌，为 Bob 创建了任务。服务器可以不再次验证令牌就读取声明，只是因为运行时的 JWT 授权器已经验证过它。前面没有该授权器的服务器必须自己检查签名、签发者、受众和过期，正如第 2 部分中 Amazon EKS 上的智能体所做的那样。

验证结果

我们对已部署的方案运行了每一项检查。Alice、Bob 和 Carol 各自要求智能体创建任务，然后列出项目的任务：

这些请求在工具运行之前就停住了：

AgentCore Identity 返回的令牌与我们直接在 Okta 兑换的令牌逐项声明匹配：sub 是用户，cid 和 act 点名智能体，scp 持有连接的范围，groups 持有用户的组，并且它存活 300 秒。

对一次端到端大约 30 秒的请求，AgentCore Identity 增加大约 0.6 秒，其中大部分是模型和工具调用。来自我们测试客户端的五次运行的中位数：

在运行中治理智能体

Okta 在铸造 ID-JAG 时评估智能体、用户和连接。我们测量了每项管理员操作对下一次请求和已签发令牌的影响：

对一个智能体的操作让另一个继续工作。Okta 在兑换 ID-JAG 时不重新检查用户：在我们移除用户 3 秒后，其自定义授权服务器仍为一个在移除之前铸造的 ID-JAG 签发了访问令牌。Okta 的系统日志把每次许可记为以智能体为行动者，第 2 部分把这些事件流入 CloudWatch。

委托链的最佳实践

这些测量得出六条做法，每一条都是这条链的属性，而不是偏好：

跨应用访问与普通令牌交换的对比

普通的 RFC 8693 令牌交换也会把用户身份带到下游。我们在同一个 Okta 授权服务器和用户上把它与 XAA 对比：

这些结果反映我们的 Okta 配置。Okta 的指南展示了被交换令牌的 act 声明，而我们没有收到。普通令牌交换携带了用户身份，但没有携带用户权限。

这一模式适用的地方

我们与媒体和娱乐公司合作，也是我们最先遇到这个问题的地方。制片厂、流媒体或游戏组织让智能体对着制作跟踪、标题和资产元数据、权利和本地化，以及观众或玩家支持来运行。每个系统有自己的授权模型和自己的审计方，用户的权限因标题、地域或发行窗口而不同，因此在智能体上线之前必须回答“哪个智能体可能为哪个用户在哪个系统里行动”。

这条链里没有任何东西是该行业特有的：智能体是你的 IdP 中的一个身份，目标是一台 OAuth 2.0 授权服务器，用户的权限搭在一个声明里。金融服务、医疗和公共部门团队把不同的资源放在同一套控制后面。

清理

为避免持续费用，删除你创建的资源：

• 删除 AgentCore CLI 为智能体和两台 MCP 服务器创建的 AWS CloudFormation 堆栈。

• 用 aws bedrock-agentcore-control delete-oauth2-credential-provider --name okta-xaa-obo 删除凭证提供方，并用 delete-workload-identity 删除你自己创建的任何工作负载身份。

• 删除你添加到执行角色上的 IAM 策略。

• 在 Okta 中，停用并删除人工智能智能体及其关联应用，并移除资源连接、授权服务器的策略规则、范围和声明，以及测试用户和组。

结论

在本文中，你使用 Okta 跨应用访问来决定哪个智能体可能为哪个用户行动，并使用 AgentCore Identity 来执行每一项决定。运行时只接纳该智能体自己的 ID-JAG，凭证提供方用智能体并不持有的密钥兑换每一个，令牌保管库在一次请求内复用结果，MCP 服务器根据 groups 声明强制每个用户的权限。

这一设计把交换留在智能体的角色里，并在每台 MCP 服务器中重复授权检查。见本系列第 2 部分，了解其设计为何把两者都移到一个带 Cedar 策略的 AgentCore 网关后面，增加 Amazon EKS 上的第二个智能体，并把 Okta 系统日志与 CloudWatch 中的 AgentCore 追踪接在一起。

要开始，查看 AgentCore 示例和 Okta 的跨应用访问文档。API 细节见 AgentCore 开发者指南中的代表用户令牌交换。

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/govern-ai-agent-access-with-okta-cross-app-access-and-amazon-bedrock-agentcore-part-1