A2AおよびMCPエージェントのセキュリティ：アイデンティティ、委任、および監査証跡

LLMシステムにおけるセキュリティの関心は、プロンプトインジェクションに最も集中していますが、それは確かに注目を集めるべきものです。しかし、エージェントがツールを呼び出し、他のエージェントに作業を委任し始めると、それは問題の一部に過ぎなくなります。

MCP（Model Context Protocol）は、エージェントにファイル、API、データベース、チケットシステムへの構造化されたアクセスを提供します。A2A（Agent-to-Agent）プロトコルは、1つのエージェントがタスク、メッセージ、アーティファクトを、別のチーム、ベンダー、ランタイムに属する可能性のある別のエージェントに送信することを可能にします。これらのプロトコルは、信頼境界を横断するからこそ有用であり、つまり、アイデンティティ、認可、委任の制限、監査証跡がオプションの強化ではなく、第一級のアーキテクチャ要素となることを意味します。

この記事は、LLMアーキテクチャクラスターのエージェントプロトコルセキュリティに関する標準的なガイドです。脅威モデル、アイデンティティ、ゲートウェイ、レジストリ、委任、本番環境チェックリストをカバーします。入力検証、出力フィルタリング、プロンプト安全性パターンについては、代わりに実践的なLLMガードレールを参照してください。

ガードレール vs プロトコルセキュリティ vs ランタイムポリシー

この3つのレイヤーは異なる問題を解決し、混同されると異なる方法で失敗します。

LLMガードレールはモデルの入力と出力で動作します：インジェクションパターンのブロック、有害コンテンツのフィルタリング、JSON形状の検証、生成されたテキストに対するトーンまたはコンプライアンスルールの強制です。それらは会話レイヤーを保護します。

プロトコルセキュリティはエージェントの境界で動作します：どのエージェントがどのMCPツールを呼び出せるか、どのエージェントがどのピアに委任できるか、タスクにどのOAuthスコープが紐づくか、下流のエージェントがユーザーの代わりに行動できるかどうかなどです。それらはアクションレイヤーを保護します。

ランタイムポリシーはそれらの間を埋めます：トリガーが自然言語であったか構造化プロトコル呼び出しであったかに関わらず、ルールに対してリクエストを評価するポリシーエンジンです。ツールの実行前に人間の承認を要求したり、不明なドメインへのエグレスをブロックしたり、スコープが元のユーザーを超えた場合に委任を拒否したりすることができます。

私の意見は明確です：プロトコルセキュリティなしのガードレールは、ツール呼び出しを通じてデータを漏洩し続ける礼儀正しいチャットボットを生み出します。ガードレールなしのプロトコルセキュリティは、悪意のある指示をアーティファクトに埋め込んでも従い続ける、適切に認証されたエージェントを生み出します。両方が必要であり、高リスクなアクションにはランタイムポリシーも必要です。

A2AおよびMCPエージェントシステムの脅威モデル

コントロールの買い物リストではなく、資産と敵対者から始めましょう。

保護すべき資産： プロンプトとアーティファクト内のユーザーデータ、MCPサーバーの資格情報、ツールを通じてアクセス可能な本番環境システム、エージェントの評判、トークン使用量に紐づく請求アカウント、監査の整合性。

現実的な敵対者： 公開エージェントエンドポイントを悪用する外部ユーザー、毒されたツール結果を返す侵害されたMCPサーバー、エージェントカードでスキルを誤って表現する悪意のあるエージェント、権限を過剰に委任する内部者、モデルの動作を操作するツールメタデータに対するサプライチェーンの改ざん。

悪意のあるまたは侵害されたツール（MCP）

MCPサーバーは、モデルに公開されるコードとデータです。敵対的なサーバーは、誤解を招くツール記述を返し、モデルから渡された引数を漏洩させたり、ホストがスコープされた資格情報なしでツール呼び出しを実行する場合に、ユーザーの意図を超えたアクションを実行したりすることができます。

悪意のあるまたはなりすまされたエージェント（A2A）

タスクを受け入れるエージェントは、悪意がある、侵害されている、あるいは単に権限が広すぎる可能性があります。エージェントカードは機能を記述しますが、署名、TLS、発行者の信頼を検証しない限り、アイデンティティを保証するものではありません。

混乱した代理人（Confused Deputy）

エージェントBは財務APIにアクセスする権限を持っています。権限が低いエージェントAが、アーティファクトに送金指示を隠し持たせながら「この請求書を要約してください」とBに依頼します。委任スコープがエンドツーエンドで強制されない限り、Bは自身の資格情報を使用して実行します。

広すぎる権限と隠れた委任チェーン

ユーザーが1つのステップを承認します。オーケストレーターは静かに3つのA2Aホップと5つのMCP呼び出しをチェーンします。ユーザーは完全なグラフを見ることはありませんが、組織は結果に対して依然として責任を負います。

アーティファクトとエージェント間メッセージを通じたプロンプトインジェクション

インジェクションはユーザーメッセージの問題だけではありません。PDFアーティファクト、ツールによって取得されたウェブページ、またはエージェントCからのメッセージは、エージェントDのモデルを対象とした指示を含んでいる可能性があります。モデル境界におけるプロトコル経由のすべてのコンテンツを信頼できない入力として扱ってください。

毒されたまたは誤解を招くエージェントカード

記述とスキル名はプロンプトの表面積です。safe_read_only_analysis（安全な読み取り専用分析）を宣伝しながら、書き込み可能なバックエンドを受け入れるカードは、技術的な保証ではなく、ソーシャルエンジニアリングのレイヤーです。

マルチエージェントシステムのアイデンティティモデル

プロトコルセキュリティは、明確なアイデンティティタイプと、それぞれが何を保証できるかから始まります。

A2Aのエージェントカードは、サポートされている認証スキーム（OpenAPIの慣行に準拠したOAuth 2.0、APIキー、mTLS、および類似のパターン）と、オプションのセキュリティ要件付きのスキルを宣伝します。カードは発見メタデータであり、信頼アンカーではありません。クライアントはバンドアウトで資格情報を取得し、各リクエストで標準HTTPヘッダーを送信します。サーバーは各呼び出しで検証し、認証またはスコープが失敗した場合に401または403を返す必要があります。

同じエージェントの内部ビューと外部ビュー

本番環境のエージェントは、限られたスキルリストを持つ公開エージェントカードと、内部呼び出し者向けのより豊富な認証済みカードを公開することがよくあります。A2A仕様は、認証済みクライアント向けの拡張カードを許可します。この分割を意図的に使用してください：パートナーは内部スキルを見るべきではなく、内部オーケストレーターは公開発見のみで認可に依存すべきではありません。

MCPおよびA2Aのための認証と認可

認証は誰が呼び出しているかに答えます。認可は何が許可されているかに答えます。

MCPツールへのアクセス

各MCP接続に対して、以下を定義します：

• どのエージェントホストが接続できるか
• そのホストに対してどのツールが有効化されているか
• サイドエフェクトを実行するOSユーザーまたはサービスアカウント
• 人間ユーザーが各変更呼び出しを承認する必要があるかどうか

「すべてに接続する」MCP設定よりも、ツールの許可リストを優先してください。コーディングエージェントは、公開サポートボットと同じプロファイルで給与管理MCPサーバーを必要としません。

A2Aエージェントへのアクセス

各エージェントピア関係に対して、以下を定義します：

• どの呼び出し元エージェントIDがどのスキルを呼び出せるか
• 最大委任深さ
• 境界を跨ぐことができるアーティファクトタイプ
• ユーザーコンテキストが署名済みクレームとして伝播する必要があるかどうか

OAuthスコープ（または同等物）を、一般的なエージェント管理者ではなくスキルにマッピングします。トークンレイヤーでの最小権限が、プロンプトレイヤーでの希望よりも優れています。

ゲートウェイ強制 vs エージェント個別ポリシー

エージェント個別ポリシーは、1つのチームがグラフ全体を所有し、リリースが調整されている場合に機能します。ゲートウェイ強制ポリシーは、複数のチーム、テナント、またはベンダーがエージェントネットワークを共有し、許可リスト、レート制限、監査を1つの場所で強制する必要がある場合に機能します。

コントロールプレーンとしてのA2Aゲートウェイ

A2Aゲートウェイはプロトコルによって厳密に必要とされていませんが、エージェントトラフィックに集中化されたガバナンスが必要なときに必要になります。

ゲートウェイは通常、以下を処理します：

• 認証の終了とトークン交換
• スキルまたはテナントによる正しいエージェントサービスへのルーティング
• タスクが受け入れられるまたは転送される前のポリシーチェック
• プロトコルバージョンのネゴシエーション
• レート制限と不正利用の検出
• 各タスク遷移における構造化監査の出力

ゲートウェイが過剰になる場合 vs 必要になる場合

ゲートウェイは、1つのチームによって維持される1つのKubernetes名前空間内の1つのオーケストレーターと2つのスペシャリストエージェントにとっては、しばしば過剰です。パートナーがあなたのエージェントを呼び出すとき、複数の事業部門がインフラを共有するとき、コンプライアンスが統一されたログを要求するとき、またはすべてのエージェント実装がポリシーを正しく強制すると信頼できないときに必要になります。

A2AゲートウェイをMCPゲートウェイ（またはMCPプロキシ）と組み合わせることで、ツールアクセスに同じ扱い（アイデンティティ、許可リスト、エグレス制御、ツール境界での監査）を提供します。チャットUIでのみではありません。

パートナー向け vs 内部用エージェントカード

外部呼び出し者と内部呼び出し者に対して異なる発見メタデータを公開します。外部カードは狭いスキルとより厳格な認証を公開します。内部カードはメンテナンスまたは管理者スキルをリストできますが、公開カードが示すよりも強力な認証なしに到達可能であってはなりません。

エージェントレジストリと発見セキュリティ

発見は攻撃表面の一部です。「利用可能」に見えるエージェントを制御できる者は、オーケストレーターが作業を送る先を制御します。

レジストリ vs 周知エージェントカードURL

小規模デプロイメントは、エージェントごとに周知URL（/.well-known/agent-card.json）を使用します。エンタープライズデプロイメントは、エージェントID、バージョン、エンドポイント、所有者、ポリシータグを索引化するレジストリを追加します。レジストリはポリシーオブジェクトです：エントリは、それらがどこに住んでいるだけでなく、どのテナントがどのエージェントを発見できるかを記録する必要があります。

バージョン管理、非推奨、所有権

レジストリレコードには、所有者、変更履歴、非推奨日が必要です。エージェントカードをキャッシュするオーケストレーターは、TTLで更新し、サポートされている場所で署名を検証する必要があります。古いカードは、脆弱性が修正されてもずっと後まで、引退したスキルがトラフィックを受け続ける方法です。

エンタープライズ内部ネットワーク vs 外部パートナー

内部エージェントメッシュは、mTLSとプライベートDNSに依存できます。パートナーエージェントは、ランタイムを制御していないため、明示的な連合ルール、契約的にスコープされたスキル、およびより強力なアーティファクト検査を必要とします。

エージェント境界を跨ぐ委任

委任は、A2Aセキュリティが勝利または敗北する場所です。エージェントAがタスクをエージェントBに送信する際、3つの質問に明確な答えが必要です：

1. 誰の権限が行使されているか？ ユーザーのもの、Aのサービスアカウント、または混合された委任トークンか？
2. Bはその権限で何をすることを許可されているか？ 読み取り専用分析、またはAの代わりに変更ツールか？
3. Bがスコープを超えた場合、誰が責任を負うか？ A、B、ゲートウェイポリシー、または不明確なプロンプトを承認した人間か？

ユーザー意図の伝播 vs 過剰委任

ユーザーID、元のタスクID、許可されたスキル、有効期限、最大ホップ数を含む署名済み委任クレームを渡します。下流のエージェントは、静かにスコープを拡張するタスクを拒否する必要があります。BがAが持っていたよりも高い権限を必要とする場合、input_required（入力が必要）に遷移し、トークンを不可視にアップグレードするのではなく、明示的な人間の承認を取得します。

リスクのある委任のための人間による承認フローは、A2Aストリーミングと長時間実行エージェントワークフローのための非同期タスクでカバーされており、input_requiredはエラーではなく第一級のタスク状態です。

推論と実行権限の分離

エージェントは、書き込みツールが承認の背後にある間に計画するために広範な読み取りアクセスを必要とする場合があります。モデルの誤りが直ちに本番環境を変更できないように、推論と実行のために資格情報を分割するか、異なるMCPプロファイルを使用します。

監査証跡と回答の出自

委任チェーンを再構築できない場合、インシデントを説明できません。監査をパスできません。請求の異常を争うこともできません。

3つのレイヤーでログを記録します：

ゲートウェイ： 認証結果、ポリシー決定、ルーティングされたエージェントID、タスクID、親タスクID、レート制限イベント。

エージェント： タスク状態遷移、送信/受信メッセージ、モデル/ツール呼び出し（必要に応じて引数がマスク）、作成されたアーティファクト、外部への委任。

MCPサーバー： ツール名、呼び出し元エージェントID、ユーザーコンテキスト、成功/失敗、レイテンシ、影響を受けた行数またはリソースID（ポリシー許可）。

すべてのレイヤー間でトレースIDで相関します。LLMシステムの可視性は計装バックエンドをカバーします。この記事は何をキャプチャする必要があるかを定義し、それらのバックエンドが意味のあるシグナルを持つようにします。

最終回答の出自は以下に答えるべきです：どのユーザー、どのオーケストレータータスク、どのスペシャリストエージェント、どのツール、どのアーティファクトがユーザーが見たテキストに影響を与え、どのポリシーゲートが途中で発火したか。

ランタイムポリシー、エグレス、シークレット

ランタイムポリシーエンジン（OPA、Cedar、カスタムルールサービス）は構造化イベントを評価します：「ユーザーZのための引数Yを持つツールX」。それらはモデルがうまく振る舞うことに依存しないため、ガードレールを補完します。

人間の承認は、ランタイムポリシーにおける不可逆的または高コストのアクション（支払い、外部メール、本番環境設定変更、権限付与）に属します。

エグレス制御は、MCPサーバーとエージェントが呼び出せるドメインを制限します。シークレットを読み取ることができ、任意のURLにPOSTできるエージェントは、データ損失を待っている状態です。

シークレットはエージェントカードやプロンプトに含まれるべきではありません。MCPホストは、シークレットマネージャーから実行時に短命の資格情報を注入する必要があります。トランスポート暗号化、鍵管理、およびベースラインインフラセキュリティパターンについては、データを保護するためのアーキテクチャパターンを参照してください。

非同期A2Aフロー内のプッシュ通知ウェブフックは、同じ厳格さを必要とします：送信元のアイデンティティを検証し、古くなったイベントを拒否し、ウェブフックペイロードをそれ自体での認可として決して扱わない。

参照セキュリティアーキテクチャ

以下の図は、大規模なA2Aは外部、MCPは内部デプロイメントのための本番環境志向のレイアウトを要約します。

オーケストレーターはA2Aを通じてスペシャリストエージェントを見ます。スペシャリストはMCPを通じてツールを見ます。ユーザーは生のMCP資格情報を受け取ることはなく、パートナーはポリシーレビューなしで内部スキルサーフェスを受け取ることはありません。

プロトコル概念（エージェントカード、タスク、アーティファクト）については、A2Aプロトコルとは何ですか？を参照してください。採用とエンタープライズフレームについては、2026年のGoogle A2Aプロトコルを参照してください。多数のエージェントが協調する場合のトポロジーについては、マルチエージェントオーケストレーションパターンを参照してください。

A2AおよびMCPセキュリティのための本番環境チェックリスト

エージェントプロトコルを信頼されたサンドボックスを超えて公開する前に、以下を検証してください：

アイデンティティと認証

• 本番環境パスに匿名エージェントが存在しない
• 各MCPおよびA2A呼び出しが各リクエストで認証されている
• OAuthスコープまたは同等物が、一般的な管理者ではなくスキル/ツールにマッピングされている
• 公開 vs 認証済みエージェントカードビューが意図的に定義されている

委任とポリシー

• 委任トークンがユーザーID、タスクID、スコープ、有効期限、ホップ制限を保持している
• 下流エージェントが明示的な承認なしでスコープ拡張を拒否している
• 高リスクツールがランタイムポリシーまたは人間の承認を要求している
• 推論と実行が可能な限り分離された資格情報を使用している

発見とレジストリ

• エージェントレジストリエントリが所有者とバージョン履歴を持っている
• エージェントカードがTTLで更新され、サポートされている場所で署名が検証されている
• パートナーエージェントが明示的なスキル許可リストで連合化されている

監査と可視性

• ゲートウェイ、エージェント、MCPレイヤーが相関した監査イベントを出力している
• 委任チェーンが親と子タスクIDでログ記録されている
• 最終回答のためのアーティファクトの出自が記録されている
• トレースIDが可視性バックエンドに接続されている

不正利用とレジリエンス

• ユーザー、エージェント、テナントごとのレート制限
• 委任タスクのタイムアウトポリシー
• ツールサーバーのエグレス許可リスト
• シークレットがマネージャー内にあり、カード、プロンプト、リポジトリ内にはない

結論

A2AとMCPの相互運用性は、エージェントとツールがチームとベンダーの境界を跨って構成できるため強力ですが、アイデンティティ、認可、委任の制限、監査設計なしではその力は安全ではありません。ガードレールはモデルの会話を保護します。プロトコルセキュリティは、エージェントがユーザーの代わりに取るアクションを保護します。

エージェントカードを広告、委任を署名済み契約、MCPツールを特権コード実行、監査ログを午前2時に何かが起きたときに必要とする証拠チェーンとして扱ってください。

ガバナンスが単一の絞め殺す場所を必要とするときにゲートウェイを構築します。エージェントを分割する前に資格情報を分割します。答えが「モデルが決定した」ことが最終的なインシデントレポートにならないように、すべてのホップをログ記録します。

頻繁に質問される質問

LLMガードレールとA2A MCPエージェントセキュリティの違いは何ですか？ ガードレールはモデルの入力と出力を制約します。プロトコルセキュリティは、アイデンティティ、認可、監査証跡を通じて、誰がツールを呼び出し、タスクを委任し、誰の代わりに行動できるかをMCPおよびA2A間で制約します。

エージェントアイデンティティはA2Aデプロイメントでどのように機能すべきですか？ 人間、エージェントサービス、タスクのアイデンティティを分離します。各リクエストで資格情報を検証し、スコープ済みトークンを使用し、エージェントカードを信頼の証明ではなく発見メタデータとして扱います。

マルチエージェントシステムにおける混乱した代理人問題とは何ですか？ それは、権限のあるエージェントまたはツールが、権限の低い呼び出し元が委任またはアーティファクトを通じて指示を隠し持たせたために、機密アクションを実行するときに発生します。すべてのホップでスコープを強制します。

本番環境でA2Aゲートウェイは必要ですか？ 単一チームの内部デプロイメントは、エージェントごとにポリシーを強制できます。マルチテナント、マルチベンダー、またはパートナー向けのネットワークは、通常、集中化された認証、ルーティング、レート制限、監査のためにゲートウェイを必要とします。

A2A MCP監査ログには何を含めるべきですか？ ゲートウェイ、エージェント、MCPレイヤー間でトレースIDと相関した、ユーザーID、エージェントID、タスクID、親タスクID、ツール呼び出し、ポリシー決定、アーティファクト、タイムスタンプ。

出典

• A2A Protocol – Enterprise-ready security topics: https://github.com/a2aproject/A2A/blob/main/docs/topics/enterprise-ready.md
• A2A Protocol – Specification overview: https://a2a-protocol.org/latest/specification/
• A2A Protocol – Streaming and push notification security: https://a2a-protocol.org/latest/topics/streaming-and-async/