Amazon AWS 为 AgentCore Identity 添加 Private Key JWT，以 KMS 控制取代共享密钥

Amazon AWS 已为 AgentCore Identity 添加 Private Key JWT 身份验证，为自动化 agent 提供了长期 OAuth client secret 的新替代方案。这项变更将客户端身份验证转向由 AWS Key Management Service 支持的短期签名断言，同时也让 AWS CloudTrail 能更清晰地记录每一次签名请求。

这一组合之所以重要，是因为自主 agent 请求 token 的频率可能远高于面向普通员工的传统应用。被复制的 client secret 在有人轮换或撤销前仍可能有效；而 Private Key JWT 断言会很快过期，并且每次新请求都需要访问受保护的签名密钥。

核心矛盾并不只是密钥与密码之争。Amazon Bedrock AgentCore Identity 如今承诺在不要求开发者自行构建和运维签名服务的情况下，提供更强的控制能力。这一承诺能否兑现，取决于与身份提供商的兼容性、精确的声明配置、KMS 权限以及完整的审计覆盖范围。

Amazon AWS 将 OAuth 客户端身份验证纳入 KMS

关键变化在于，AgentCore Identity 无需存储可重复使用的 client secret，即可验证 OAuth client。

根据 Private Key JWT 公告中描述的新模式，AgentCore Identity 会构建 JSON Web Token，并通过 AWS KMS 对其签名。身份提供商使用相应的公钥验证该签名。

私钥始终保留在 KMS 内部。agent、应用进程或管理员无需将密钥导出到配置文件、容器镜像、环境变量或独立的密钥存储中。

这个已签名的 JWT 是一种 client assertion，也就是说，它向授权服务器证明 OAuth client 的身份。它并不是最终提供给 API 的 access token。授权服务器会先验证该断言，再签发 access token。

这一差异很容易被忽略。OAuth 客户端身份验证回答的是：请求 token 的应用是否为已注册 client；而 OAuth grant 则决定最终 token 代表谁的授权，以及它获得哪些权限。

因此，Private Key JWT 可以用于不止一种 grant flow。AgentCore Identity 支持通过 authorization code grant 实现用户委托访问，并通过 client credentials 实现 machine-to-machine 访问。其更广泛的 authentication patterns 还涵盖 on-behalf-of token exchange 配置。

对于用户委托请求，用户首先通过身份提供商授权访问。随后，AgentCore Identity 会在以 authorization code 交换 token 时验证 OAuth client。用户批准与 client 身份仍是彼此独立的控制措施。

对于 machine-to-machine 请求，则没有用户完成交互式同意页面。agent 会以应用自身的授权请求 access token。Private Key JWT 会在 client credentials 交换期间验证该应用。

这使该功能的意义不止于登录。它面向的是 agent 对企业 API、软件服务和其他受保护资源的出站访问。这些正是静态凭证可能成为运维负担的连接场景。

AgentCore Identity 已充当 agent、授权服务器和资源服务器之间的中介。它会获取凭证，同时让长期 secret 和 refresh token 不接触 agent 代码。Private Key JWT 将这一边界扩展到了 OAuth client 的身份验证材料。

现在，请求路径包含多个明确阶段。agent 向 AgentCore Identity 请求已授权的访问；AgentCore Identity 创建时限受控的断言，调用 KMS 对其签名，再将其发送至身份提供商的 token endpoint。

身份提供商会根据已注册公钥检查签名，同时评估用于识别 client、audience、签发时间和过期时间的声明。如果这些检查均通过，提供商便会经由 AgentCore Identity 返回 access token。

这一设计并未消除信任，而是将信任转移到 KMS policy、IAM role、OAuth 配置以及身份提供商的公钥注册中。这些控制措施比一串被复制的字符串更细粒度，但也增加了身份验证可能因配置不匹配而中断的位置。

Private Key JWT 如何改变密钥模型

Private Key JWT 减少了对共享密钥的依赖，但其安全性取决于对谁可以请求 KMS 签名的控制。

传统 OAuth 客户端身份验证通常使用 client_secret_basic 或 client_secret_post。两种方法都会将 client ID 和共享 secret 发送至授权服务器。区别在于，这些凭证是出现在 HTTP Basic header 中，还是请求正文中。

AWS 文档将 HTTP Basic 描述为自定义 AgentCore Identity provider 的默认方法。该 secret 会一直可重复使用，直至被轮换、过期或撤销。持有其副本的每一个系统，都会成为该凭证安全边界的一部分。

Private Key JWT 用非对称密钥对取代了这一对称模型。一方控制私有签名密钥，而身份提供商仅存储用于验证的公钥。公钥泄露并不能让攻击者生成有效断言。

该方法遵循 OAuth JWT profile，该规范定义了用于客户端身份验证和授权 grant 的 JWT。token 请求包含 client assertion，并将其标识为 JWT bearer assertion。

一个典型断言包含标识 client 的 issuer claim、该 client 的 subject claim，以及指向 token endpoint 的 audience claim。它还包括过期时间和签发时间。唯一的 JWT identifier 可帮助身份提供商检测重放尝试。

这些字段并非装饰性元数据。错误的 audience 会使签名正确的 JWT 仍然无效。时钟差异则可能导致提供商以尚未生效或已过期为由拒绝断言。

Private Key JWT 也不会自动保证重放保护。RFC 7523 将部分重放防御交由部署策略处理。身份提供商需要设置适当的有效期限制，并在支持的情况下跟踪唯一断言。

较短的过期时间窗口会缩短被截获断言的可利用时间，但无法保护攻击者能够反复调用签名密钥的系统。这正是 KMS key policy 和 IAM permission 成为核心执行层的原因。

AWS KMS 将非对称密钥表示为相互关联的公钥和私钥对。对于签名密钥，私有部分始终在服务内部受到保护；公钥则可以下载并注册到外部身份提供商。

KMS 支持多种 asymmetric key types，包括用于签名和验证的 RSA 与椭圆曲线密钥。所选密钥类型和算法必须与身份提供商接受的类型相匹配。

AgentCore Identity 需要权限才能使用已配置密钥进行签名。AWS 表示，KMS Sign 操作的调用方需要通过 key policy 获得 kms:Sign 授权。随后，该服务会使用私有部分，但不会返回它。

这带来了实质性的隔离改进。暴露 key ARN 的配置泄露不会暴露私钥材料。攻击者仍需要 AWS credentials，以及调用该密钥的有效授权。

不过，签名权限仍然敏感。拥有广泛 kms:Sign 访问权限的 role，可能会在预期工作负载路径之外请求签名。团队应将权限绑定到正确的 AgentCore execution roles，并避免使用通用的通配符访问。

这一变更也会影响轮换。使用共享 secret 时，双方都必须替换同一个机密值；采用非对称身份验证时，团队可以在身份提供商处引入新的公钥，同时在受控过渡期间保留旧验证密钥。

只要身份提供商支持多个活跃密钥，这种重叠便可减少停机时间。如果它只接受一个公钥，轮换仍需要协调时机。Private Key JWT 改变了轮换的材料，而非免除了经过测试的轮换流程的必要性。

支持的 Grant Flow 对应不同的 Agent 身份

Private Key JWT 用于验证 OAuth client，而所选 grant 决定 agent 是代表自身还是代表用户行事。

authorization code grant 适合代表个人访问资源的 agent。用户通过身份提供商登录，并批准所请求的权限。授权服务器会返回一个 code，client 再用它交换 token。

在该交换过程中，AgentCore Identity 使用 Private Key JWT assertion 来证明提出请求的是已注册 client。该 assertion 不会替代用户同意，而是强化了 token endpoint 的身份验证。

这一 flow 适用于读取用户日历、搜索员工已获授权记录，或在委托权限内更新客户管理系统的 agent。生成的访问权限仍与用户及其批准的 scope 绑定。

client credentials grant 则面向另一种情况：工作负载无需交互式用户即可代表自身行事。计划任务 agent 可能调用内部库存 API、处理服务告警，或检索获批准的运营数据。

Private Key JWT 会先验证这一机器 client，授权服务器随后才签发 application token。由于没有用户参与，client identity、token scope 和下游 authorization policy 承担了更大的安全责任。

组织不应把两种 grant 视为可互换的部署选项。对于本应保留用户身份的任务使用 client credentials，可能会模糊责任追踪；对后台服务工作使用 delegated flow，则可能对个人账户产生脆弱依赖。

on-behalf-of 访问引入了另一种变化。agent 接收现有用户身份的凭据，并将其交换为适用于另一资源的 token。该 flow 必须保留用户、agent 和目标服务之间的关系。

AgentCore Identity 文档描述了这些场景下的标准 token exchange 与基于 JWT 的 authorization grant 方法。支持情况仍取决于外部授权服务器及其 token-exchange 规则。

Private Key JWT 可以验证参与该交换的 client。它不决定传入的用户 token 是否有效，也不决定请求的委托是否应获准。这些判断仍由相关身份与授权系统负责。

这种分离是该功能最强的架构优势之一。团队可以根据 agent 所需的授权选择 grant，再根据 client 应如何证明自身身份选择 Private Key JWT。

这也说明，将其简单理解为单一“agent credential”并不安全。agent 可以拥有工作负载身份、代表用户运行、调用多个资源服务器，并为每个目标使用不同的 token。

AgentCore Identity 的工作负载访问令牌又增加了一层。AWS 表示，当代理从保险库请求凭证时，该令牌可以携带代理身份和最终用户身份。AgentCore Runtime 可以自动将其提供给托管代理。

该工作负载令牌用于授权访问 AgentCore Identity。外部 OAuth 访问令牌用于授权访问目标 API。Private Key JWT 断言则在令牌签发过程中对 OAuth 客户端进行身份验证。

因此，在一次端到端交易中可能会出现三种令牌，各自承担不同职责。混淆它们可能导致错误验证、过度日志记录或意外泄露。

安全审查应将每种令牌映射到其签发者、受众、持有者、有效期和目标位置。还应识别哪个组件能够刷新或替换它。这样的梳理能够发现产品级架构图可能掩盖的设计错误。

更广泛的竞争压力则落在基于密钥的代理集成方案上。静态客户端密钥为人熟知且获得广泛支持，但当大量自主工作负载需要独立权限和审计追踪时，其扩展性较差。

Private Key JWT 提高了配置门槛，同时减少了凭证重复。对于已在运行 AWS IAM、KMS 和 CloudTrail 的团队而言，这一取舍可能颇具吸引力。对于规模较小的部署，新增的策略管理复杂度可能超过眼前收益。

配置信任链不仅仅是选择一种方法

只有当 KMS、IAM、AgentCore Identity 和外部身份提供商在相同的加密与 OAuth 细节上达成一致时，配置才能成功。

首要要求是配置用于签名和验证的非对称 KMS 密钥。加密密钥无法完成这项工作。密钥规范和签名算法必须与目标身份提供商接受的组合相匹配。

AWS KMS 会公开非对称签名密钥的公钥部分。团队可直接注册该公钥，或通过受支持的 JSON Web Key 配置将其注册到身份提供商处。

身份提供商必须将该密钥关联至正确的 OAuth 客户端。它还必须在其令牌端点支持 Private Key JWT。不同提供商的注册界面和接受的算法各不相同，因此这一步仍具有提供商特定性。

接下来，管理员需在 Amazon Bedrock AgentCore 控制台中创建或更新自定义 OAuth 凭证提供商。配置需要提供商的发现信息、客户端标识符、KMS 密钥 ARN 和签名算法。

OAuth 发现机制让 AgentCore Identity 能够从提供商的元数据中定位授权端点和令牌端点。团队应验证发现到的令牌端点是否与身份提供商预期的受众值相符。

AgentCore Identity 还需要调用 KMS 的权限。KMS 的签名操作要求密钥具有 SIGN_VERIFY 用途，并使用与该密钥兼容的算法。

根据所选消息类型，KMS 可接受原始消息或预先计算的摘要。JWT 实现必须避免意外的重复哈希，因为外部验证依赖于算法规定的哈希行为。

JWT 标头配置同样重要。身份提供商可使用密钥标识符选择合适的公钥。在轮换期间多个公钥可能同时处于活动状态，缺失或错误的标识符会尤其棘手。

载荷声明也需要同等谨慎处理。签发者和主体通常对应 OAuth 客户端 ID。受众通常标识授权服务器的令牌端点，但具体值应以提供商要求为准。

过期时间应保持较短。签发时间必须反映已同步的时钟。在提供商记录此前已接受断言的场景中，唯一令牌标识符很有价值。

保存凭证提供商后，团队应分别测试每一种预期授权类型。成功的客户端凭证请求并不能证明授权码交换或令牌交换已正确配置。

测试应从最小权限范围开始。如果身份验证成功但授权失败，二者的区别会更容易诊断。为绕过错误而添加广泛权限，可能掩盖受众或客户端注册问题。

团队还应测试失败路径。使用错误密钥签名的请求应当失败。过期断言应当失败。错误受众和未经授权的 KMS 调用方也都应产生可区分的证据。

这正是运营层面的取舍变得清晰的地方。共享密钥足够简单，团队通常只验证成功路径。Private Key JWT 提供了更强的边界，但这些边界需要明确测试。

该配置还会在行政团队之间形成依赖。云安全团队可能负责 KMS 和 IAM 策略。身份团队可能控制 OAuth 客户端及公钥注册。

应用所有者配置 AgentCore Identity 并确定授权范围。审计团队决定必须保留并触发告警的 CloudTrail 记录。没有任何一项控制台选择能够解决这些权责划分问题。

一个实用的推广方式是从一项非关键集成开始。团队可以在将该方法应用到大量代理之前，先记录声明要求、失败响应、轮换步骤和升级责任归属。

在首次经过验证的部署完成后，应再推进自动化。基础设施模板可以标准化密钥策略和凭证提供商设置，但不应臆测身份提供商的行为。

结果并非一个无密钥系统。令牌仍然存在，授权服务器仍掌握信任，AWS 权限仍属于凭证。更严谨的说法是：OAuth 客户端不再依赖一个共享、可复用的密钥。

CloudTrail 将每次签名转化为审计信号

由 KMS 支持的签名为防御人员提供了可与令牌请求和代理活动关联的 AWS 侧事件。

AWS KMS 与 CloudTrail 集成，后者会记录用户、角色和 AWS 服务发起的调用。其 KMS 审计日志记录涵盖加密操作以及密钥管理操作。

因此，一次 Private Key JWT 交易应会围绕 KMS 签名请求产生证据。该事件可以标识所涉及的操作、区域、时间、相关密钥，以及 AWS 主体或服务上下文。

仅凭该记录并不能呈现完整情况。CloudTrail 表明获授权的 AWS 身份请求了签名。外部身份提供商的日志则显示它是否接受了该断言并签发令牌。

目标服务的审计日志显示生成的访问令牌执行了什么操作。有效的调查会关联这三层信息，而不是将 KMS 事件视为资源访问成功的证明。

CloudTrail 仍可回答重要问题。调查人员可以查找异常签名量、来自错误角色的请求、未经批准区域中的调用，或涉及超出正常使用计划密钥的活动。

所配置的事件选择器很重要。AWS 将 KMS 事件归类为管理事件，而 CloudTrail 跟踪通常会记录管理活动。不过，管理员可以明确排除 KMS 事件。

AWS 警告称，KMS 操作可能产生大量事件。一些组织为控制日志量而对其进行过滤。这样做可能会移除使该身份验证模式更易于审计的关键签名证据。

采用 Private Key JWT 的团队应审查其管理事件设置。他们应确认相关 KMS 活动会进入预期的跟踪或事件数据存储。

保留期限和可搜索性同样重要。事件历史记录有助于近期调查，而跟踪或 CloudTrail Lake 事件数据存储支持更长期的分析。导出的记录也可以输入安全监控系统。

基准应区分预期的令牌刷新行为与异常情况。持续运行的机器代理可能会以固定节奏签署断言。用户委派的工作流则可能在活跃会话期间产生突发请求。

显著偏差可能表明重试循环、配置失败或凭证滥用。反复签名后又遭令牌端点拒绝，可能指向错误的受众、过期的公钥或时钟问题。

没有相应 AgentCore 请求的签名活动值得进一步检查。成功签发令牌却没有预期的下游调用也是如此。每一种模式都指向信任链中不同的断点。

密钥生命周期事件应接收单独告警。禁用签名密钥可能使所有依赖集成立即中断。策略变更可能会悄然扩大被允许调用它的主体范围。

CloudTrail 在轮换期间同样有帮助。团队可以观察新密钥启用后旧密钥是否仍收到签名请求。持续活动可能暴露被忽略的凭证提供商或延迟的部署。

不过，审计可见性仍有前提。日志必须启用、保留、保护并接受审查。记录了却从未查询的事件几乎无法提供实际防御能力。

CloudTrail 事件也无法验证请求背后的业务理由。一个获得适当授权的代理仍可能在错误的时间请求访问令牌，或将其用于范围过宽的任务。

这一限制将注意力转向授权设计。Private Key JWT 可以证明客户端控制着对签名密钥的访问权。它无法判断代理的目标、所选工具或请求操作是否恰当。

组织需要围绕加密证明实施范围限制、资源服务器策略、工作负载控制和行为监控。签名是一种高质量信号，但并非完整的代理治理系统。

Private Key JWT 上线后企业应关注什么

接下来的考验在于，Private Key JWT 会成为运营默认方案，还是仍只是一项面向严格管理部署的高级选项。

第一个信号是身份提供商的互操作性。成功采用要求提供商接受所选签名算法、声明、受众格式和公钥注册方法。

AWS 可以简化交换流程中自身的一侧，但无法标准化每个提供商的管理工作流。清晰、针对特定提供商的示例将减少部署失败和不安全的变通做法。

第二个信号是轮换行为。企业需要了解能否注册重叠的公钥、不中断地更新 AgentCore 提供商，以及通过审计记录确认迁移。

仅在初始设置期间有效的功能只解决了一半问题。生产身份验证还需要在密钥被禁用、替换或泄露时具备可预测的恢复机制。

第三个信号是审计采用情况。CloudTrail 让团队能够访问签名记录，但组织必须保留 KMS 事件，并将其与身份提供商和资源服务器日志关联起来。

检测指导会让这项功能更有用。高签名频率、不熟悉的主体、重复错误和意外的区域活动，都是切实可行的告警候选项。

安全团队还应关注 AgentCore Identity 权限模型的边界。理想策略应允许一个工作负载为一个获批准的提供商使用一把签名密钥，同时不授予无关的签名访问权限。

跨账户密钥提高了灵活性，但需要谨慎的资源策略。AWS KMS 支持跨账户签名使用，前提是调用方指定密钥 ARN 并获得所需权限。

这一能力可支持集中式的安全职责管理，但也会在应用账户与中央身份账户之间形成依赖。中央账户发生故障或策略配置失误，可能影响大量 Agent。

企业应衡量实际运营结果，而非假定加密设计必然能够保证成功。可用指标包括密钥轮换工作量、令牌请求失败次数、未授权签名尝试，以及密钥变更后的恢复时间。

企业还应将 Private Key JWT 与 AWS IAM 签名 JWT 身份验证进行比较。AgentCore Identity 文档描述了一种 AWS_IAM_ID_TOKEN_JWT 方法：该方法使用由 IAM 签发的断言，并要求授权服务器信任 AWS IAM。

这两种方法都摆脱了共享客户端密钥，但建立信任的方式不同。Private Key JWT 要求身份提供商信任由客户自行管理的公钥；IAM 方法则要求其信任 AWS IAM 这一签发方。

提供商支持情况往往决定哪种路径具有可行性。一些身份系统已支持将 Private Key JWT 用于机密 OAuth 客户端；直接接受 AWS IAM 作为签发方的系统可能较少完成相应配置。

因此，Private Key JWT 处于一个颇具价值的中间位置。它采用标准 OAuth 身份验证方式，同时让私有签名材料继续受 KMS 控制。

这一功能更广泛的意义，在于它如何对待 Agent：平台并不向 Agent 提供可重复使用的凭证，而是在需要访问时执行一次权限范围严格限定的加密操作。

这种模式降低了被复制配置数据的价值，也为每次令牌请求建立了可强制执行的检查点。对于高频运行、且监督有限的自主工作负载而言，这些都是实质性的改进。

代价是需要更精确地进行配置。团队必须协调算法、公钥、JWT 声明、IAM 策略、OAuth 授权、令牌范围以及日志控制。

Amazon AWS 通过将签名功能纳入 AgentCore Identity，使这种复杂性更易于管理。但它并未让围绕信任的决策就此消失。

在广泛采用这一方法前，应选择一个具有代表性的 Agent，并追踪其完整访问路径。识别其中涉及的每个主体、令牌、授权、范围、日志来源和撤销机制。

随后应测试轮换与故障情形，而不只是验证身份验证能否成功。如果团队能够说明每次签名由谁请求，以及之后发生了什么，那么 Private Key JWT 所做的就不只是替代一个密钥。