Amazon AWS、AgentCore IdentityにPrivate Key JWTを追加、共有シークレットをKMS制御に置き換え

Amazon AWSはAgentCore IdentityにPrivate Key JWT認証を追加し、自動化エージェントに長期存続するOAuthクライアントシークレットに代わる新たな選択肢を提供した。この変更により、クライアント認証はAWS Key Management Serviceに支えられた短命の署名付きアサーションへと移行する。また、各署名リクエストについてAWS CloudTrailにより明確な記録が残るようになる。

この組み合わせが重要なのは、自律型エージェントでは一般的な従業員向けアプリケーションよりもはるかに頻繁にトークンを要求し得るためだ。流出したクライアントシークレットは、誰かがローテーションまたは失効させるまで有効なままであり得る。一方、Private Key JWTアサーションは短時間で期限切れとなり、新しいリクエストごとに保護された署名鍵へのアクセスを必要とする。

中心的な論点は、単に鍵とパスワードの比較ではない。Amazon Bedrock AgentCore Identityは、開発者に独自の署名サービスの構築・運用を強いることなく、より強力な制御を実現するとしている。その約束が実現するかは、アイデンティティプロバイダーとの互換性、正確なクレーム設定、KMS権限、完全な監査範囲に左右される。

Amazon AWS、OAuthクライアント認証をKMSに移行

重要な変更点は、AgentCore Identityが再利用可能なクライアントシークレットを保存せずにOAuthクライアントを認証できるようになったことだ。

Private Key JWTの発表で説明されている新しいパターンでは、AgentCore IdentityがJSON Web Tokenを構築し、AWS KMSを通じて署名する。アイデンティティプロバイダーは、対応する公開鍵を用いてその署名を検証する。

秘密鍵はKMS内に保持される。エージェント、アプリケーションプロセス、管理者が鍵を設定ファイル、コンテナイメージ、環境変数、または別のシークレットストアにエクスポートする必要はない。

署名済みJWTはクライアントアサーションであり、認可サーバーに対してOAuthクライアントのアイデンティティを証明するものだ。最終的にAPIへ提示されるアクセストークンそのものではない。認可サーバーは、そのアクセストークンを発行する前にアサーションを検証する。

この区別は見落とされやすい。OAuthクライアント認証は、トークンを要求するアプリケーションが登録済みクライアントかどうかに答える。OAuthグラントは、結果として得られるトークンが誰の権限を表し、どの権限を受け取るかを決定する。

したがって、Private Key JWTは複数のグラントフローで機能し得る。AgentCore Identityは、認可コードグラントによるユーザー委任アクセスと、クライアントクレデンシャルによるマシン間アクセスをサポートする。より広範な認証パターンには、代理トークン交換の構成も含まれる。

ユーザー委任リクエストでは、まずユーザーがアイデンティティプロバイダーを通じてアクセスを認可する。その後、AgentCore Identityは、認可コードをトークンと交換する際にOAuthクライアントを認証する。ユーザーの承認とクライアントのアイデンティティは、別個の制御として維持される。

マシン間リクエストでは、ユーザーが対話的な同意画面を完了することはない。エージェントは、アプリケーション自身の権限の下でアクセストークンを要求する。Private Key JWTは、クライアントクレデンシャル交換の際にそのアプリケーションを認証する。

このため、この機能はログイン用途にとどまらない。エージェントから企業API、ソフトウェアサービス、その他の保護されたリソースへのアウトバウンドアクセスを対象としている。こうした接続こそ、静的な認証情報が運用上の負債となり得る領域だ。

AgentCore Identityはすでに、エージェント、認可サーバー、リソースサーバーの間の仲介役として機能している。長期的なシークレットやリフレッシュトークンをエージェントコードから遠ざけたまま、認証情報を取得する。Private Key JWTは、その境界をOAuthクライアントの認証マテリアルにも拡張する。

リクエスト経路には現在、いくつかの明示的な段階がある。エージェントはAgentCore Identityに認可済みアクセスを要求する。AgentCore Identityは期限付きアサーションを作成し、KMSを呼び出して署名し、それをアイデンティティプロバイダーのトークンエンドポイントに送信する。

アイデンティティプロバイダーは、登録済み公開鍵に対して署名を確認する。また、クライアント、オーディエンス、発行時刻、有効期限を特定するクレームも評価する。これらの検証に通れば、プロバイダーはAgentCore Identityを介してアクセストークンを返す。

この設計は信頼を排除するものではない。信頼をKMSポリシー、IAMロール、OAuth設定、アイデンティティプロバイダーの公開鍵登録へと移すものだ。これらの制御は、コピーされた1つの文字列よりもきめ細かいが、不一致が認証を停止させ得る箇所も増える。

Private Key JWTがシークレットモデルをどう変えるか

Private Key JWTは共有シークレットへの依存を減らすが、そのセキュリティはKMSに署名を要求できる主体を制御できるかどうかに依存する。

従来のOAuthクライアント認証では、一般にclient_secret_basicまたはclient_secret_postが用いられる。いずれの方法も、クライアントIDと共有シークレットを認可サーバーに送信する。違いは、それらの認証情報がHTTP Basicヘッダーに含まれるか、リクエスト本文に含まれるかだ。

AWSのドキュメントでは、カスタムAgentCore Identityプロバイダーにおけるデフォルト方式としてHTTP Basicが説明されている。シークレットは、ローテーション、期限切れ、または失効するまで再利用可能なままだ。コピーを保持するすべてのシステムが、その認証情報のセキュリティ境界の一部となる。

Private Key JWTは、この対称モデルを非対称鍵ペアに置き換える。一方の当事者が秘密署名鍵を管理し、アイデンティティプロバイダーは公開検証鍵のみを保存する。公開鍵が露出しても、攻撃者が有効なアサーションを生成できるようにはならない。

このアプローチは、クライアント認証および認可グラント向けのJWTを定義するOAuth JWT profileに従う。トークンリクエストにはクライアントアサーションが含まれ、それがJWT bearer assertionであることを示す。

一般的なアサーションには、クライアントを特定する発行者クレーム、そのクライアントに対するサブジェクトクレーム、トークンエンドポイントを示すオーディエンスクレームが含まれる。また、有効期限と発行時刻も含まれる。一意のJWT識別子は、アイデンティティプロバイダーがリプレイ攻撃を検出する助けとなり得る。

これらのフィールドは装飾的なメタデータではない。誤ったオーディエンスが指定されると、正しく署名されたJWTでも無効になる可能性がある。時刻のずれにより、プロバイダーがアサーションを時期尚早または期限切れとして拒否することもある。

また、Private Key JWTが自動的にリプレイ防止を保証するわけでもない。RFC 7523では、リプレイ対策の一部をデプロイメントポリシーに委ねている。アイデンティティプロバイダーには、適切な有効期間の制限と、サポートされる場合には一意のアサーション追跡が必要となる。

短い有効期限は、取得されたアサーションが悪用できる期間を狭める。しかし、攻撃者が署名鍵を繰り返し呼び出す権限を持つシステムは保護できない。だからこそ、KMSキーポリシーとIAM権限が中核となる強制レイヤーになる。

AWS KMSは、非対称鍵を関連付けられた公開鍵と秘密鍵のペアとして扱う。署名鍵では、秘密コンポーネントはサービス内で保護されたままとなる。公開コンポーネントはダウンロードし、外部アイデンティティプロバイダーに登録できる。

KMSは、署名と検証に使用するRSAおよび楕円曲線鍵を含む複数の非対称鍵タイプをサポートしている。選択する鍵タイプとアルゴリズムは、アイデンティティプロバイダーが受け入れるものと一致していなければならない。

AgentCore Identityには、設定された鍵を署名に使用する権限が必要だ。AWSによれば、KMS Sign操作の呼び出し元には、キーポリシーによるkms:Sign認可が必要となる。その後、サービスは秘密コンポーネントを返すことなくそれを使用する。

これは意味のある封じ込めの改善だ。キーARNを露出する設定漏えいがあっても、秘密鍵マテリアルそのものは明らかにならない。攻撃者はなお、鍵を呼び出すためのAWS認証情報と有効な認可を必要とする。

ただし、署名権限は依然として機微なものだ。広範なkms:Signアクセスを持つロールは、意図したワークロード経路の外で署名を要求できる可能性がある。チームは権限を適切なAgentCore実行ロールに結び付け、汎用的なワイルドカードアクセスを避けるべきだ。

この変更はローテーションにも影響する。共有シークレットでは、両者が同じ機密値を置き換えなければならない。非対称認証では、チームは制御された移行中に古い検証鍵を維持したまま、アイデンティティプロバイダーに新しい公開鍵を導入できる。

アイデンティティプロバイダーが複数のアクティブな鍵をサポートしていれば、この重複によってダウンタイムを削減できる。公開鍵を1つしか受け入れない場合、ローテーションには依然として協調したタイミングが求められる。Private Key JWTはローテーション対象のマテリアルを変えるのであって、検証済みのローテーションプロセスの必要性をなくすものではない。

サポートされるグラントフローは異なるエージェントアイデンティティに対応する

Private Key JWTはOAuthクライアントを認証する一方、選択するグラントによって、エージェントが自らのために動作するのか、ユーザーのために動作するのかが決まる。

認可コードグラントは、ユーザーに代わってリソースへアクセスするエージェントに適している。ユーザーはアイデンティティプロバイダーを通じてサインインし、要求された権限を承認する。認可サーバーは、クライアントがトークンと交換するコードを返す。

この交換中、AgentCore IdentityはPrivate Key JWTアサーションを用いて、登録済みクライアントがリクエストを行っていることを証明する。このアサーションはユーザー同意に代わるものではない。トークンエンドポイントでの認証を強化するものだ。

このフローは、ユーザーのカレンダーを読み取るエージェント、従業員に認可されたレコードを検索するエージェント、あるいは委任された権限内で顧客管理システムを更新するエージェントに適している。得られるアクセスは、ユーザーと承認済みスコープに紐付いたままである。

クライアントクレデンシャルグラントは、別のケースに対応する。ここでは、ワークロードは対話するユーザーなしに、自身として動作する。スケジュールされたエージェントは、内部在庫APIの呼び出し、サービスアラートの処理、承認済み運用データの取得などを行う場合がある。

Private Key JWTは、認可サーバーがアプリケーショントークンを発行する前に、そのマシンクライアントを認証する。ユーザーが存在しないため、クライアントアイデンティティ、トークンスコープ、下流の認可ポリシーが、より大きなセキュリティ上の役割を担う。

組織は、この2つのグラントを相互に置き換え可能なデプロイメントオプションとして扱うべきではない。ユーザーアイデンティティを保持すべきタスクにクライアントクレデンシャルを使用すると、説明責任が不明確になる可能性がある。バックグラウンドサービスの作業に委任フローを使用すると、個人アカウントへの脆弱な依存が生じかねない。

代理アクセスは、さらに別の変形をもたらす。エージェントは既存のユーザーアイデンティティの証拠を受け取り、それを別のリソースに適したトークンと交換する。このフローでは、ユーザー、エージェント、宛先サービスの関係を保持しなければならない。

AgentCore Identityのドキュメントでは、このようなケースに対して標準的なトークン交換とJWTベースの認可グラントの両方が説明されている。サポートは依然として、外部認可サーバーとそのトークン交換ルールに依存する。

Private Key JWTは、その交換に参加するクライアントを認証できる。受信したユーザートークンが有効かどうか、あるいは要求された委任を許可すべきかどうかを決めるものではない。それらの判断は、関連するアイデンティティおよび認可システムに委ねられる。

この分離は、この機能における最も強力なアーキテクチャ上のポイントの一つだ。チームは、エージェントに必要な権限に基づいてグラントを選び、クライアントが自身のアイデンティティを証明する方法に基づいてPrivate Key JWTを選べる。

また、単一の「エージェント認証情報」という捉え方が危険である理由も浮き彫りにする。エージェントはワークロードアイデンティティを持ち、ユーザーのために動作し、複数のリソースサーバーを呼び出し、宛先ごとに異なるトークンを使用する場合がある。

AgentCore Identityのワークロードアクセストークンは、さらにもう一層を加える。AWSによれば、エージェントがvaultに認証情報を要求する際、このトークンにはエージェントのIDとエンドユーザーのIDを含められる。AgentCore Runtimeは、ホストされたエージェントにこれを自動提供できる。

このワークロードトークンはAgentCore Identityへのアクセスを認可する。外部OAuthアクセストークンは宛先APIへのアクセスを認可する。Private Key JWTアサーションは、トークン発行時にOAuthクライアントを認証する。

したがって、エンドツーエンドの1つのトランザクションに、役割の異なる3種類のトークンが現れる可能性がある。これらを混同すると、誤った検証、過剰なログ記録、あるいは意図しない露出につながり得る。

セキュリティレビューでは、各トークンについて発行者、対象者、保持者、有効期間、送信先を対応付けるべきだ。また、どのコンポーネントが更新または置き換え可能かも特定する必要がある。この作業により、製品レベルの図では隠れやすい設計上の誤りを発見できる。

より広い競争圧力は、シークレットベースのエージェント統合に及ぶ。静的なクライアントシークレットは使い慣れた広く対応された方式だが、多数の自律的ワークロードが個別の権限と監査証跡を必要とする場合には、スケールしにくい。

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はプロバイダーのメタデータから認可エンドポイントとトークンエンドポイントを見つけられる。チームは、検出されたトークンエンドポイントがアイデンティティプロバイダーの期待するaudience値と一致することを確認すべきだ。

AgentCore Identityには、KMSを呼び出す権限も必要となる。KMSの署名操作には、SIGN_VERIFY用途のキーと、そのキーに対応するアルゴリズムが必要である。

KMSは、選択されたメッセージタイプに応じて、生のメッセージまたは事前計算済みのダイジェストを受け入れる。外部検証はアルゴリズムで規定されたハッシュ動作を前提とするため、JWT実装では意図しない二重ハッシュを避けなければならない。

JWTヘッダーの設定も重要だ。アイデンティティプロバイダーは、適切な公開鍵を選択するためにキー識別子を使用できる。複数の公開鍵が有効になり得るローテーション時には、識別子の欠落や誤りが特に問題になる。

ペイロードのクレームにも同等の注意が必要である。発行者とサブジェクトは、通常OAuthクライアントIDに対応する。audienceは一般に認可サーバーのトークンエンドポイントを示すが、正確な値はプロバイダー要件に従うべきだ。

有効期限は短く保つ必要がある。発行時刻は同期された時計を反映しなければならない。プロバイダーが過去に受け入れたアサーションを記録する場合、固有のトークン識別子には価値がある。

認証情報プロバイダーを保存した後、チームは想定する各グラントを個別にテストすべきだ。クライアントクレデンシャルリクエストが成功しても、認可コード交換やトークン交換が正しく構成されているとは証明されない。

テストは最小限のスコープから始めるべきだ。認証は成功しても認可に失敗した場合、その違いを診断しやすくなる。エラーを回避するために広範な権限を追加すると、audienceやクライアント登録の問題を隠してしまう可能性がある。

チームはネガティブパスもテストすべきだ。誤ったキーで署名されたリクエストは失敗しなければならない。期限切れのアサーションも失敗しなければならない。不正なaudienceと未認可のKMS呼び出し元は、それぞれ識別可能な証跡を残す必要がある。

ここで、運用上のトレードオフが明らかになる。共有シークレットは単純であるため、チームはしばしば正常系だけを検証する。Private Key JWTはより強い境界を提供するが、その境界には明示的なテストが必要である。

この構成は、管理チーム間の依存関係も生む。クラウドセキュリティチームがKMSとIAMポリシーを所有する場合がある。アイデンティティチームはOAuthクライアントと公開鍵登録を管理する場合がある。

アプリケーション所有者はAgentCore Identityを構成し、グラントスコープを決定する。監査チームは、保持およびアラートの対象となるCloudTrailレコードを決める。単一のコンソール選択だけでは、これらの責任分担に関する問題を解決できない。

有用なロールアウトは、重要度の低い統合1件から始める。チームは、この方式を多数のエージェントに適用する前に、クレーム要件、失敗時の応答、ローテーション手順、エスカレーションの責任者を文書化できる。

自動化は、その最初の検証済みデプロイメントに続けるべきだ。インフラストラクチャテンプレートはキーポリシーと認証情報プロバイダー設定を標準化できるが、アイデンティティプロバイダーの挙動を推測すべきではない。

その結果は、シークレットのないシステムではない。トークンは依然として存在し、認可サーバーは引き続きトラストを保持し、AWS権限も認証情報である。より限定的な主張の方が妥当だ。OAuthクライアントは、共有され再利用可能なシークレットに依存しなくなる。

CloudTrailはすべての署名を監査シグナルに変える

KMSを基盤とする署名により、防御側はトークンリクエストやエージェント活動と相関付けられるAWS側のイベントを得られる。

AWS KMSはCloudTrailと統合されており、ユーザー、ロール、AWSサービスによる呼び出しを記録する。KMS監査ログには、キー管理アクションに加えて暗号操作も含まれる。

したがって、Private Key JWTトランザクションでは、KMS署名リクエストに関する証跡が生成されるはずだ。このイベントは、操作、リージョン、時刻、関連キー、関与したAWSプリンシパルまたはサービスコンテキストを識別できる。

ただし、そのレコードだけで全体像が分かるわけではない。CloudTrailが示すのは、認可されたAWS IDが署名を要求したという事実だ。外部アイデンティティプロバイダーのログは、そのアサーションを受け入れてトークンを発行したかどうかを示す。

宛先サービスの監査ログは、結果として得られたアクセストークンが何を行ったかを示す。効果的な調査では、KMSイベントをリソースアクセス成功の証拠として扱うのではなく、3つのレイヤーすべてを相関付ける。

CloudTrailはそれでも重要な問いに答えられる。調査担当者は、想定外の署名量、誤ったロールからのリクエスト、未承認リージョンでの呼び出し、通常のスケジュール外のキーに関わる活動を探せる。

構成されたイベントセレクターも重要である。AWSはKMSイベントを管理イベントに分類しており、CloudTrailの証跡は通常、管理アクティビティを記録する。ただし、管理者はKMSイベントを明示的に除外できる。

AWSは、KMS操作が大量のイベントを生成する可能性があると警告している。ログ量を抑えるために、これらをフィルタリングする組織もある。そうすると、この認証パターンの監査を容易にする署名証跡そのものが失われる可能性がある。

Private Key JWTを採用するチームは、管理イベント設定を見直すべきだ。関連するKMSアクティビティが、意図した証跡またはイベントデータストアに届いていることを確認する必要がある。

保持と検索可能性も重要である。イベント履歴は直近の調査に役立つ一方、証跡またはCloudTrail Lakeイベントデータストアはより長期的な分析を支える。エクスポートされたレコードは、セキュリティ監視システムにも取り込める。

ベースラインでは、想定されるトークンリフレッシュの挙動と異常を区別すべきだ。継続的に稼働するマシンエージェントは、一定の間隔でアサーションに署名する可能性がある。ユーザー委任型のワークフローでは、アクティブセッション中に活動が集中する場合がある。

大きな逸脱は、リトライループ、構成障害、または認証情報の不正利用を示す可能性がある。署名が繰り返された後にトークンエンドポイントで拒否される場合、誤ったaudience、期限切れの公開鍵、または時刻の問題を示唆し得る。

対応するAgentCoreリクエストを伴わない署名活動は、より詳細な調査に値する。想定されるダウンストリーム呼び出しを伴わないトークン発行成功も同様である。各パターンは、トラストチェーンの異なる箇所における断絶を示す。

キーのライフサイクルイベントには、別途アラートを設定すべきだ。署名キーを無効化すると、それに依存するすべての統合が停止し得る。ポリシー変更は、呼び出しを許可される対象を気付かないうちに拡大する可能性がある。

CloudTrailはローテーション時にも役立つ。新しいキーが有効になった後も古いキーが署名リクエストを受け続けているかを、チームは確認できる。継続する活動は、見落とされた認証情報プロバイダーや遅延したデプロイメントを明らかにする可能性がある。

ただし、監査の可視性には条件がある。ログは有効化、保持、保護、レビューされなければならない。記録されても一度も照会されないイベントは、実務上ほとんど防御にならない。

CloudTrailイベントは、リクエストの業務上の理由までは検証しない。適切に認可されたエージェントでも、不適切なタイミングでアクセストークンを要求したり、過度に広いタスクに使用したりする可能性がある。

この制約により、注目は認可設計へと移る。Private Key JWTは、クライアントが署名キーへのアクセスを制御していることを証明できる。一方で、エージェントの目的、選択されたツール、要求された操作が適切かどうかは判断できない。

組織には、暗号学的証明を補うスコープ制限、リソースサーバーポリシー、ワークロード制御、行動監視が必要である。署名は高品質なシグナルの1つであり、完全なエージェントガバナンスシステムではない。

Private Key JWTの開始後、企業が注視すべき点

次の試金石は、Private Key JWTが運用上の標準となるのか、それとも厳格に管理されたデプロイメント向けの高度な選択肢にとどまるのかである。

最初のシグナルは、アイデンティティプロバイダーとの相互運用性だ。採用を成功させるには、プロバイダーが選択された署名アルゴリズム、クレーム、audience形式、公開鍵登録方式を受け入れる必要がある。

AWSは交換処理の自社側を簡素化できるが、すべてのプロバイダーの管理ワークフローを標準化することはできない。明確でプロバイダー固有の例があれば、デプロイメント失敗や安全でない回避策を減らせるだろう。

2つ目のシグナルは、ローテーション時の挙動である。企業は、重複する公開鍵を登録できるか、停止なくAgentCoreプロバイダーを更新できるか、監査レコードを通じて移行を確認できるかを知る必要がある。

初期設定時にしか機能しない機能は、問題の半分しか解決しない。本番の認証には、キーが無効化、置き換え、または侵害された場合に予測可能な復旧も必要である。

3つ目のシグナルは、監査の採用である。CloudTrailによりチームは署名レコードへアクセスできるが、組織はKMSイベントを保持し、アイデンティティプロバイダーおよびリソースサーバーのログと接続しなければならない。

検知ガイダンスがあれば、この機能はさらに有用になる。高い署名頻度、未知のプリンシパル、繰り返されるエラー、想定外のリージョン活動は、アラートの実用的な候補である。

セキュリティチームは、AgentCore Identityの権限モデルの境界も監視すべきだ。理想的なポリシーでは、無関係な署名アクセスを与えることなく、1つのワークロードが承認済みの1つのプロバイダーに対して1つの署名キーを使用できる。

クロスアカウントキーは柔軟性を高めるが、慎重なリソースポリシーが必要となる。AWS KMSは、呼び出し元がキーARNを指定し、必要な権限を得る場合、署名用途でのクロスアカウント利用をサポートしている。

この機能は、セキュリティの所有権を一元化することを支援できる。一方で、アプリケーションアカウントと中央のアイデンティティアカウントの間に依存関係を生む可能性もある。中央アカウントでの障害やポリシー設定の誤りは、多くのエージェントに影響を及ぼし得る。

企業は、暗号設計が成功を保証すると前提するのではなく、運用上の成果を測定すべきだ。有用な指標には、シークレットローテーションの作業負荷、トークンリクエストの失敗、不正な署名試行、鍵変更後の復旧時間が含まれる。

また、Private Key JWT と AWS IAM署名JWT認証を比較する必要もある。AgentCore Identityのドキュメントでは、IAMが発行したアサーションを使用し、認可サーバーがAWS IAMを信頼する必要がある AWS_IAM_ID_TOKEN_JWT メソッドが説明されている。

どちらのアプローチも共有クライアントシークレットから離れるものだが、信頼の確立方法は異なる。Private Key JWTでは、アイデンティティプロバイダーに顧客管理の公開鍵を信頼させる。IAM方式では、発行者としてAWS IAMを信頼させる。

どの方法が実用的かは、多くの場合プロバイダーのサポート状況によって決まる。一部のアイデンティティシステムは、機密OAuthクライアント向けにすでにPrivate Key JWTをサポートしている。AWS IAMの発行者を直接受け入れるよう構成されているシステムは、より少ない可能性がある。

したがって、Private Key JWTは有用な中間的選択肢となる。標準のOAuth認証方式を適用しつつ、秘密の署名マテリアルをKMSの管理下に置ける。

この機能のより広い意義は、エージェントをどのように扱うかにある。エージェントに再利用可能な認証情報を与えるのではなく、アクセスが必要になった時点で、プラットフォームが限定的に認可された暗号操作を実行する。

このパターンは、コピーされた構成データの価値を低下させる。また、すべてのトークンリクエストに対して強制可能なチェックポイントを設ける。頻繁に稼働し、監督が限定的な自律ワークロードにとって、これらは具体的な改善点だ。

その代償として、設定にはより高い精度が求められる。チームは、アルゴリズム、公開鍵、JWTクレーム、IAMポリシー、OAuthグラント、トークンスコープ、ロギング制御を整合させなければならない。

Amazon AWSは、署名機能をAgentCore Identityに取り込むことで、この複雑さをより管理しやすくした。ただし、周辺の信頼に関する判断まで不要にしたわけではない。

この方式を広く採用する前に、代表的なエージェントを1つ選び、その完全なアクセス経路を追跡しよう。関与するすべてのプリンシパル、トークン、グラント、スコープ、ログソース、失効メカニズムを特定する。

そして、認証成功だけでなく、ローテーションと障害もテストする。チームが各署名を誰がリクエストし、その後に何が起きたかを説明できるなら、Private Key JWTは単なるシークレットの置き換え以上の役割を果たしている。