Amazon Bedrock AgentCore Identityで「Private Key JWT」認証を使う方法Authenticate with Private Key JWT using Amazon Bedrock AgentCore Identity

Amazon Web Services has published guidance on using Private Key JWT client authentication with Amazon Bedrock AgentCore Identity, giving developers a more security-conscious way to connect AI agents to external identity providers. The topic matters because agents increasingly need to obtain OAuth tokens to call downstream APIs and tools, and the method used to authenticate the agent as a client directly shapes how those credentials are created, stored, and exposed.

Private Key JWT is an OAuth 2.0 client authentication method, standardized in the context of RFC 7523 and OpenID Connect, in which the client proves its identity by presenting a signed JSON Web Token (a JWT assertion) rather than sending a shared client secret. The client signs the assertion with a private key, and the identity provider validates it using the corresponding public key. Because no shared secret travels over the network or sits in configuration where it could leak, this pattern is generally regarded as stronger than secret-based methods such as client_secret_post or client_secret_basic. The trade-off is added setup: you must manage a key pair and register the public half with the identity provider.

The AWS post explains how this authentication flow works inside AgentCore Identity and reviews the grant flows it supports. AgentCore Identity is the component of Amazon Bedrock AgentCore responsible for handling authentication and authorization so that agents can securely acquire and use tokens. In practice, OAuth deployments distinguish between machine-to-machine access, where an agent acts on its own behalf, and delegated access, where an agent acts for a signed-in user. Private Key JWT can serve as the client authentication layer underneath these flows, replacing a static secret with a cryptographic assertion regardless of which grant is used to obtain the token.

A central element of the walkthrough is the use of AWS Key Management Service (KMS) to generate the signing key. Rather than creating a private key file that lives on disk or in an application, the guide describes creating an asymmetric KMS signing key, where the private key is generated inside KMS and never leaves the service. Signing operations are performed through KMS API calls, so the agent requests a signature for the JWT assertion without ever handling the raw private key material directly. This design reduces the risk of key exfiltration and centralizes access control and auditing through AWS Identity and Access Management and CloudTrail, which is a common motivation for using KMS in credential workflows.

The post then covers registering the KMS public key with your identity provider. Because the identity provider needs the public half of the key pair to verify incoming assertions, the public key is extracted from KMS and configured on the IdP side, typically as part of the client or application registration. After that, the guide walks through configuring a credential provider on the AgentCore side so the agent knows how to construct, sign, and present the Private Key JWT when requesting tokens. Together, these steps connect the KMS-held signing key, the identity provider's verification configuration, and the agent runtime into a single working authentication path.

For readers new to this area, some background helps. Amazon Bedrock AgentCore is AWS's set of services for building, deploying, and operating AI agents, and identity is one of several concerns it addresses alongside runtime execution, memory, and tool access. Private Key JWT is not unique to AWS; it appears across enterprise identity platforms and is frequently required by providers that enforce stronger client authentication, including in regulated environments and certain financial-grade API profiles. Developers who have used JWT bearer assertions, mutual TLS client authentication, or the OAuth client credentials grant will recognize the underlying concepts.

The overall value of the guidance is likely to be practical rather than conceptual: it documents a concrete sequence for teams that want to avoid embedding long-lived secrets in agent configurations. As agent frameworks mature, tying client authentication to a managed key service such as KMS appears consistent with broader industry moves toward secretless and short-lived credential patterns. Organizations evaluating the approach should still confirm that their chosen identity provider supports Private Key JWT and the specific grant flows their agents require before adopting it.