Amazon Bedrock AgentCore Identityが「Private Key JWT」に対応、AWS KMSを活用した安全なエージェント認証が可能に

要点

• Amazon Bedrock AgentCore Identityにおいて、エージェント向けの「Private Key JWT」クライアント認証が新たにサポートされた。

• 従来の共有シークレットを使う代わりに、AWS KMSで署名されたJWTアサーションを用いて認証を行う仕組みが導入された。

• 認証に使用される秘密鍵はAWS KMS内に安全に保護され、外部に公開されることなく署名処理が実行される。

• マシントゥマシン（M2M）など、複数のグラントフローにおいてこの新しい認証方式が利用可能である。

• アマゾン ウェブ サービス（AWS）は2026年7月29日、同社の機械学習公式ブログにおいて、「Amazon Bedrock AgentCore Identity」がエージェント向けのPrivate Key JWT（非対称鍵とトークンを用いた認証方式）クライアント認証に対応したと発表した。これにより、エージェントは共有のOAuth 2.0クライアントシークレット（IDと対になるパスワードのような情報）を使用することなく、下流のアイデンティティプロバイダー（認証情報を管理するシステム）に対して署名済みのJSON Web Token（JWT：デジタル署名されたデータフォーマット）を用いて安全に認証を行えるようになるという。

秘密鍵を外部に出さない安全な認証の仕組み

従来の認証方式では、外部のAPIやサービスと連携する際に共有のクライアントシークレットを利用することが一般的であり、その漏洩対策や鍵の管理が課題となっていた。今回サポートされたPrivate Key JWTクライアント認証では、開発者は公開鍵のみをアイデンティティプロバイダーに登録し、それに対応する秘密鍵を「AWS Key Management Service（AWS KMS：暗号鍵の作成や管理を行うサービス）」内に安全に保持する。

実際の認証処理においては、Bedrockエージェントのアイデンティティ管理を担う「AgentCore Identity」がAWS KMSを利用してJWTクライアントアサーション（身元を証明するための署名入りデータ）に署名を行う。署名されたアサーションはアイデンティティプロバイダーへ送信され、プロバイダー側で事前に登録された公開鍵を用いて検証される。この一連のプロセスにおいて、秘密鍵がAWS KMSの外部に公開されたり送信されたりすることは一切ないため、認証情報の安全性が大きく向上するとしている。

顧客注文履歴の取得を例とする動作フロー

元記事では、顧客サポートエージェントが、アイデンティティプロバイダーで保護された社内の注文管理APIから顧客の注文履歴を取得するケースを例に挙げ、認証の動作フローを説明している。

まず、エージェントはAgentCore Identityの GetResourceOauth2Token を呼び出し、注文APIにアクセスするためのトークンを要求する。これを受けたAgentCore Identityは、設定された資格情報プロバイダーからクライアントID、KMSキーのARN（Amazonリソースネーム：AWS内のリソースを一意に識別する文字列）、および署名アルゴリズムを読み取る。そして、一時的なJWTクライアントアサーション（キー識別子や証明書のサムプリント〈証明書を一意に特定するためのハッシュ値〉などの情報を含む）を構築し、設定されたアルゴリズム（RS256、PS256、またはES256）でKMSの非対称署名キーに対して kms:Sign を呼び出す。

AWS KMSはアサーションに署名を施し、そのデータをAgentCore Identityに返却するが、この際も秘密鍵がKMSから外に出ることはない。その後、AgentCore Identityは署名済みアサーションを、特定のパラメータ（grant_type=client_credentials およびクライアントアサーションタイプ）を指定してアイデンティティプロバイダーのトークンエンドポイントに送信する。

最後に、アイデンティティプロバイダーは登録済みの公開鍵で署名を検証し、アクセストークンを返却する。これを受け取ったAgentCore Identityがエージェントにトークンを引き渡し、エージェントはそのトークンを使用して注文APIから顧客履歴を取得する。

サポートされるグラントフロー

Private Key JWT認証は、複数のグラントフロー（認可手順）で利用できるという。

一つ目は「マシントゥマシン（M2M）」フローである。これは人間のユーザーが介在せず、エージェント自身のアカウントや権限として動作する場合に使用される。例えば、データの同期を行うバックグラウンド処理や、どのオペレーターが利用しているかに関わらずすべての顧客サポートエージェントがアクセス可能なサービスなどのケースが該当する。このフローでは client_credentials グラントが使用され、発行されるトークンのサブジェクト（主体）はクライアント自身となる。

二つ目は「オンベハーフオブ（OBO）」フローである。これはエージェントが特定のユーザーの代理として動作するもので、そのユーザーの既存の資格情報を活用して処理を実行する。

補足

Private Key JWTクライアント認証のサポートにより、エージェントと外部APIとの安全な連携が容易になり、特に企業内の機密データを扱うシステムにおいて、より堅牢なセキュリティ設計が可能になるとみられる。