1. 序論と目的

背景と論拠

AIシステムが急速なペースで実用化され続ける中、システム間の相互作用とコンテキスト情報の共有は、モデルの精度を確保し、推論の継続性を維持し、それらに適応した応答を可能にするために不可欠となっている。このような状況の中で、モデルコンテキストプロトコル（MCP）は、大規模言語モデル（LLM）やエージェントベースシステムにおけるコンテキスト配信を構造化し、標準化するために設計された有望な新しいフレームワークとして登場した[1]。

MCPは、構造化されたコンテキストフローのメカニズムを通じて、モデル間の連携、実行コンテキストの共有、ポリシー駆動型のアクセス制御を容易にする。特に、ゼロ・トラスト・セキュリティ・アーキテクチャと統合する可能性があり、安全なAI運用のための戦略的基盤を提供する点で重要である[2]。しかし、MCPはまだ設計と実装の初期段階にあり、その構造的特性はいくつかの重大なセキュリティ脅威をもたらす：

• レイヤーにまたがるコンテキストの誤用

• 委任認証の悪用

• ポリシーのバイパスとモデルの誤動作[3][4]。

これらの脅威は単なる設定の欠陥ではなく、AIシステム全体の信頼性、一貫性、信頼性を損ないかねない深刻なリスクをもたらす。

分析の目的

このホワイトペーパーの目的は以下の通りである：

1. 2024年11月から2025年4月までに発表されたMCP関連の最新研究論文のうち15本を体系的にレビューおよび分析し、特に文献に示されたセキュリティ脅威シナリオの特定、分類、構造化に焦点を当てる。

2. 2024年11月、Anthropic社による最初の技術リリース後、現在入手可能なすべてのMCP出版物の包括的な分析を実施する。

3. MCPベースのアーキテクチャの上に構築されたLLMやAIエージェントシステムに出現する可能性のある、現実世界の攻撃ベクトルや脆弱性のカテゴリーを特定する。

4. この脅威分析に基づき、ポリシー主導の対抗策と実行可能な技術的保護方法を提案するとともに、MCP時代に特化した新しいセキュリティ・アーキテクチャの必要性を強調する。

レビューした文献の範囲

この分析は、arXiv、ResearchGate、Preprints.org 、Anthropicなどのプラットフォームで発表された、合計15のMCP関連の研究論文と技術報告に基づいている。選ばれた文書は、以下の主要な主題分野を網羅している：

• MCPアーキテクチャと標準化の動向

• ポリシーベースの制御と認証委任モデル

• LLMとコンテキスト配信フローの統合

• 脆弱性、異常な動作、監査の限界を含む、MCPシステム内のセキュリティ脅威シナリオ

レビューされた文献の完全な要約は、セクション2（文献レビューの枠組みと分類）の「MCPに関連する15の主要論文の要約表」に示されており、関連する戦略と所見に関連して、以下の各セクションを通して各文献が適宜引用されている。

分析の枠組み

• 主要キーワードによるトピック分類：MCPセキュリティ関連キーワードクラスターに基づく分類。

• 脅威の種類による構造化：シナリオを脅威カテゴリーT1～T4に分類。

• 情報源の信頼性、適時性、適用性の評価：信頼できる最新の研究プラットフォームからの文書を優先する。

• MCP セキュリティ・アーキテクチャとの関連性：戦略的な整合性、および現実世界の実装における適用可能性に基づいて評価される。

この分析の枠組みは、本ホワイトペーパーのセクション3（MCPベースのシステムにおけるセキュリティ脅威シナリオ分析）およびセクション4（セキュリティ脅威分析に基づく戦略的推奨事項）に適用される。

文書の構成

本ホワイトペーパーは5つの主要なパートで構成されており、それぞれがモデル・コンテキスト・プロトコル（MCP）ベースのAIシステムに関連するセキュリティ脅威を分析し、次世代のセキュリティ・アーキテクチャとともに構造的な対策を提案するよう設計されている：

1. 序論と目的

MCPの背景を説明し、コンテキストを意識したシステムにおける新たなセキュリティリスクを浮き彫りにする。15の主要な出版物のレビューに基づき、構造化された脅威分析の必要性を説明する。

1. 文献レビューの枠組みと分類

最近のMCP関連論文15本を定量的・定性的に分類・評価。分析結果は脅威カテゴリーT1～T4にマッピングされ、要約表には各研究の戦略的貢献度を示す数値関連性スコア（MSR）が記載されている。

1. MCPベースのシステムにおけるセキュリティ脅威シナリオ分析

MCP システムで観測される 4 つの中核的な脅威タイプ（T1～T4）について、シナリオに基づく例を用いて詳しく説明する。このセクションには、各脅威構造を視覚的に説明するためのコードサンプル、 実行フロー、および障害箇所が含まれている。

1. セキュリティ脅威分析に基づく戦略的提言

T1～T4の脅威に対処するための4つの戦略的柱（ポリシーの関連付け、コンテキスト統合、 委任管理、監査トレーサビリティ）を提案する。各戦略は、期待される影響とともに、MCP アーキテクチャ内の該当するセキュリティレイヤーにマッピングされる。

1. 結論と新しいセキュリティー・アーキテクチャーの提案

統合的、自律的、かつポリシー駆動型のセキュリティフレームワークとしてのMCP PAM（Model Context Protocol Privileged Access Management）を紹介する。このセクションでは、MCP 時代におけるセキュリティへのアプローチ方法のパラダイムシフトの必要性を強調する。

2. 文献レビューの枠組みと分類

分析の目的とアプローチ

本セクションは、モデル・コンテキスト・プロトコル（MCP）ベースのAIシステムにおけるセキュリティ脅威を理解し、対処するための基礎となる。この目標を達成するため、2024年11月から2025年4月までに発表された最近の論文15本を収集し、体系的に分析した。

選ばれた文献は、arXiv、Preprints.org、ResearchGate、Anthropicなど、評判の高いプラットフォームから入手したもので、以下の主要なトピックをカバーしている：

• MCPの基本的なアーキテクチャとコンテキスト指向のデザイン

• ポリシーベースのアクセス制御と委任メカニズムの限界

• コンテキストフローの処理と伝送経路における脆弱性

• 監査ログ構造の課題と監査可能性の確保

• LLMとエージェントベースのAI実行環境との間で統一されたポリシーを適用することの難しさ

この文献レビューは、表面的なトピックの要約や傾向の観察にとどまらない。その代わりに、実用的な基盤を構築することを目的としている：

• セクション3で議論される、T1～T4の中核となる脅威タイプを特定するための理論的根拠とシナリオに基づく根拠を確立する。

• セクション4で示される、ポリシー主導の戦略設計と階層的セキュリティマッピングに必要な構造的洞察を提供する。

• セクション5で提案されるMCP PAMアーキテクチャの機能レベルの検証をサポートする。

各出版物は、技術的貢献、セキュリティとの関連性、適用可能性、戦略的適合性という 4 つの基準について、量的・質的レンズを通して評価される。この評価に基づき、文献要約表（表1）と戦略適合性スコア（MSR：MCP Strategic Relevance Score）が提供される。

この分析結果は、脅威の構造、シナリオ、対応戦略の設計をサポートするために、本稿の以下の部分で直接適用される。

評価基準と採点フレームワーク

このMCPに基づくセキュリティ脅威分析のために選ばれた15本の論文は、トピックとの関連性だけでなく、戦略的な関連性、具体的には、実行可能な対策立案や構造的な脅威パターンの特定への貢献度によって評価された。

評価項目：4つの主要な基準

MSRスコアの計算式（MCP戦略関連性スコア）

各論文は、上記の4つの基準それぞれについて、0から3の尺度で評価された。そして、これらの評価をもとに、以下の加重式を用いてMSR（MCP Strategic Relevance）スコアを算出した：

MSRi=(Ti×0.3)+(Si×0.4)+(Ai×0.2)+(Ri×0.1)MSRi=(Ti×0.3)+(Si×0.4)+(Ai×0.2)+(Ri×0.1)

• Ti（技術的貢献）：MCP のアーキテクチャ、システム設計、実行構造に関する技術的要素を提案または実装している度合い。

• Si（セキュリティとの関連性）：ポリシー違反、コンテキストの不正操作、監査の失敗などのセキュリティリスクとの直接的な関連性。

• Ai（適用性）：提案されたコンセプトやフレームワークを実際のMCPベースのシステムに適用する際の実用性。

• Ri（戦略的関連性）：コンテンツが、T1～T4 の脅威シナリオ、対応戦略、または本ホワイトペーパーで提案されている MCP PAM アーキテクチャと整合している度合い。

MSRスコアによる分類

MSRスコアの使用目的

MSRのスコアとクラス分けは以下の通り：

• セクション2.3：文献を要約し、評価表に分類する。

• セクション3：T1～T4の脅威シナリオを定義する際に、文献引用の優先順位をつける。

• セクション4：各戦略案の実現可能性を裏付ける基礎的な証拠。

• セクション5：MCP PAMアーキテクチャの提案の実用的な根拠の検証。

文献毎の評価表（MSR）

除外論文とその理由

以下の論文は、戦略的関連性（MSR）のスコアが低かったため、中核的脅威分析から除外された：

• [5] Paul Pajo, "Smithery.ai ..."：：セキュリティよりも業種統合のユースケースにフォーカス。脅威モデリングや構造的リスク要因との関連は最小限。

• [8] Xinyi Hou, "Hardware Synergy..."：ハードウェアの統合が中心で、MCPセキュリティ・アーキテクチャや脅威分析との関連性は低い。

これらの論文は背景となる参考文献としては役立つかもしれないが、脅威シナリオの枠組みに直接含めるには不適切と判断された。

文献要約表の概要

以下の要約表は、分析対象となった全15件の論文の主要なメタデータと要約をまとめたものである。各文書は、特にT1～T4の脅威タイプの分類、戦略的対策の設計、ポリシーに基づくセキュリティフレームワークの策定において、以降のセクションで引用される場合がある。

各論文について、表は以下を含む：

• 出版日

• 著者

• タイトルとコア・トピック

• 概要

• 主要キーワード

• ソース・プラットフォーム

• 直接ダウンロードリンク

MCP関連主要15文献のサマリー表（2024年11月～2025年4月11日）

3. MCPベースのシステムにおけるセキュリティ脅威シナリオ分析

分析のアプローチ

セクション2で紹介した15の文献の分析に基づき、このホワイトペーパーのパートでは、モデル・コンテキスト・プロトコル（MCP）に基づき、AIシステムで発生する可能性のある主要なセキュリティ脅威のタイプを分類し、拡張する。各脅威カテゴリーは構造化された分解を通して探求され、実世界のシナリオに拡張される。MCPはAIモデル間のコンテキストとポリシーの交換をサポートするコアプロトコルとして設計されているが、その構造的な特徴から、以下のようなセキュリティ脅威モデルを生み出す可能性がある。

MCPにおけるセキュリティ脅威タイプの分類

主要な脅威シナリオ

シナリオ A：LLMの誤動作につながるコンテキスト・インジェクション（T1、T3）

モデルコンテキストプロトコル（MCP）は、LLMとAIエージェントが正確な実行環境で動作するようにコンテキストを構造化するように設計されている。しかし、このコンテキスト情報が検証されずに外部から注入されたり、転送中に改ざんされたりすると、LLMは攻撃者の意図に従って動作する可能性がある。これは、不正な応答、特権の悪用、システムの歪みにつながる可能性がある。プロンプトインジェクションとは異なり、これはプロトコルレイヤーの脆弱性を突く、コンテキストレベルのプロトコル改ざん攻撃である。

脅威の流れの例：

1. ユーザーからのリクエスト：「口座残高を確認したい」

2. システムは、ユーザーの許可データを含むコンテキスト・ペイロードを生成し、LLMに渡す。

3. 中間ノードまたは脆弱なエージェントに侵入した攻撃者は、コンテキスト・ペイロードを変更する。

4. LLMは変更されたコンテキストを信頼し、特権コマンドを実行する（例えば、資金移動や口座削除）。

5. システムはレスポンスの検証を怠り、不正な実行を許して特権エスカレーションやデータ漏えいを引き起こす。

※ペイロードとは：パケットやデータグラムなどのデータの送受信単位のうち、宛先などの制御情報を除いた、相手に送り届けようとしている正味のデータ本体のこと

コードの比較：正常なコンテキストと改ざんされたコンテキストのペイロードの比較

JSON// 正常な Context Payload{    "user": {        "id": "user_84321",        "role": "viewer",        "authenticated": true    },    "request": {        "action": "view_balance"    },    "policy": {        "allow": ["view_balance"],        "deny": ["transfer_funds", "delete_account"]    }}

// JSON// 攻撃者が注入した改ざんされた Context Payload{    "user": {        "id": "user_84321",        "role": "admin",   // 権限偽装        "authenticated": true    },    "request": {        "action": "transfer_funds",   // 高リスク作業に変更    },    "policy": {        "allow": ["view_balance", "transfer_funds"],        "deny": []    }}

このように改変されたコンテキストによって、システムは権限を与えられた管理者からのリクエストであると誤認し、LLMは特権コマンドを何の疑いもなく処理するようになる。

**セキュリティの内訳

• コンテキストの完全性検証の欠如

ロール、アクション、ポリシーなどの重要なコンテキスト・フィールドに、暗号化署名や検証ロジックが存在しない。

• 信頼できないソースからのポリシー・インジェクション

ポリシー定義（許可/拒否）はクライアントサイドまたは中間ノードによって生成されるため、本質的に信頼できない。

• LLMは未検証のコンテキストに基づいて実行する

LLMは、二次的な検証を行わず、入力されたコンテキストのみに基づいて意思決定を行う。

• コンテキスト生成レイヤーとポリシー実施レイヤーの分離

コンテキスト構築レイヤーとポリシー実行ロジックの分離は、オープンな攻撃ベクトルを生み出す。

シナリオB: 権限のないエージェントによる委任なりすまし (T2)

MCPベースのシステムでは、エージェント間のコラボレーションはポリシーベースの委任モデルによって管理される。しかし、委任リクエストの検証が弱い場合、あるいは委任チェーンのトラッキングが不完全な場合、攻撃者は下位エージェントを侵害し、より高い特権を持つエージェントになりすまして委任権限を盗むことができる。これは不正な権限エスカレーションにつながり、システム全体の完全性を脅かす。

脅威の流れの例：

1. エージェントAは、コア・インフラストラクチャに対する権限を持つ特権エージェントである。

2. エージェントBは、機能限定エージェントで、外部との統合や顧客向けのタスクに使用される。

3. 攻撃者はエージェントBを侵害し、あたかもエージェントAから発行されたかのように委任ペイロードを偽造する。

4. システムはfrom_agent、token、scopeなどのフィールドを検証することなく、 リクエストを受け入れる。

5. その結果、攻撃者はエージェントBを使用して、エージェントAを装って特権アクションを実行し、バウンダリ・バイパス（セキュリティ境界の迂回）を達成する。

コード例：委任なりすまし攻撃

// JSON// 正常な委任リクエスト構造{    "type": "delegation_request",    "from_agent": "agent_b",    "to_agent": "agent_a",    "scope": "read_only",    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}

// JSON// 攻撃者が改ざんした委任リクエスト{    "type": "delegation_request",    "from_agent": "agent_a",             // 偽造された出発主体    "to_agent": "agent_b",    "scope": "infrastructure_control",   // 上位権限リクエスト    "token": "eyJhbGciOiJI...TamperedToken..."  // 改ざんされた署名のないトークン}

適切な検証なしに処理された場合、この偽造されたリクエストにより、エージェントBは、システム設定の変更、ファイルの削除、ユーザーアカウントの変更など、本来エージェントAに制限されるべき危険性の高い操作を実行できるようになる。

セキュリティの内訳

• 委任リクエストの身元検証の欠如

from_agentフィールドが本当に指定された送信元から送信されたものであることを確認するための、暗号化署名または証明書メカニズムがない。

• スコープ制約の欠落

スコープフィールドはポリシーの上限に対して評価されないため、攻撃者はより広範なアクセスを要求することで特権をエスカレートさせることができる。

• 委任チェーンの追跡が不可能

システムは、委任の系統やトラストチェーンを可視化できないため、なりすましや複数レベルの委任の悪用を検知できない。

• 未署名または改ざんされたトークンの受け入れ

トークン（JWT、MACなど）は署名やタイムスタンプの検証なしで受け入れられ、悪意のある操作やリプレイ攻撃に対して脆弱になる。

シナリオC：コンテキスト環境間での実行の乖離（T3）

MCPは、複数の実行環境にわたって同じコンテキストを提供することで、ポリシーの一貫性とセキュリティの予測可能性を保証することを目的としている。しかし、現実の環境では、LLM やエージェントの設定、ローカルポリシー読み込みメカニズム、インタプリタのバージョンの違いによって、同じコンテキストが実行環境によって異なる解釈を受けるという非決定論的な動作が発生する可能性がある。このような違いは、最終的にポリシーの不整合、セキュリティの予測可能性の失敗、トラストチェーンの崩壊につながる可能性がある。

脅威の流れの例：

1. 単一のコンテキスト・ペイロードが複数のシステムに配信される。

2. 各システムは、ローカルに組み込まれたLLMやポリシー解釈エンジンを使ってコンテキストを評価する。

3. ポリシー・ロジックやポリシー・エンジンのバージョンの違いにより、あるシステムではリクエストが許可され、別のシステムではブロックされる。

4. これは、同じリクエストに対する一貫性のないポリシー実行結果を招き、組織全体の集中管理態勢を弱体化させる。

コードの例：ノード間で異なるポリシー解釈

// JSON// 伝送された文脈 (Context Payload){"user": {"id": "dev_user","role": "editor"},"request": {"action": "publish"},"context": {"project": "prod-marketing","env": "staging"}} 

# rego# Node A (ポリシー解釈: editor は publish 可能)package access default allow = false allow {  input.user.role == "editor"  input.request.action == "publish"} 

# rego# Node B (ポリシー解釈: publish は admin のみ可能)package access default allow = false allow {  input.user.role == "admin"  input.request.action == "publish"} 

全く同じコンテキストを受信しているにもかかわらず、ノードAとノードBは正反対のポリシー決定を返答し、一方はアクセスを許可し、もう一方は拒否する。これにより、ポリシーの一貫性が崩れ、予測可能性が損なわれ、システムの信頼境界を弱体化する。

セキュリティの内訳

• ローカルなポリシー評価

ポリシーはノード・レベルに分散され、独自に解釈されるため、一元的なポリシー適用とならず、見落とされる。

• 標準化されたポリシーテンプレートの欠如

Regoのポリシーはノードによって異なるため、統一されていないポリシー定義のために解釈の相違が生じる。

• 実行環境メタデータの欠落

コンテキスト・ペイロードにはランタイム・メタデータ（OS、地域、エンジン・バージョンなど）が含まれていないため、環境間で一貫性のある解釈ができない。

• ポリシーエンジンの非同期化

MCPエージェントまたはLLMランタイム間の非同期化は、トラストチェーンを弱め、同一のコンテキストに対して一貫性のないポリシー適用につながります。

シナリオD：コンテキストフローのロギングの失敗と監査の不可視化（T4）

MCP ベースのシステムでは、コンテキストはエージェント間で継続的に受け渡され、ポリシー実行フローの基礎を形成して評価される。しかし、コンテキストの流れがログに記録されないか、標準化されない形式でログに記録されるか、または意味不明な方法で暗号化されると、インシデントが発生した場合に監査トレーサビリティが事実上不可能になる。その結果、監査が可視化できなくなり、コンプライアンス違反、フォレンジック分析の妨害、セキュリティ対応の遅延といった重大なセキュリティの崩壊につながる。

脅威の流れの例：

1. ユーザーがシステム内で特定のアクションのリクエストを開始する。

2. リクエストはMCPコンテキストでラップされ、複数のエージェントとMCPサーバに渡される。

3. 転送中に、不正なコンテキストの変更や悪意のある委任が発生する。

4. MCPサーバーはイベントをログに記録するが、コンテキストID、該当エージェント、実行結果などの重要な詳細が欠落しているか、読み取り不可能な暗号化された形式で保存される。

5. 結果として、セキュリティ運用チームは、実行経路を追跡したり、どこに問題があるかを特定したりすることができない。

コード例：不完全なロギング vs構造化されたロギング

// 非標準ログサンプル (内容省略、フィールド欠落){    "event": "context_execution",    "context_id": "ctx_1132abc",    "timestamp": "2025-04-10T02:15:23Z",    "status": "executed"}

// 期待されるログ形式の例 (構造化され検証可能な形式){    "event": "context_execution",    "context_id": "ctx_1132abc",    "agent": {        "id": "agent_X7",        "signature_valid": true    },    "policy": {        "evaluated": true,        "result": "allow"    },    "request": {        "action": "delete_account",        "initiated_by": "user_0841"    },    "timestamp": "2025-04-10T02:15:23Z",    "hash": "b324f8a6c1..."}

最初の例では、技術的なイベントのみがログに記録され、ポリシーの決定や実行者は可視化されない。対照的に、2番目の例では、ポリシー適用の結果、エージェントの署名検証、監査とフォレンジック分析のための完全なコンテキストが含まれる。

セキュリティの内訳

• 構造化されていないコンテキスト・フロー・ロギング

表層レベルのイベントのみが記録され、ポリシーの適用履歴や実行パスは記録されない。

• 非標準のログフォーマット

ログの書式が統一されておらず、重要なフィールド（エージェント、ポリシー、結果など）が省略されているため、解釈の妨げになっている。

• ログの完全性を検証しない

デジタル署名やハッシュ検証がないため、改ざんされたログが検出されない。

• エンドツーエンドのログ相関がない

エージェントとMCPサーバー間で相関IDを共有しないと、1つのコンテキストリクエストの全行程を追跡することが困難になる。

シナリオ E: 論理的分離によるポリシー実行の不一致 (T2, T3)

多くのMCPベースのシステムでは、ポリシーの評価を担当するコンポーネント（例えば、Open Policy Agent）は、実際のタスクを実行するランタイム・エグゼキュータ（例えば、LLMやオーケストレータ）から分離されている。この分離は、ポリシーの決定と実行時の動作との間で不整合が発生するという重大なリスクをもたらす。ポリシーのロジックと実行エージェントが物理的または論理的に切り離されている場合、実行時の動作が強制されたポリシーに従わない可能性があり、その結果、ポリシーのバイパスや権限の不正使用につながる恐れがある。

脅威の流れの例：

1. ユーザーがMCPベースのLLMシステムにアクション要求を送信する。

2. ポリシーエンジン（OPAなど）はリクエストを評価し、拒否判定を返す。

3. しかし、ポリシーの結果は実行者に送信されないか、実行者によって無視され、代わりに、ローカルコンテキストに依存して、アクションを実行するかどうかを決定する。

4. その結果、ポリシーによって明確に拒否されているにもかかわらず、リクエストはとにかく実行される。

5. これはセキュリティ・ポリシーの回避につながり、システムを信頼できないものにしてしまう。

コード例：ポリシーの決定 vs実行時の動作

# コード スニペット# ポリシーエンジン (例: OPA で実行)package policy.access default allow = false allow {  input.user.role == "manager"  input.request.action == "delete_user"}

// JSON// Context Payload (LLM が受け取る入力){"user": {"id": "user_042","role": "analyst"},"request": {"action": "delete_user"}}

# Python# 実行エンジン内部ロジック (LLM/Agent 内部)if context["user"]["authenticated"] and context["request"]["action"] == "delete_user":    perform_deletion()

ユーザのロールが "manager "ではないので、ポリシー・エンジンは削除要求を拒否すべきであるが、ランタイム・エグゼキュータはユーザが認証されているかどうかをチェックするだけで、削除を進める。この結果、ポリシーと動作の不一致が発生します。

セキュリティの内訳

• 意思決定と実行の間に欠けているポリシー・バインディング（特定のユーザーやグループに対する、特定の権限の設定）

ポリシーの結果が実行レイヤーに確実に、あるいは即座に反映されないため、盲点が生じる。

• コンテキストのみのロジックの実行

エクゼキュータは、外部からのポリシー評価を無視して、ローカルのコンテキストを使って独自に意思決定を行う。

• ポリシーが強制適用されるランタイム実行はない

"ポリシーの承認が真であるときのみ実行が許可される "という強制的な決まり事はない。

• 「仲介者」の上書きリスク

オーケストレーターやルーターのようなミドルウェアコンポーネントは、「仲介者」として、ポリシーの結果を上書きしたり破棄したりする可能性があり、安全でない振る舞いを進行させる。

主要な構造的セキュリティ欠陥のまとめ

MCPベースのシステムで確認されたセキュリティの脅威は、孤立した脆弱性ではなく、むしろMCPアーキテクチャ全体に埋め込まれた構造的なセキュリティの弱点に起因するものである。主な欠陥は以下の通り：

これらの構造的な弱点は、MCPアーキテクチャが意図した設計に反して、状態の不一致、ポリシーの回避、不正な実行、セキュリティの予測可能性を損ねるといった、様々なセキュリティリスクを不注意の上にもたらす可能性があることを明らかにしている。

MCPアーキテクチャにおける脅威とレイヤのマッピング

的確で効果的なセキュリティ対応を可能にするため、各脅威タイプとMCPシステムの特定のアーキテクチャーレイヤーとの関係をまとめると、以下のようになる：

の基礎的な参考資料となり、どのアーキテクチャレイヤに特定の保護・制御対策が必要かを決定するのに役立つ。

脅威構造と戦略的対応の方向性のまとめ

先の分析で概説したように、MCPベースのシステムは、以下のような様々なシステマティックで広範なセキュリティ脅威に直面している：

• コンテキスト・フローにおける整合性と信頼の欠如

• 一貫性のないポリシーの解釈

• ルールに準拠しないランタイムの動作

• コンテキスト・フローにおける監査の不可視性

これらの脅威は、システムのセキュリティ実施能力、ポリシー実行の信頼性、コンプライアンス遵守態勢を直接的に損なうことにつながる。これらの脅威は、MCPフレームワーク上に構築されたAIインフラの全体的なセキュリティ保証に深刻な課題をもたらす。これらのリスクに対処するため、セクション4では、先に特定した4つの脅威タイプ（T1～T4）に基づき、技術的かつポリシー主導型のセキュリティ対策を提案する。戦略的な方向性は以下を軸とする：

• ポリシー評価と実行の不一致を除去する

• コンテキストの流れの整合性の確保

• 委任における制約とトレーサビリティの強制

• 監査機能の構造化と標準化

これらの戦略を通じて、MCPベースシステムのセキュリティ態勢と運用の安定性の両方を強化する、実用的で柔軟性のあるセキュリティ・アーキテクチャの確立を目指す。

4.セキュリティ脅威分析に基づく戦略的提言

戦略的枠組み

セクション3で特定されたセキュリティの脅威は、MCPベースの環境に合わせた3つの基本的なセキュリティ原則によって対処することができる：

• ポリシーの一貫性：

委任範囲、実行条件、監査基準を含むセキュリティポリシーは、エージェント、LLM、サーバ間で一貫して適用されなければならない。

• リアルタイム検知：

コンテキストの改ざん、ポリシーの迂回、モデルの誤動作を発生したその時に特定するため、統一された検知フレームワークが必要になる。

• 監査性：

MCPシステム内の実行フローとコンテキストの伝播は、信頼性の高い監査とフォレンジックをサポートするために、すべてのレイヤーにわたって追跡可能でなければならない。

戦略A：ポリシーの一貫性と実行時バインディング（結合）の確保

目的

この戦略は、ポリシーの評価と実行時の論理的整合性を確立し、ポリシー違反が実行段階で効果的にブロックされることを保証することを目的としている。この整合性は、ポリシー層とアクション層がしばしば切り離されるLLMやマルチエージェントシステムを含む環境では特に重要である[1][3]。

推奨事項

• ポリシーエンジン（例えばOPA - Open Policy Agent）をLLMまたはエージェントランタイムと直接接続する。実行は、ポリシーの決定が検証された後にのみ許可されるべきである。 OPAベースのフレームワークは、AI統合インフラストラクチャにおいて、プロアクティブなポリシー決定ポイント（PDP）とポリシー実施ポイント（PEP）をサポートし、すでにその有効性が証明されている[3][12]。

• ポリシーのテンプレートとバージョンを一元化されたリポジトリに保存し、定期的な更新をすべての実行ノードにプッシュする。 このアプローチは、環境間でポリシーのバージョンが一貫していないことに起因する非決定性を緩和する(T3)[4][14]。

• 実行前に、ポリシーの結果（許可/拒否）を含む署名された決定オブジェクト（ポリシー決定トークン）を生成する。実行エンジンは、有効なトークンを伴わないアクションを拒否しなければならない。 この構造は、ポリシーから実行へのバインディング（結合）**を強制し、ランタイム層のみで行われる不正な実行決定を排除する[10]。

期待される成果

• ローカル環境での誤った解釈やポリシーバージョンの違いによる意図しない実行を防ぐ

• ポリシーの意図と実行時の動作の不一致をなくす

• システム全体の一元的なポリシーベースのコントロールを強化

• 脅威シナリオC（実行の乖離）およびシナリオE（ポリシーと実行の分離）のプロアクティブな緩和を提供します。

修正される脅威の種類

• T2: 委任時のポリシー適用に一貫性がない

• T3: 全ての実行環境下での非決定論的ポリシー評価

戦略 B：コンテキストフローの整合性と改ざん防止

目的

MCPベースのシステムでは、コンテキストは実行の基盤として機能し、ポリシー評価とセキュリティ制御の両方の中心的な要素である。コンテキスト・ペイロードが改ざんされたり、送信中に偽造されたりすると、攻撃者はポリシーを迂回したり、LLMの誤動作を引き起こしたりする可能性がある。この戦略は、コンテキストの整合性を確保し、改ざんをリアルタイムで検知・防止することを目的としている。

推奨事項

• デジタル署名を導入して、各コンテキストの出所と整合性性を検証する。署名は、非対称 PKI または HMAC ベースの認証方法を使用して実装できる[2][6]。

• 各コンテキストフローについて、チェックサムまたはMerkle Treeベースの完全性ハッシュを生成する。MCPサーバはデータを受信した時点で検証する。Merkle Tree構造は、複数のコンテキストフィールドを並行して効率的かつ正確に検証することを可能にする[3][12]。

• 実行時に検証に失敗したコンテキストは、ポリシーによって自動的に拒否される。失敗した試行内容はログに記録され、管理者によるレビューのためにMCP監査システムに転送される。

• ポリシーエンジンと実行エンジンの両方が同じコンテキストを独立して検証する二重の整合性チェックを適用する。この構造は、中間エージェントやノードによる改ざんのリスクを排除する[1][10]。

期待される成果

• 破損または偽装されたコンテキストによるLLMの誤動作を防ぐ（シナリオAなど）

• 改ざんされたコンテキストに基づくポリシーバイパスや権限偽装攻撃をブロックする

• コンテキスト主導の意思決定における信頼を確立する

• 検証可能なコンテキストベースの監査ログの作成を可能にする

修正される脅威の種類

• T1:コンテキスト・インジェクションとなりすまし

• T3：文脈の歪曲による悪意のある操作

戦略C：委任管理となりすまし防止

目的

MCPシステムは、エージェント間の連携によって構築されており、多くの場合、権限の委譲を頻繁に行う必要がある。しかし、委任リクエストが十分に検証されない場合、攻撃者はエージェントになりすましたり、大雑把に定義された委任メカニズムを悪用して、権限のエスカレーションを不正に行う可能性があります。この戦略では、 明示的かつ制限的な委任チェーンを設計し、委任パスのトレーサビリティを確保することに焦点を当てる。

推奨事項

• すべての委任リクエストは、前の委任者のID、ポリシーの承認ログおよびデジタル署名で構成される、完全な委任チェーンを含むべきである。このメタデータは、OIDCベースのトークンにカプセル化することも、MCPのネイティブなコンテキスト構造に直接統合することもできる[2][10]。

• スコープまたはケイパビリティフィールドを使用して、委任権限の上限を定義する。例えば、"read-only "アクセス権を持つロールは、決して "admin "レベルでの委任を要求してはならない。これはRBACスタイルの制約[11]を反映している。

• 委任リクエストを受信すると、MCPサーバーまたはポリシーエンジンは、その要求が事前に定義された、ポリシーによって許可されたパスと一致するかどうかを検証すべきである。未登録または未承認のデリゲーションチェーンは直ちに拒否され、委任されたロールの実行は阻止されるべきである。

• 委任リクエストは、発信元のエンティティによって暗号的に署名されなければならない。RSAまたはHMAC署名を使用して、正当な委任者のみが有効な委任リクエストを発行できるようにする[6]。

期待される成果

• なりすましエージェントによる偽装された委任リクエストの発行を防ぐ

• 制御下にない権限委譲による過剰な権限エスカレーションをブロックする

• 信頼でき、追跡可能な委任チェーンを確保する。

• 下位エージェントが上位エージェントになりすましたり、上位エージェントの権限を継承しようとするT2シナリオに対する強力な防御を提供する。

修正される脅威の種類

• T2: 委任の濫用となりすましの委任リクエスト

戦略 D：構造化された監査ロギングとフォレンジック・トレーサビリティ

目的

MCPベースのシステムでセキュリティを維持するには、コンテキストの流れ、ポリシーの決定、実行結果の体系的なロギングが必要です。しかし、非標準のログフォーマットの使用、イベントの部分的な省略、エージェント間の切断されたロギングは、監査の不可視性を生み出し、インシデント発生時の根本原因分析、説明責任の追跡、規制遵守を妨げる重大な弱点となる。この戦略は、構造化されたロギングフォーマットと追跡可能なイベント相関システムを確立し、MCP環境におけるフォレンジックの準備態勢を強化し、インシデント発生後の対応を強化することを目的としている。

推奨事項

• すべてのMCP関連アクティビティは、contextid、agentid、policy_result、timestamp、execution_outcome、signature_statusを含む構造化されたJSON形式で記録されなければならない。 このフォーマットは、MCPサーバ、ポリシーエンジン、および実行レイヤ[2][12]全体に渡って、一貫して採用されなければならない。

• 各ログエントリは、チェーンベースのログの検証と順序付けを可能にするために、prev_hashやsession_idのようなフィールドとともに、SHA256ハッシュやMerkleツリー値のような暗号的な整合性チェックを含んでいなければならない[6][13]。

• 中間ノードまたはリレーエージェントを通過したイベントは、中央監査サーバーで記録されなければならない。これにより、調査中に完全なコンテキストフローパスとエージェントのトラストチェーンを再構築することが可能になる。

• ログは、既存のセキュリティ情報・イベント管理（SIEM）プラットフォームやフォレンジック・ツールにリアルタイムで供給されるべきである。

ログは柔軟な検索性をサポートし、脅威の探索やインシデントの再現のためのKQL/SQLクエリの自動生成のために設計された構造でなければならない[4]。

期待される成果

• すべてのコンテキストの遷移とエージェントとのやり取りの完全な可視化

• なりすまし、または悪意のある操作をされたリクエストのフォレンジック・トレーサビリティ

• コンプライアンスと監査準備のための強力なサポート

• T4 シナリオ（セキュリティ・インシデントの追跡と追跡の失敗）を直接的な緩和。

修正される脅威の種類

• T4: 欠落している、または検証不可能なコンテキストロギング

この戦略は、単なるロギングにとどまらず、MCPベースのシステムを透明化し、監査可能にし、フォレンジックの要求に応えるようにするために必要なコンテキスト・インテリジェンスを提供し、セキュリティチームを強化する[12][13][15]。

戦略総括表

MCPベースの脅威を軽減するための4つの重要な戦略的対策のまとめ

次の最後のセクション「5：結論と新しいセキュリティアーキテクチャの提案」では、これまで議論してきた脅威と戦略を統合し、MCPベースのAIシステムに合わせた最新のセキュリティフレームワークを提案する。

5. 結論と新しいセキュリティ・アーキテクチャの提案

包括的な分析

本ホワイトペーパーでは、最近の学術論文や技術論文15件の評価に基づき、モデルコンテキストプロトコル（MCP）上に構築されたAIシステムの構造的なセキュリティ分析を行う。コンテキストの送信、ポリシーの評価、実行制御、監査ロギングなど、複数のアーキテクチャ層にわたって、4つの中核的な脅威の出現を繰り返し観察した：

• T1:　コンテキスト・インジェクションと悪意のある操作

• T2: 委任メカニズムの悪用

• T3: 非決定論的ポリシー評価と実行結果

• T4: 監査の不可視性とフォレンジックの失敗

これらの脅威は、MCPベースのAIインフラの信頼性、説明責任およびポリシーの一貫性を損なう可能性がある。さらに、このような脆弱性を効果的に軽減するために必要なコンテキストの認識と実行時の強制力が欠如している従来のセキュリティモデルの深刻な限界が明らかになった。

既存戦略の基礎と拡張の必要性

セクション4では、MCPに関連するセキュリティ上の脅威（T1～T4）に対処するための4つの 戦略的対策を提案した。これらの戦略（コンテキストの整合性、委任制御、ポリシー実行の一貫性、監査トレーサビリティ）は、特定された脅威シナリオに合致する強力な設計原則を提供する。 
しかし、これらの戦略を現実のAI主導型インフラに一貫性を持って持続的に適用するためには、より包括的なソリューションが必要である。問題は、単にこれらの戦略が有効かどうかではなく、セキュリティ・フレームワークの結束を通じて、信頼性の高い自動的な運用が可能かどうかである。
次のような業務上の要求は、そのような枠組みの必要性を浮き彫りにしている：

• ポリシーの評価-エンフォースメントを伴う実行バインディング

• 委任チェーン追跡と範囲制御

• コンテキスト整合性検証と実行前ポリシーバインディング

• 実行とポリシー結果の構造化および署名された監査ロギング

• リスク適応型自律アクセス制御

これらの要件は、機能的なセキュリティ・コンポーネントの必要性だけでなく、これらの戦略を自動的かつ確実に編成し、実施できる総合的なシステムの必要性を強調している。このニーズに応えるため、このホワイトペーパーでは、MCP PAM（Model Context Protocol Privileged Access Control – MCP 特権アクセス管理）-MCP環境のために特別に構築されたセキュリティ・アーキテクチャ-を紹介する。

次のセクション「5.3：新しいセキュリティ・フレームワークの必要性」では、MCP 特権アクセス管理を正式に紹介し、その中核機能を定義し、脅威カテゴリT1～T4に対応付ける。

新しいセキュリティフレームワークの必要性：MCP PAM（MCP 特権アクセス管理）の提案

MCP PAMは、MCPベースのシステムで特定された主要な脅威シナリオ（T1～T4）に対処するために構築されたセキュリティアーキテクチャである。これは従来のアクセス・コントロール・ツールではなく、モデル・コンテキスト・プロトコル環境の動的で分散化された性質に合わせて特別に設計された、コンテキストを認識し、ポリシーを強化し、リスク適応型セキュリティ・プラットフォームである。

MCP PAMのコア機能

MCP PAM機能とT1-T4セキュリティ脅威のマッピング (● 直接的な軽減 | ○ 間接的な軽減)

さらに、MCP PAMは、MCP環境下における脅威に対処するために、以下の重要なセキュリティ機能を提供する：

• 予防：実行前にポリシーを検証し、改ざんやなりすましのあるコンテキストデータをブロックする。

• 検知：リアルタイムのロギングとリスク・スコアリングにより、異常の発生を検知します。

• 応答：動的なリスク評価に基づいて、ポリシーの強制適用と実行のブロックに自動的に対応します。

• 責任：構造化された監査可能な形式で、完全な実行フローを記録する。

MCP PAMは、ポリシーと実行の分断、委任トレーサビリティの欠如、コンテキストの整合性リスク、監査ログの一貫性の無さといった重要な問題を、統合化されたアーキテクチャの中で解決する。MCP PAMは、最新のAI駆動環境に最適化する目的に特化したセキュリティ制御システムである。

本ホワイトペーパーの結論とまとめ

AIシステムはますます自律的になりつつあり、その実行構造は、従来のアカウントや権限ベースのセキュリティモデルではもはや管理できない複雑さを顕著に示している。特に、モデルコンテキストプロトコル（MCP）に基づくシステムは、以下の特徴を併せ持つ：

• 実行は、ユーザーが直接入力するのではなく、エージェントとLLMによって行われる。

• ポリシー決定と実行結果は、実行前後のコンテキストによって変わる。

• 権限の委譲、プロキシ操作、APIオーケストレーションは、権限の水平的なフローを作り出す。

このようなダイナミクスは、コンテキストの改ざん、ポリシーの無視、ランタイムの不整合、監査漏れなど、従来のPAMフレームワークでは対処できない新たなセキュリティ上の課題をもたらす。

このホワイトペーパーの結論は明確である：

「AI主導のMCPベースの環境では、自律的にコンテキストベースの実行ポリシーを評価、実施、記録できる新しいMCPセキュリティ・アーキテクチャが必要であり、そのソリューションはMCP PAMである」

🚀 安全なMCPとAIエージェント運用を、今すぐAI Hubで先取り体験。

参考文献

[1] X. Hou, L. Zhang, R. Sun, and Y. Wang, “Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions,” arXiv preprint, Mar. 2025.

[2] B. Radosevich and J. Halloran, “MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits,” arXiv preprint, Apr. 2025.

[3] S. Szeider, “MCP-Solver: Integrating Language Models with Constraint Programming Systems,” arXiv preprint, Apr. 2025.

[4] A. Singh, Y. Gupta, and N. Trivedi, “A Survey of the Model Context Protocol (MCP): Standardizing Context to Enhance Large Language Models (LLMs),” Preprints.org, Apr. 2025.

[5] P. Pajo, “Smithery.ai: A Model Context Protocol for Enhanced LLM Integration and Cross-Industry Applications,” ResearchGate, Mar. 2025.

[6] Z. Chen, J. Lin, and R. Wang, “ShieldAgent: Shielding Agents via Verifiable Safety Policy Reasoning,” arXiv preprint, Mar. 2025.

[7] J. Luo, K. Hu, and M. Zhao, “Large Language Model Agent: A Survey on Methodology, Applications and Challenges,” arXiv preprint, Mar. 2025.

[8] X. Hou, R. Sun, and J. Yao, “The Next Frontier of LLM Applications: Open Ecosystems and Hardware Synergy,” arXiv preprint, Mar. 2025.

[9] Anthropic, “Introducing the Model Context Protocol,” Anthropic Technical Blog, Nov. 2024.

[10] T. South, J. Velasquez, and M. D. Kemp, “Authenticated Delegation and Authorized AI Agents,” arXiv preprint, Jan. 2025.

[11] G. A. Gabison and R. P. Xian, “Inherent and Emergent Liability Issues in LLM-Based Agentic Systems,” arXiv preprint, Apr. 2025.

[12] P. Pajo, “Model Context Protocol Servers: A Novel Paradigm for AI-Driven Workflow Automation,” ResearchGate, Mar. 2025.

[13] P. Pajo, “Accelerating AI Integration: Multi-Order Effects and Sociotechnical Implications of Standardized AI-Tool Interoperability,” ResearchGate, Mar. 2025.

[14] A. Ramachandran, “Transforming Enterprise AI Integration: Architecture, Implementation and Applications of MCP,” ResearchGate, Mar. 2025.

[15] A. Kattamuri, “Unlocking Context for Intelligent Agents: The Model Context Protocol as a Standardized Integration Framework,” IJIRSET, Mar. 2025.

[16] QueryPie, “Security Governance and Integrated PAM Strategy for AI Agents in the Age of the Model Context Protocol (MCP),” White Paper, 2025.

[17] QueryPie, “MCP PAM as the Next Step Beyond Guardrails,” White Paper, 2025.