AWS Machine Learning出典公開日2026-10-21 00:03 UTC+8

AWS上のX.509 PKIによるAIエージェントアイデンティティの保護

AIエージェントがデータベース、API、および機密性の高いビジネスオペレーションにアクセスする場合、X.509公開鍵基盤(PKI)による暗号技術的なアイデンティティの確立が重要な要件となります。中心的な課題は、どのエージェントがリクエストを行ったのかを証明すること、エージェント間の偽造を防ぐこと、そして各エージェントが許可されたユーザーの代理としてのみ行動していることを確認することです。コンポーネント間でAPIキーを共有したり、エージェントチェーンを通じてOAuthトークンを受け渡したりするといった従来のアプローチでは、エンタープライズ展開が求めるゼロトラストの要件を満たせません。

マルチエージェントAIフレームワークでは、エージェントを外部ツールやデータソースに接続するために、Model Context Protocol(MCP)の使用がますます増えています。MCPは、大規模言語モデル(LLM)を基盤とするエージェントがデータベースクエリやメール操作などのツールを呼び出す方法を定義します。しかし、MCPには組み込みの認証標準がなく、設計上トランスポートに依存しません。これにより重大なギャップが生じます。適切なアイデンティティ機構がなければ、どのコンポーネントでもエージェントになりすましたり、傍受した認証情報をリプレイしたり、許可なくツールを呼び出したりすることが可能です。

この記事では、Keyfactor EJBCAをAWSサービスと組み合わせて、このギャップに対処する方法を紹介します。EJBCAは、高可用性デプロイ、REST API自動化、Online Certificate Status Protocol(OCSP)検証をサポートするPKIプラットフォームです。このリファレンスアーキテクチャでは、4つの相互補完的なセキュリティ機構を使用します。第一に、署名付きリクエストエンベロープがすべてのエージェント呼び出しにおいて暗号技術的な所有証明を提供します。第二に、ユーザー署名付き委任アサーションが、認証情報を共有することなくエージェントを許可します。第三に、RFC 8693のオーディエンススコープトークンが、単一のトークン漏洩による露出範囲を制限します。第四に、リアルタイムのOCSP失効確認が、認証情報の変更をすべてのエージェントに即座に伝播させます。

このソリューションは、LLM推論に Amazon Bedrock を、 AWS Strands Agents SDKを通じて使用します。このリファレンスアーキテクチャでは保護対象のリソースとしてデータベースを使用していますが、同じ認証パターンはMCP互換の任意のツールサーバーに適用できます。すべての例の完全なソースコードは、付属のGitHubリポジトリで入手できます。

Keyfactor EJBCAについて

Keyfactorは、Keyfactorによると、世界中で1,500社を超えるエンタープライズ顧客に利用されている、広く採用されたマシンアイデンティティ管理プラットフォームを提供しています。これらの組織は、金融サービス、ヘルスケア、製造業、政府機関に及びます。Keyfactorは、証明書ライフサイクル管理、PKI運用、マシンアイデンティティガバナンスを通じて、組織が暗号技術的な信頼を確立・維持できるよう支援します。

EJBCA Enterpriseは、Keyfactorの認証局(CA)およびPKIプラットフォームであり、高可用性デプロイとREST API自動化のために設計されています。エンタープライズ製品として提供されるEJBCAは、X.509証明書の発行、OCSP検証、証明書失効リスト(CRL)の配布、そしてWebコンソールとREST APIの両方を通じた完全な証明書ライフサイクル管理を提供します。EJBCAは、オンプレミス、コンテナ、またはAmazon Elastic Compute Cloud(Amazon EC2)上へのデプロイをサポートします。

AWSとKeyfactorのパートナーシップは、AWSのマネージドサービス(Amazon Bedrock、AWS Secrets Manager、Amazon Relational Database Service(Amazon RDS))と、証明書ライフサイクル管理、自動登録、リアルタイム失効をサポートするPKIインフラストラクチャを組み合わせたものです。この組み合わせは、AIエージェントエコシステムにおけるギャップに対処します。AWSがコンピューティング、ストレージ、AI推論レイヤーを提供する一方、Keyfactorは、エージェントを検証可能で失効可能な短命の認証情報に紐付ける暗号技術的なアイデンティティレイヤーを提供します。AWSとKeyfactorのエンジニアリングチームが共同で開発したこのジョイントリファレンスアーキテクチャは、これらのテクノロジーを統合する方法を示しています。ここで示すパターンは、皆さんのマルチエージェントデプロイに適用できます。

ソリューションの概要

このアーキテクチャは3つの認証レイヤーを実装しており、それぞれがエージェント通信チェーンにおける異なる信頼境界に対処します。これら3つのレイヤーは、前述の4つのセキュリティ機構、すなわち所有証明のための署名付きエンベロープ、認証情報不要の認可のための委任アサーション、露出制限のためのオーディエンススコープトークン、リアルタイム失効のためのOCSPを使用します。各機構は、次の表に示すようにレイヤーをまたいで組み合わされます。

レイヤー	信頼境界	機構	検証内容
1. ユーザー認証	ユーザーからシステムへ	OAuth + X.509証明書 + 委任ミント	ユーザーアイデンティティ、認証情報のバインディング
2. エージェント間	エージェントからエージェントへ	署名付きエンベロープ(PoP + nonce + タイムスタンプ)	呼び出し元のアイデンティティ、リクエストの新鮮性、リプレイなし
3. MCP認証	エージェントからツールサーバーへ	スコープトークン + エンベロープ + 委任	すべてのID、認可チェーン、OCSP

図1は、3つの認証レイヤーと、ユーザー、エージェント、MCPツールサーバーの間で認証情報がどのように流れるかを示しています。この図は、ユーザー認証情報（ログインフロー内に留まるもの）、エージェント認証情報（エージェントごとにスコープ設定されるもの）、およびそれらを接続する委任チェーンの分離を示しています。

図1: AWS上のAIエージェントシステム向けの3層PKI認証アーキテクチャ

図2は、典型的なユーザーセッション中の詳細なトラフィックフローを示しています。ログインから証明書発行、エージェントへの委任、ツールの呼び出し、セッションのクリーンアップに至る認証ステップのシーケンスが示されています。

図2: ユーザーログインからエージェント委任、ツール呼び出し、セッションクリーンアップまでの認証トラフィックフロー

使用するAWSサービス

以下のAWSサービスが、この参照アーキテクチャの基盤を形成します。

サービス	目的
Amazon Bedrock	Strands Agents SDKを介したLLM推論
Amazon RDS for MySQL	MCPツールを介してアクセスされるアプリケーションデータベース
Amazon Simple Email Service (Amazon SES)	Email Agent向けのメール配信
AWS Secrets Manager	PKCS12バンドル、トークン、メタデータのセキュアな保管
Amazon EC2	Keycloak IDPとEJBCA PKIサーバーのホスト

ソリューションの手順

以下のステップでは、最初のユーザーログインからセッションクリーンアップまで、アーキテクチャの各コンポーネントを順に説明します。各ステップは前のステップの上に構築され、人間のユーザーと最終的なツール実行を結ぶ信頼の連鎖を確立します。

前提条件

Amazon Bedrock、Amazon RDS for MySQL、Amazon SES、AWS Secrets Managerへのアクセス権を持つアクティブなAWSアカウント。
Keycloak 26.2以降(RFC 8693標準のトークン交換に必要です。以前のバージョンは互換性のないレガシー交換を使用します)。
REST API V1とOCSPレスポンダが設定されたKeyfactor EJBCA Enterprise。
REST API認証用のEJBCA API管理者証明書(api-admin.p12)。
Python 3.9+開発環境。
X.509証明書、OCSP、OAuth 2.0、RSAデジタル署名、PKCS#12キーストアに関する知識。

ステップ1: ユーザーログイン、証明書発行、委任の作成

ログインフローは、3つのメカニズムによってユーザーの識別情報を確立したうえで、ユーザーの資格情報を共有することなくAIエージェントに権限を委任します。この分離は極めて重要です。エージェントは、ユーザーの秘密鍵やフルセッションのOAuthトークンを一切保持することなく、認可の証明を受け取ります。

まず、アプリケーションはOAuth 2.0パスワードグラントを使用してKeycloakに対してユーザーを認証し、フルセッションのアクセストークンとリフレッシュトークンを受け取ります。直後に、アプリケーションはRFC 8693トークン交換を実行して、スコープを絞ったダウンスコープトークンを取得します。このトークンのオーディエンスはMCPサーバーに制限されます。エージェントに渡されるのは、この限定されたトークンだけです。誤って露出した場合でも、組織内の他のサービスにはアクセスできません。

次に、アプリケーションはRSA 2048以上のキーペアをローカルで生成し、Certificate Signing Request(CSR)を pkcs10enroll REST APIエンドポイントを通じてEJBCAに送信します。EJBCAはCSRに署名して証明書を返します。アプリケーションは証明書と秘密鍵をPKCS12コンテナにバンドルし、AWS Secrets Managerに保存します。秘密鍵がアプリケーションの境界の外に出ることはありません。EJBCAには送信されず、エージェントと共有されることもなく、ファイルシステムに保存されることもありません。同じCSRベースのフローを使用して、エージェントロールごとに1枚、合計3枚のエージェント証明書が発行されます。

3番目に、ユーザーの秘密鍵が委任アサーションに署名します。これは、3つのエージェント証明書すべてのSHA-256フィンガープリントと、ユーザーのサブジェクト名、発行時刻、有効期限を列挙したJSONドキュメントです。この委任により、ユーザーがこれらの特定のエージェントに自身に代わって行動することを認可したことが証明されます。エージェントはユーザーの証明書の代わりにこの委任を保持します。

# RFC 8693 Token Exchange - downscope to MCP audience
downscoped_token = keycloak.token_exchange(
    original_token, audience="mysql-mcp-server", scope="database:write"
)
# Client-side key generation (user key never leaves this flow)
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
csr = build_csr(private_key, f"CN={username},E={username}@org.com")
user_cert = ejbca.pkcs10enroll(csr, ca_name="UserCA")
# User signs delegation over agent cert fingerprints
delegation = mint_delegation(
    username=username,
    user_cert_pem=user_cert,
    user_key_pem=private_key_pem,
    agent_cert_pems=[orch_cert, mysql_cert, email_cert]
)
# Result: {sub, agent_fingerprints[], iat, exp, user_cert_pem, signature_b64}

ステップ2: エージェント間の署名付きエンベロープ

オーケストレーターエージェントがリクエストをサブエージェント(MySQLエージェントやEmailエージェントなど)にルーティングする際、身分証明のために単に自身の証明書を渡すだけではありません。代わりに、ツール名、引数、タイムスタンプ、および暗号論的にランダムなノンスを含むリクエストペイロード全体を、自身の秘密鍵と RSA-PSS-SHA256を用いて署名します。結果として得られる署名済みエンベロープは所有証明(proof-of-possession)を提供します。受信側のエージェントは、呼び出し元が提示された証明書に対応する秘密鍵を実際に保持していることを検証できます。

受信側のエージェントは、リクエストを処理する前に、エンベロープに対して6つの検証チェックを実行します:

署名の検証: 送信者が秘密鍵を所有していることを証明します（proof-of-possession）。
タイムスタンプの鮮度: 封筒は以下の範囲内でなければなりません ENVELOPE_MAX_AGE_SECONDS （デフォルトは60秒）現在時刻から。
ナンスの一意性: ザ ReplayCache 以前に使用されたnonceを拒否し、リクエストのリプレイを防止します。
CAチェーン検証: 送信者の証明書は、信頼されたCA（UserCA.pem).
ロール認可: 証明書CNのロール接尾辞が、このエージェントに対する ALLOWED_CALLER_ROLES に含まれている必要があります。
OCSP失効チェック: EJBCAへのリアルタイムチェックにより、証明書が失効していないことを確認します。

オーケストレーターが同じプロンプトを再送する必要がある場合（例：一時的な障害の後）、新しいナンスを用いて新しいエンベロープを作成しなければなりません。古いエンベロープは、正規の送信者であってもリプレイできません。

# Orchestrator signs request to sub-agent
envelope = sign_envelope(
    payload={"tool": "query_database", "args": {"sql": "SELECT ..."}},
    cert_pem=orchestrator_cert_pem,
    private_key_pem=orchestrator_key_pem
)
# envelope: {payload_b64, cert_pem, timestamp, nonce, signature_b64, alg}
# Sub-agent verifies (six checks)
verified_payload = verify_envelope(
    envelope,
    allowed_role="orchestrator-agent",
    ca_cert_pem=ca_pem,
    replay_cache=cache
)

ステップ3: MCPサーバー認証

MCPサーバー（FastMCP）は、データベース操作が実行される前の最終的な信頼境界です。すべてのツール呼び出しに対して4つの検証チェックを実行し、多層防御を実現します。たとえ1つの資格情報が不正アクセスを受けたとしても、残りのチェックによって不正な操作は防止されます。

認証シーケンス:

トークンイントロスペクション: Keycloakの /token/introspect エンドポイントへのPOSTにより、トークンがアクティブであり、そのオーディエンスに「mcp-server」が含まれていることを検証します。正しいオーディエンスを持たないフルセッショントークンは拒否されます。
エンベロープ検証: エージェントの署名済みエンベロープは、署名の正しさ、タイムスタンプの新しさ、ナンスの一意性、CAチェーンの信頼、ロールの一致（mysql-agent）、OCSPによる未失効について検証されます。
委任検証: ユーザーの委任アサーションが検証されます。署名は、ユーザーの鍵の保持者がこの委任を承認したこと、呼び出し元エージェントの証明書フィンガープリントが許可リストに含まれていることを証明し、ユーザーの証明書はOCSPを通じてチェックされます。
同一性クロスチェック: トークンのユーザー名、委任のサブジェクト、およびエージェント証明書のCN接頭辞は、すべて一致しなければなりません。これにより、ユーザーからツール実行までの一貫した単一の同一性チェーンが確認されます。

# MCP Server - Four validation checks
# 1. Token: must be active with correct audience
info = introspect(token)
assert info["active"] and "mcp-server" in info["aud"]
# 2. Envelope: proof-of-possession + freshness + replay + CA + role + OCSP
payload = verify_envelope(envelope, "mysql-agent", ca_pem, replay_cache)
# 3. Delegation: user authorized this agent + user cert not revoked
claims = verify_delegation(delegation, agent_cert_pem, ca_pem)
# 4. Cross-check: consistent identity chain
assert token_username == claims["sub"] == agent_cn.rsplit("_", 1)[0]
# All checks passed - execute tool
result = execute_sql(payload["args"]["sql"])

ステップ4: リプレイ防止

すべての署名済みエンベロープは、Pythonのsecretsモジュールで生成された128ビットの暗号学的にランダムな16進文字列である一意のナンスを持ちます。 ReplayCache はスレッドセーフなインメモリストアで、新鮮性ウィンドウが切れるまで（2倍の ENVELOPE_MAX_AGE_SECONDS). 同じノンスが2回目のリクエストに現れた場合、たとえ署名が有効でタイムスタンプが最新であっても、エンベロープは直ちに拒否されます。

タイムスタンプ検証はノンスチェックを補完するものです。エンベロープのタイムスタンプは、サーバーの現在時刻から ENVELOPE_MAX_AGE_SECONDS (デフォルトは60秒) 以内でなければなりません。これらのメカニズムを組み合わせることで、4つの不正アクセスシナリオに対処します:

記録済みリプレイ: 不正ユーザーが有効なエンベロープを取得し、後で再送信するシナリオです。ノンスはすでに確認済みです。
遅延配信: 伝送中に傍受されたエンベロープが、新鮮性ウィンドウの経過後に到着するシナリオです。タイムスタンプチェックに失敗します。
古いリクエストの再利用: プロキシにキャッシュされた古いエンベロープが再送信されるシナリオです。ノンスとタイムスタンプの両方のチェックに失敗します。
事前計算された偽造: 不正ユーザーは将来のノンスを予測してエンベロープに事前署名することはできません。

ステップ 5: クライアント側の鍵生成

このアーキテクチャの重要なセキュリティ特性は、秘密鍵がローカルで生成され、外部システムに一切送信されないことです。アプリケーションはPythonのcryptographyライブラリを使用してRSA 2048+の鍵ペアを生成します。公開鍵とサブジェクト情報のみを含むCSRを構築し、CSRのみを次の pkcs10enroll エンドポイントを通じてEJBCAに送信します。

EJBCAはCSRを検証し、証明書プロファイル(7日間の有効期間、鍵使用制約)を適用し、CA鍵で署名して、発行された証明書を返します。アプリケーションはその後、ローカルで保持していた秘密鍵と返却された証明書をPKCS12コンテナにバンドルし、AWS Secrets Managerに保存します。

この設計はいくつかのセキュリティ特性を提供します:

ユーザーの秘密鍵は、ログイン時に委任アサーションに署名するためにのみ使用されます。エージェントと共有されることはありません。
各エージェントの秘密鍵は、そのエージェントがエンベロープに署名するためにのみ使用されます。エージェント間で共有されることはありません。
EJBCAは秘密鍵を一切閲覧または保存しません。純粋に証明書認証局として動作します。
Secrets Managerが不正アクセスを受けた場合でも、(別途保存されている) PKCS12のパスワードが追加の保護層となります。
鍵マテリアルは、次回のログイン時に新しいCSRで再登録することにより、独立してローテーションできます。

ステップ 6: 完全なログアウトと資格情報の失効

ログアウトすると失効カスケードがトリガーされ、未処理のすべての資格情報が直ちに無効化されます。このシーケンスにより、完了後は有効な資格情報が一切残りません:

EJBCAでユーザー証明書を失効させる: これにより、すべての未処理の委任が即時に無効化されます。委任の検証はOCSPを通じてユーザーの証明書をリアルタイムで確認するためです。
3つのエージェント証明書をすべて失効させる: これにより、すべての未処理の署名済みエンベロープが無効化されます。エンベロープの検証にはOCSPが含まれているためです。
AWS Secrets Managerからすべてのシークレットを削除する: リカバリーウィンドウなしで即時に削除するには、 ForceDeleteWithoutRecovery を使用します。
Keycloakセッションを終了する: セッション終了エンドポイントを通じてダウンスコープされたトークンを無効化します。

失効カスケードがこの鍵となるセキュリティ特性です。PKI層で単一のユーザー証明書を失効させると、トークンを個別に失効させたり、セッションを削除したり、各エージェントに連絡したりすることなく、下流のすべてのエージェント権限が速やかに失効します。OCSPが伝播メカニズムを提供し、すべてのリクエストがOCSPをチェックするため、その効果は即時です。

セキュリティに関する考慮事項

このアーキテクチャにおける設計上の選択は、本番環境のマルチエージェントデプロイメントにとって重要ないくつかのセキュリティ特性に対応しています。

秘密鍵の分離。ユーザーの秘密鍵はログインフロー中にのみ存在し、委任への署名にのみ使用されます。エージェントキーはエージェントごとにスコープされ、決して共有されません。鍵素材が信頼境界を越えることはありません。

クレデンシャル共有と比較した委任。エージェントは、ユーザーのクレデンシャルを一切保持することなく、暗号学的チェーン(委任からエージェントフィンガープリント、さらにエンベロープ署名へ)によって権限を証明します。エージェントキーが漏洩した場合、明らかになるのはそのエージェントのキーのみであり、ユーザーのキーではありません。

オーディエンススコープのトークン。RFC 8693のトークン交換は、MCPサーバーのみが受け入れるトークンを生成します。誤って漏洩したダウンスコープ済みトークンは、Keycloak管理API、他のサービス、さらには別のMCPサーバーインスタンスに対しても認証できません。

リプレイ防止。リクエストごとのノンスと60秒の鮮度ウィンドウの組み合わせにより、すべてのリクエストが単回使用かつ時間的に限定されていることが確認されます。 ReplayCache はスレッドセーフで、自動クリーンアップを行います。

フェイルクローズド設計。すべての検証失敗は即時の拒否につながります。OCSPに到達不能:拒否。無効な署名:拒否。期限切れのタイムスタンプ:拒否。再使用されたノンス:拒否。誤ったオーディエンス:拒否。セキュリティチェックにグレースフルデグラデーションはありません。

失効カスケード。1つのユーザー証明書を失効させると、すべての委任、すべてのエージェント権限、およびすべての未処理のエンベロープが速やかに無効化されます。これはリアルタイムのOCSPを通じて伝播され、個別のクレデンシャルクリーンアップを必要としません。

前方専用の信頼チェーン。 ALLOWED_CALLER_ROLES マップは、 orchestrator-agent のみが mysql-agent および email-agentを呼び出せることを強制します。サブエージェントは互いに呼び出すことができず、オーケストレーターを上方に呼び出すことも、ユーザーになりすますこともできません。

AIガバナンスに関する考慮事項

PKIアーキテクチャは、このシステム内のAIエージェントに組み込みの行動境界を提供します。本番環境のデプロイメントでは、この記事で説明したPKIベースのアクセス制御に加えて、Amazon Bedrock Guardrailsを使用して、エージェントの応答に対するコンテンツフィルタリング、トピックの回避、およびグラウンディングチェックを強制する必要があります。

ツール境界: AIエージェントは厳格なツール制約の下で動作します。事前定義されたMCPツール(execute_sql, describe_table, list_tables)のみを呼び出すことができます。エージェントは任意のコードを実行したり、証明書のスコープ外のリソースにアクセスしたりすることはできません。
人間による監視: すべてのエージェントのアクションはログに記録され、監査可能です。AWS CloudTrailがAWS API呼び出しをキャプチャし、MCPサーバーは、完全なアイデンティティチェーン(ユーザー、エージェント、タイムスタンプ、および操作)とともに、検証されたすべてのツール呼び出しをログに記録します。
データ処理: ユーザークエリと結果は、認証済みセッションの境界内に留まります。オーディエンススコープのトークンにより、データアクセスは特定のMCPサーバーインスタンスに制限されます。
証明書ベースの動作境界: エージェントは、有効な証明書を保持しているツールのみを呼び出すことができます。 mysql-agent 証明書を持たないエージェントは、LLMがどのような指示を生成しても、データベースにアクセスできません。

アーキテクチャの拡張

このアーキテクチャは、追加のエージェントタイプ、水平スケーリング、マルチテナント分離をサポートするように拡張できます。以下の段落では、最も一般的な拡張ポイントについて説明します。

新しいエージェントタイプを追加するには、 ALLOWED_CALLER_ROLESにエントリを追加するだけで済みます。証明書はログイン時に自動的に発行され、委任アサーションには新しいエージェントのフィンガープリントが動的に含まれます。インフラストラクチャの変更は不要です。
水平スケーリングについては、ロードバランサーの背後でEJBCAのOCSPレスポンダを高可用性モードでデプロイできます。AWS Secrets Managerは、このワークロードに適した高リクエストレートをサポートしています。 ReplayCache は、分散デプロイメントのためにAmazon ElastiCacheでバックアップできます。
本番環境向けにアーキテクチャを強化するには、AWS CloudHSMまたはオンプレミスのHSMを介して、ハードウェアセキュリティモジュール（HSM）バックアップのEJBCA署名鍵を使用できます。OCSP応答のステープリングにより検証のレイテンシーが削減され、Certificate Transparencyログにより発行された証明書の完全な監査証跡が提供されます。
マルチテナントデプロイメントでは、テナントごとの証明書機関またはテナントごとの委任機関を作成することで、暗号学的なテナント分離を実現できます。テナントごとのAWSアカウントと組み合わせることで、テナント間の強力な分離が実現します。
PKIベースのエージェントIDは、AWS Identity and Access Management（IAM）ロールで補完することもできます。エージェント間認証にはPKIを、AWSサービスの認可にはIAMを使用します。2つのシステムは独立して動作し、多層防御を提供します。

クリーンアップ

継続的な課金を避けるために、このウォークスルーで作成したリソースを削除してください：

Amazon RDS for MySQLインスタンスを削除します（スクリプトによるセットアップを使用した場合は、AWS CloudFormationスタックを削除します）。
AWS Secrets Managerからすべてのシークレットを削除します。これには、 mcp/ プレフィックスの下にあるユーザー証明書とエージェント証明書が含まれます。
検証済みの送信者メールアドレスをAmazon SESから削除します。
KeycloakとEJBCAを実行しているAmazon EC2インスタンスを終了します(このデモのためにデプロイした場合)。
EJBCAの管理コンソールまたはREST APIを使用して、EJBCA内のすべてのテスト証明書を失効させ、削除します。
Keycloakレルム(mcp-realm)および関連するクライアントを削除します。
スクリプトによるセットアップを使用した場合は、 ./scripts/cleanup.sh (Linux)または ./scripts/cleanup.bat (Windows)を実行して、これらの手順を自動化できます。

まとめ

この記事では、Keyfactor EJBCAとAWSのサービスを使用したX.509 PKIによるAIエージェント通信の保護について、リファレンスアーキテクチャを実演しました。このアーキテクチャは、4つの相互補完的なメカニズムを通じて、マルチエージェントAIシステムにおける根本的なアイデンティティのギャップに対処します:

署名付きリクエストエンベロープにより、エージェント間のすべての呼び出しにおいて暗号学的な所有証明が提供され、不正な第三者がエージェントのアイデンティティを偽造したりリクエストをリプレイしたりすることが大幅に困難になります。
ユーザー署名付きの委任アサーションにより、認可とクレデンシャルの共有が分離されます。エージェントは、ユーザーの秘密鍵やフルセッショントークンを保持することなく、ユーザーの代理として行動する権限を持っていることを証明できます。
RFC 8693のオーディエンススコープトークンにより、トークンが漏洩した場合の露出範囲が単一のサービス境界に限定されます。
リアルタイムのOCSP失効確認により、クレデンシャルの失効がシステム全体に即座に反映されることが確認されます。あるユーザー証明書を失効させると、下流のすべてのエージェントの権限が速やかに終了します。

このアーキテクチャはフレームワークに依存しません。ここではAWS Strands Agents SDKとFastMCPを使って実演しましたが、同じPKIパターンは、LangChain、CrewAI、AutoGen、またはツールプロトコルを使用するその他のマルチエージェントフレームワークにも適用できます。AIエージェントが普及し、ますます機密性の高い操作にアクセスするようになるにつれて、エージェントのアイデンティティインフラストラクチャはオプションから必須のものへと移りつつあります。

このリファレンスアーキテクチャの使用を開始するには、 accompanies GitHubリポジトリを参照してください。使用したサービスの詳細については、以下のリソースを参照してください:

著者について

原文の出典

AWS Machine Learning

原文を読む

内容について

原文の公開と権利は出典元に帰属します。

機械翻訳 · 原文をご参照ください