Amazon AWS Adds Private Key JWT to AgentCore Identity, Trading Shared Secrets for KMS Control

Amazon AWS has added Private Key JWT authentication to AgentCore Identity, giving automated agents a new alternative to long-lived OAuth client secrets. The change moves client authentication toward short-lived, signed assertions backed by AWS Key Management Service. It also creates a clearer record of each signing request in AWS CloudTrail.

That combination matters because an autonomous agent can request tokens far more frequently than a conventional employee-facing application. A copied client secret can remain useful until someone rotates or revokes it. A Private Key JWT assertion expires quickly and requires access to a protected signing key for every new request.

The central tension is not simply keys versus passwords. Amazon Bedrock AgentCore Identity now promises stronger control without forcing developers to build and operate their own signing service. Whether that promise holds depends on identity-provider compatibility, precise claim configuration, KMS permissions, and complete audit coverage.

Amazon AWS Moves OAuth Client Authentication Into KMS

The important change is that AgentCore Identity can authenticate an OAuth client without storing a reusable client secret.

In the new pattern described by the Private Key JWT announcement, AgentCore Identity constructs a JSON Web Token and signs it through AWS KMS. The identity provider verifies that signature using the corresponding public key.

The private key remains inside KMS. An agent, application process, or administrator does not need to export the key into a configuration file, container image, environment variable, or separate secret store.

The signed JWT is a client assertion, meaning it proves the OAuth client’s identity to an authorization server. It is not the access token ultimately presented to an API. The authorization server validates the assertion before issuing that access token.

This distinction is easy to miss. OAuth client authentication answers whether the application requesting a token is the registered client. The OAuth grant determines whose authority the resulting token represents and which permissions it receives.

Private Key JWT can therefore operate across more than one grant flow. AgentCore Identity supports user-delegated access through the authorization code grant and machine-to-machine access through client credentials. Its broader authentication patterns also cover on-behalf-of token exchange configurations.

For a user-delegated request, a person first authorizes access through the identity provider. AgentCore Identity then authenticates the OAuth client when exchanging the authorization code for tokens. The user’s approval and the client’s identity remain separate controls.

For a machine-to-machine request, no user completes an interactive consent screen. The agent requests an access token under the application’s own authority. Private Key JWT authenticates that application during the client credentials exchange.

That makes the feature relevant beyond login. It targets outbound access from agents to enterprise APIs, software services, and other protected resources. These are precisely the connections where a static credential can become an operational liability.

AgentCore Identity already acts as an intermediary between agents, authorization servers, and resource servers. It retrieves credentials while keeping long-term secrets and refresh tokens away from agent code. Private Key JWT extends that boundary to the OAuth client’s authentication material.

The request path now has several explicit stages. The agent asks AgentCore Identity for authorized access. AgentCore Identity creates a time-limited assertion, calls KMS to sign it, and sends it to the identity provider’s token endpoint.

The identity provider checks the signature against the registered public key. It also evaluates claims identifying the client, audience, issuance time, and expiration. If those checks pass, the provider returns an access token through AgentCore Identity.

This design does not eliminate trust. It relocates trust into KMS policies, IAM roles, OAuth configuration, and the identity provider’s public-key registration. Those controls are more granular than one copied string, but they also introduce more places where a mismatch can stop authentication.

How Private Key JWT Changes the Secret Model

Private Key JWT reduces reliance on shared secrets, but its security depends on controlling who can ask KMS to sign.

Traditional OAuth client authentication commonly uses client_secret_basic or client_secret_post. Both methods send a client ID and shared secret to the authorization server. The difference is whether those credentials appear in an HTTP Basic header or the request body.

AWS documentation describes HTTP Basic as the default method for custom AgentCore Identity providers. The secret remains reusable until rotation, expiration, or revocation. Every system holding a copy becomes part of the credential’s security boundary.

Private Key JWT replaces that symmetric model with an asymmetric key pair. One party controls the private signing key, while the identity provider stores only the public verification key. Exposure of the public key does not let an attacker generate valid assertions.

The approach follows the OAuth JWT profile, which defines JWTs for client authentication and authorization grants. The token request includes a client assertion and identifies it as a JWT bearer assertion.

A typical assertion contains an issuer claim identifying the client, a subject claim for that client, and an audience claim naming the token endpoint. It also includes expiration and issuance times. A unique JWT identifier can help an identity provider detect replay attempts.

Those fields are not decorative metadata. An incorrect audience can make a correctly signed JWT invalid. A clock difference can cause the provider to reject an assertion as premature or expired.

Private Key JWT also does not automatically guarantee replay protection. RFC 7523 leaves some replay defenses to deployment policy. Identity providers need appropriate lifetime limits and, where supported, unique assertion tracking.

Short expiration windows narrow the usefulness of a captured assertion. They do not protect a system where an attacker has permission to invoke the signing key repeatedly. That is why the KMS key policy and IAM permissions become the core enforcement layer.

AWS KMS represents an asymmetric key as a linked public and private pair. For signing keys, the private component remains protected inside the service. The public component can be downloaded and registered with an external identity provider.

KMS supports multiple asymmetric key types, including RSA and elliptic-curve keys for signing and verification. The chosen key type and algorithm must match what the identity provider accepts.

AgentCore Identity needs permission to use the configured key for signing. AWS states that callers of the KMS Sign operation require kms:Sign authorization through the key policy. The service then uses the private component without returning it.

This is a meaningful containment improvement. A configuration leak exposing a key ARN does not reveal private key material. An attacker would still need AWS credentials and effective authorization to invoke the key.

However, permission to sign remains sensitive. A role with broad kms:Sign access could potentially request signatures outside the intended workload path. Teams should bind permissions to the correct AgentCore execution roles and avoid general wildcard access.

The change also affects rotation. With a shared secret, both sides must replace the same confidential value. With asymmetric authentication, teams can introduce a new public key at the identity provider while retaining the old verifier during a controlled transition.

That overlap can reduce downtime, provided the identity provider supports multiple active keys. If it accepts only one public key, rotation still demands coordinated timing. Private Key JWT changes the material being rotated, not the need for a tested rotation process.

The Supported Grant Flows Serve Different Agent Identities

Private Key JWT authenticates the OAuth client, while the selected grant determines whether an agent acts for itself or a user.

The authorization code grant fits agents that access resources on a person’s behalf. A user signs in through an identity provider and approves requested permissions. The authorization server returns a code that the client exchanges for tokens.

During that exchange, AgentCore Identity uses the Private Key JWT assertion to prove that the registered client is making the request. The assertion does not replace user consent. It strengthens authentication at the token endpoint.

This flow suits an agent reading a user’s calendar, searching an employee’s authorized records, or updating a customer-management system within delegated permissions. The resulting access remains tied to the user and the approved scopes.

The client credentials grant addresses a different case. Here, the workload acts as itself without an interactive user. A scheduled agent might call an internal inventory API, process service alerts, or retrieve approved operational data.

Private Key JWT authenticates that machine client before the authorization server issues an application token. Because no person is present, the client identity, token scopes, and downstream authorization policy carry more of the security burden.

Organizations should not treat the two grants as interchangeable deployment options. Using client credentials for a task that should preserve user identity can obscure accountability. Using a delegated flow for background service work can create brittle dependencies on individual accounts.

On-behalf-of access introduces another variation. An agent receives evidence of an existing user identity and exchanges it for a token suited to another resource. The flow must preserve the relationship among the user, agent, and destination service.

AgentCore Identity documentation describes both standard token exchange and JWT-based authorization grant approaches for these cases. Support still depends on the external authorization server and its token-exchange rules.

Private Key JWT can authenticate the client participating in that exchange. It does not decide whether the incoming user token is valid or whether the requested delegation should be allowed. Those decisions remain with the relevant identity and authorization systems.

This separation is one of the feature’s strongest architectural points. Teams can choose a grant based on the authority an agent needs, then choose Private Key JWT based on how the client should prove its identity.

It also highlights why a single “agent credential” is an unsafe mental model. An agent can have a workload identity, operate for a user, call several resource servers, and use different tokens for each destination.

AgentCore Identity’s workload access token adds another layer. AWS says that token can carry the agent’s identity and the end user’s identity when the agent requests credentials from the vault. AgentCore Runtime can provide it to hosted agents automatically.

That workload token authorizes access to AgentCore Identity. The external OAuth access token authorizes access to the destination API. The Private Key JWT assertion authenticates the OAuth client during token issuance.

Three tokens can therefore appear in one end-to-end transaction, each with a different job. Confusing them can lead to incorrect validation, excessive logging, or accidental exposure.

Security reviews should map each token to its issuer, audience, holder, lifetime, and destination. They should also identify which component can refresh or replace it. That exercise catches design mistakes that product-level diagrams can hide.

The broader competitive pressure falls on secret-based agent integrations. Static client secrets are familiar and widely supported, but they scale poorly when many autonomous workloads need independent permissions and audit trails.

Private Key JWT raises the setup burden while reducing credential duplication. For teams already operating AWS IAM, KMS, and CloudTrail, that trade can be attractive. For smaller deployments, the added policy surface may outweigh the immediate benefit.

Configuring the Trust Chain Requires More Than Selecting a Method

The setup succeeds only when KMS, IAM, AgentCore Identity, and the external identity provider agree on the same cryptographic and OAuth details.

The first requirement is an asymmetric KMS key configured for signing and verification. Encryption keys cannot perform this job. The key specification and signing algorithm must match a combination accepted by the target identity provider.

AWS KMS exposes the public part of an asymmetric signing key. Teams register that public key with their identity provider, either directly or through a supported JSON Web Key configuration.

The identity provider must associate the key with the correct OAuth client. It must also support Private Key JWT at its token endpoint. Registration interfaces and accepted algorithms differ across providers, so this step remains provider-specific.

Next, administrators create or update a custom OAuth credential provider in the Amazon Bedrock AgentCore console. The configuration needs the provider’s discovery information, client identifier, KMS key ARN, and signing algorithm.

OAuth discovery lets AgentCore Identity locate authorization and token endpoints from the provider’s metadata. Teams should verify that the discovered token endpoint matches the audience value expected by the identity provider.

AgentCore Identity also needs permission to invoke KMS. The KMS signing operation requires a key with SIGN_VERIFY usage and an algorithm compatible with that key.

KMS accepts either a raw message or a precomputed digest, depending on the selected message type. A JWT implementation must avoid accidental double hashing because external verification assumes the algorithm’s specified hashing behavior.

JWT header configuration matters as well. The identity provider can use a key identifier to select the appropriate public key. An absent or incorrect identifier becomes especially troublesome during rotation, when several public keys may be active.

Payload claims require equal care. The issuer and subject commonly correspond to the OAuth client ID. The audience normally identifies the authorization server’s token endpoint, although provider requirements should control the exact value.

Expiration should remain short. Issued-at time must reflect a synchronized clock. A unique token identifier is valuable where the provider records previously accepted assertions.

After saving the credential provider, teams should test each intended grant independently. A successful client credentials request does not prove that authorization code exchange or token exchange is configured correctly.

Testing should begin with minimal scopes. If authentication succeeds but authorization fails, the distinction becomes easier to diagnose. Adding broad permissions to bypass an error can conceal an audience or client-registration problem.

Teams should also test negative paths. A request signed with the wrong key should fail. An expired assertion should fail. An incorrect audience and unauthorized KMS caller should each produce distinguishable evidence.

This is where the operational tradeoff becomes visible. Shared secrets are simple enough that teams often validate only the happy path. Private Key JWT provides stronger boundaries, but those boundaries need explicit testing.

The configuration also creates dependencies across administrative teams. A cloud-security team may own KMS and IAM policies. An identity team may control the OAuth client and public-key registration.

Application owners configure AgentCore Identity and determine grant scopes. Audit teams decide which CloudTrail records must be retained and alerted on. No single console selection resolves those ownership questions.

A useful rollout starts with one noncritical integration. Teams can document claim requirements, failure responses, rotation steps, and escalation ownership before applying the method to many agents.

Automation should follow that first validated deployment. Infrastructure templates can standardize key policies and credential-provider settings, but they should not guess at identity-provider behavior.

The result is not a secretless system. Tokens still exist, authorization servers still hold trust, and AWS permissions remain credentials. The narrower claim is more defensible: the OAuth client no longer depends on a shared, reusable secret.

CloudTrail Turns Every Signature Into an Audit Signal

KMS-backed signing gives defenders an AWS-side event they can correlate with token requests and agent activity.

AWS KMS integrates with CloudTrail, which records calls made by users, roles, and AWS services. Its KMS audit logging includes cryptographic operations as well as key-management actions.

A Private Key JWT transaction should therefore create evidence around the KMS signing request. The event can identify the operation, region, time, relevant key, and AWS principal or service context involved.

That record does not contain the full story by itself. CloudTrail shows that an authorized AWS identity requested a signature. The external identity provider’s logs show whether it accepted the assertion and issued a token.

The destination service’s audit logs show what the resulting access token did. An effective investigation correlates all three layers rather than treating the KMS event as proof of successful resource access.

CloudTrail can still answer important questions. Investigators can look for unexpected signing volume, requests from the wrong role, calls in an unapproved region, or activity involving a key outside its normal schedule.

The configured event selectors matter. AWS classifies KMS events as management events, and CloudTrail trails normally record management activity. Administrators can explicitly exclude KMS events, however.

AWS warns that KMS operations can generate high event volumes. Some organizations filter them to control logging volume. Doing so can remove the very signing evidence that makes this authentication pattern easier to audit.

Teams adopting Private Key JWT should review their management event settings. They should confirm that relevant KMS activity reaches the intended trail or event data store.

Retention and searchability matter too. Event history is useful for recent investigation, while a trail or CloudTrail Lake event data store supports longer analysis. Exported records can also feed security monitoring systems.

A baseline should distinguish expected token refresh behavior from anomalies. A continuously running machine agent may sign assertions on a regular cadence. A user-delegated workflow may create bursts during active sessions.

Large deviations can indicate a retry loop, configuration failure, or credential misuse. Repeated signing followed by token-endpoint rejection could point to an incorrect audience, expired public key, or clock problem.

Signing activity without corresponding AgentCore requests deserves closer inspection. So does successful token issuance without the expected downstream calls. Each pattern identifies a different break in the trust chain.

Key lifecycle events should receive separate alerts. Disabling a signing key can halt every dependent integration. Policy changes can silently expand who is allowed to invoke it.

CloudTrail also helps during rotation. Teams can observe whether the old key continues receiving signing requests after a new key becomes active. Continued activity may reveal an overlooked credential provider or delayed deployment.

Audit visibility remains conditional, however. Logs must be enabled, retained, protected, and reviewed. An event recorded but never queried offers little practical defense.

CloudTrail events also do not validate the business reason for a request. A properly authorized agent can still ask for an access token at the wrong time or use it for an overly broad task.

That limitation shifts attention toward authorization design. Private Key JWT can prove the client controls access to a signing key. It cannot determine whether the agent’s objective, selected tool, or requested operation is appropriate.

Organizations need scope restrictions, resource-server policies, workload controls, and behavioral monitoring around the cryptographic proof. The signature is one high-quality signal, not a complete agent governance system.

What Enterprises Should Watch After the Private Key JWT Launch

The next test is whether Private Key JWT becomes an operational default or remains an advanced option for tightly managed deployments.

The first signal is identity-provider interoperability. Successful adoption requires providers to accept the selected signing algorithms, claims, audience format, and public-key registration method.

AWS can simplify its side of the exchange, but it cannot standardize every provider’s administrative workflow. Clear, provider-specific examples would reduce failed deployments and unsafe workarounds.

The second signal is rotation behavior. Enterprises need to know whether they can register overlapping public keys, update AgentCore providers without interruption, and confirm migration through audit records.

A feature that works only during initial setup solves half the problem. Production authentication also needs predictable recovery when a key is disabled, replaced, or compromised.

The third signal is audit adoption. CloudTrail gives teams access to signing records, but organizations must retain KMS events and connect them with identity-provider and resource-server logs.

Detection guidance would make the feature more useful. High signing rates, unfamiliar principals, repeated errors, and unexpected regional activity are practical candidates for alerts.

Security teams should also watch the boundaries of AgentCore Identity’s permission model. The ideal policy lets one workload use one signing key for one approved provider without granting unrelated signing access.

Cross-account keys add flexibility but require careful resource policies. AWS KMS supports cross-account use for signing when callers specify the key ARN and receive the required permissions.

That capability can support centralized security ownership. It can also create dependencies between application accounts and a central identity account. Outages or policy mistakes in the central account can affect many agents.

Enterprises should measure operational outcomes instead of assuming the cryptographic design guarantees success. Useful indicators include secret-rotation workload, token-request failures, unauthorized signing attempts, and recovery time after key changes.

They should also compare Private Key JWT with AWS IAM-signed JWT authentication. AgentCore Identity documentation describes an AWS_IAM_ID_TOKEN_JWT method that uses an IAM-issued assertion and requires the authorization server to trust AWS IAM.

The two approaches move away from shared client secrets, but they establish trust differently. Private Key JWT asks the identity provider to trust a customer-managed public key. The IAM method asks it to trust AWS IAM as an issuer.

Provider support will often decide which route is practical. Some identity systems already support Private Key JWT for confidential OAuth clients. Fewer may be configured to accept an AWS IAM issuer directly.

Private Key JWT therefore occupies a useful middle ground. It applies a standard OAuth authentication method while keeping the private signing material under KMS control.

The feature’s broader significance lies in how it treats an agent. Rather than giving the agent a reusable credential, the platform performs a narrowly authorized cryptographic operation when access is needed.

That pattern reduces the value of copied configuration data. It also creates an enforceable checkpoint for every token request. Those are concrete improvements for autonomous workloads that operate frequently and with limited supervision.

The tradeoff is increased configuration precision. Teams must align algorithms, public keys, JWT claims, IAM policies, OAuth grants, token scopes, and logging controls.

Amazon AWS has made that complexity more manageable by bringing signing into AgentCore Identity. It has not made the surrounding trust decisions disappear.

Before adopting the method broadly, choose one representative agent and trace its complete access path. Identify every principal, token, grant, scope, log source, and revocation mechanism involved.

Then test rotation and failure, not just successful authentication. If your team can explain who requested each signature and what happened afterward, Private Key JWT is doing more than replacing a secret.