AWSとKeyfactor、AIエージェントの身元をX.509証明書で担保する構成を公開

公開された参照構成

AWSはブログで、Keyfactorと共同開発したAIエージェント向けの認証参照アーキテクチャを公開した。X.509公開鍵基盤（PKI）を使い、エージェントが誰のために、どの権限でツールを呼び出したのかを暗号学的に証明する。LLMの推論にはAmazon Bedrockを、AWS Strands Agents SDKを通じて利用する。保護対象の例としてデータベースを挙げているが、同じ認証パターンはMCP互換のツールサーバー全般に適用できるとしている。

背景にあるのはMCPの認証機能の不在である。MCPはLLMを組み込んだエージェントがデータベース照会やメール操作といったツールを呼び出す方法を定めるが、認証の標準仕様を持たず、トランスポートに依存しない設計になっている。そのため適切な身元確認がなければ、任意のコンポーネントがエージェントになりすましたり、傍受した資格情報を再利用したり、権限なくツールを呼び出したりできてしまう。原文はこの状態を「重大なギャップ」と表現している。

4つの仕組みと3層

構成は4つのセキュリティ機構を組み合わせる。1つ目は、エージェントの呼び出しごとにリクエスト全体へ署名する「署名付きエンベロープ」で、秘密鍵の保持を証明する（proof-of-possession）。2つ目は、ユーザーの秘密鍵で署名した「委譲アサーション」で、資格情報を共有せずにエージェントへ権限を委ねる。3つ目はRFC 8693のオーディエンス限定トークンで、1つのトークンが漏れた場合の影響範囲を限定する。4つ目はOCSPによるリアルタイムの失効確認で、資格情報の変更を全エージェントへ即座に反映する。

これらを3つの認証レイヤーに割り当てる。ユーザーログインと証明書発行・委譲の層、エージェント間通信の層、MCPサーバーの層である。エージェント間では、オーケストレーターがツール名・引数・タイムスタンプ・ランダムなnonceを含むペイロードにRSA-PSS-SHA256で署名し、受け手が署名、鮮度（既定60秒）、nonceの重複、CAチェーン、ロール、OCSPの6項目を検証する。同じプロンプトを再送する場合も新しいnonceが必要で、過去のエンベロープは正規の送信者でも再利用できない。

MCPサーバー側ではさらに4項目を確認する。Keycloakのトークンイントロスペクションでトークンが有効かつオーディエンスにMCPサーバーを含むこと、署名エンベロープの検証、ユーザーの委譲アサーションの検証、そしてトークンのユーザー名・委譲の主体・エージェント証明書のCNが一致するかの突合である。多層防御により、1つの資格情報が不正アクセスを受けても残りの検査で不正操作を防ぐ設計としている。

従来手法との違い

原文は、コンポーネント間でAPIキーを共有する方法や、エージェントの連鎖に沿ってOAuthトークンをそのまま渡す方法では、企業導入が求めるゼロトラスト要件を満たせないと指摘する。これに対し本構成では、ユーザーの秘密鍵とフルセッションのOAuthトークンをエージェントに渡さない。アプリケーションがローカルでRSA 2048ビット以上の鍵ペアを生成し、CSRをEJBCAのpkcs10enroll APIへ送って証明書を受け取り、証明書と秘密鍵をPKCS12形式でAWS Secrets Managerに保存する。秘密鍵はアプリケーションの境界の外に出ない。

EJBCAはKeyfactorの認証局／PKIプラットフォームで、高可用性構成やREST API自動化、OCSP検証を特徴とする。オンプレミス、コンテナ、Amazon EC2のいずれでも展開できる。Keyfactorは自社プラットフォームが世界1,500社以上の企業顧客に使われていると説明しており、金融、医療、製造、政府機関が含まれるとしている。AWS側がBedrockやSecrets Manager、Amazon RDSといったマネージドサービスを担い、Keyfactor側が証明書の発行・更新・失効を担う身元レイヤーを受け持つ関係にある。

前提条件と未公表の点

試すには前提条件がある。Amazon Bedrock、Amazon RDS for MySQL、Amazon SES、AWS Secrets ManagerへアクセスできるAWSアカウントに加え、RFC 8693の標準トークン交換に対応したKeycloak 26.2以降が必要で、それ以前のバージョンは互換性のないレガシー交換を使うため利用できない。Keyfactor EJBCA EnterpriseとREST API V1、OCSPレスポンダ、API管理者証明書（api-admin.p12）、Python 3.9以降の環境も求められる。X.509証明書、OCSP、OAuth 2.0、RSA署名、PKCS#12に関する知識も前提にされている。

一方、EJBCA Enterpriseの価格やライセンス条件は原文に記載がない。2026年10月20日付のブログ時点では参照アーキテクチャとサンプルコードの公開であり、製品としての提供形態や運用時の負荷、大規模環境での性能は示されていない。なお、原文のステップ3のコード例は4番目の検査の手前で途切れており、ID突合の実装コード全文は確認できない。