公開：2026年10月21日, 最終更新：2026年10月21日
AWSとKeyfactorのエンジニアリングチームが共同で、AIエージェントのゼロトラスト認証基盤をX.509 PKIで構築する参照アーキテクチャを公式ブログで解説した。Amazon BedrockとEJBCA Enterprise、AWS Secrets Managerなどを組み合わせ、エージェント間の成りすましや資格情報の再生攻撃を防ぐ4つのセキュリティメカニズムを示している。
30秒サマリー
- MCP（Model Context Protocol）には認証標準が組み込まれておらず、エージェントへの成りすましや無認可のツール呼び出しが課題となっている
- 参照アーキテクチャは「署名付きリクエストエンベロープ」「委任アサーション」「RFCスコープトークン」「OCSPリアルタイム失効確認」の4機構を3層に組み合わせる設計
- ユーザーの秘密鍵はアプリケーション境界外に出ず、エージェントは委任アサーションを通じてユーザー資格情報を共有せずに認可を受ける
X.509 PKI×AWSによるAIエージェント認証の参照アーキテクチャの要点
AWSのMachine Learning公式ブログは、AIエージェントがデータベースやAPIなどのリソースにアクセスする際に必要な暗号ID基盤の実装方法を詳説した。背景として、Multi-agentフレームワークで広く使われるModel Context Protocol（MCP）には認証標準が存在せず、コンポーネントがエージェントを偽装したり、傍受した資格情報を再生したりするリスクがあることが指摘されている。
参照アーキテクチャはKeyfactor EJBCAとAWSサービスを組み合わせ、3つの信頼境界を管理する。第1層ではOAuth 2.0とX.509証明書を用いてユーザー認証と委任トークンの発行を行う。具体的には、Keycloakで取得したフルセッショントークンをRFC 8693トークン交換でMCPサーバー向けにダウンスコープし、エージェントにはこの制限付きトークンのみを渡す。ユーザーの秘密鍵はアプリケーション内でローカル生成され、EJBCA・エージェント・ファイルシステムには渡されない。
第2層のエージェント間通信では、オーケストレーターエージェントがツール名・引数・タイムスタンプ・ランダムなナンスをRSA-PSS-SHA256で署名した「署名付きエンベロープ」を生成する。受信エージェントは署名検証・タイムスタンプ鮮度（デフォルト60秒以内）・ナンス一意性・CAチェーン検証・ロール認可・OCSPリアルタイム失効確認の6項目をチェックする。ナンスは再利用不可のため、同一リクエストの再生攻撃は正規の送信者にも不可能な設計となっている。
第3層のMCPサーバー（FastMCP）では、全ツール呼び出しに対してトークンイントロスペクション・エンベロープ検証・委任アサーション検証・OCSPチェックを多層的に実施する。1つの資格情報が漏えいしても他のチェックが不正操作を阻止する多層防御（defense-in-depth）の設計思想に基づく。LLM推論にはAmazon BedrockをAWS Strands Agents SDK経由で使用し、全サンプルコードはGitHubリポジトリで公開されている。
X.509 PKIの主な仕様・数値
- LLM推論基盤：Amazon Bedrock（AWS Strands Agents SDK経由）
- PKIプラットフォーム：Keyfactor EJBCA Enterprise
- IDプロバイダー：Keycloak 26.2以降（RFC 8693準拠のトークン交換に必要）
- 鍵ペアのアルゴリズムと鍵長：RSA 2048ビット以上
- 署名アルゴリズム（エンベロープ）：RSA-PSS-SHA256
- エンベロープ有効期限（デフォルト）：60秒（ENVELOPE_MAX_AGE_SECONDS）
- 資格情報ストレージ：AWS Secrets Manager（PKCS12バンドル）
- Python要件：3.9以上
出典: AWS Machine Learning Blog（公式ブログ）
なぜ重要か（編集部の分析）
編集部の見方として、MCPを採用するマルチエージェントシステムが企業内に広がる中、認証標準の欠如は放置できないリスクとなっている。本アーキテクチャが示す「資格情報の共有ゼロ・短命証明書・リアルタイム失効」の原則は、API鍵やOAuthトークンの使い回しという従来手法と明確に一線を画す。エージェントの数が増えるほど証明書ライフサイクル管理の自動化が不可欠となり、PKIとクラウドサービスの統合設計がAIシステムの信頼性を左右する要因になりつつある。
日本企業への示唆（編集部の分析）
編集部の分析として、日本企業がAIエージェントを基幹業務APIや社内データベースに接続する場合、まず既存のID管理・PKI基盤がエージェント向けの短命証明書自動発行とOCSPに対応しているか確認することが出発点となる。EJBCA以外のCA製品でも同様のパターンは適用可能だが、REST APIによる証明書ライフサイクル自動化が前提条件となる。セキュリティ担当者はMCPサーバーへのアクセス権限設計（スコープ・ダウンスコープ）を開発初期段階から組み込み、「エージェントが誤動作・侵害された場合に影響範囲をどう最小化するか」を要件定義に含めることが重要となる。
背景・経緯
原文によれば、AIエージェントがデータベース・API・業務システムにアクセスするケースが増加する中、従来のAPIキー共有やOAuthトークンのエージェントチェーン流通はゼロトラスト要件を満たさないとされる。AWSとKeyfactorのエンジニアリングチームが共同でこの参照アーキテクチャを開発したとされており、Keyfactorは金融・医療・製造・政府機関を含む1,500社以上の企業顧客を持つと同社は述べている。
X.509 PKIについてよくある質問
Q. X.509 PKIを使ったAIエージェント認証でユーザーの秘密鍵はどこに保存されるか？
A. 原文によれば、ユーザーの秘密鍵はアプリケーション内でローカル生成され、EJBCAには送られず、エージェントとも共有されず、ファイルシステムにも保存されない。エージェントへはPKCS12形式でAWS Secrets Managerに格納されたエージェント固有の証明書・鍵ペアが渡される。
Q. このアーキテクチャでMCPサーバーはエージェントのリクエストをどのように検証するか？
A. 原文によれば、MCPサーバー（FastMCP）はKeycloakへのトークンイントロスペクション・署名付きエンベロープの検証・委任アサーションの確認・EJBCAへのOCSPリアルタイム失効チェックの4項目を全ツール呼び出しに対して実施する。
Q. X.509 PKIのエージェント認証基盤にKeycloak 26.2以降が必要な理由は何か？
A. 原文によれば、RFC 8693準拠の標準的なトークン交換に対応しているためで、それ以前のバージョンは非互換のレガシー交換方式を使用しているとされる。
