エージェンシー企業の安全確保：MCPプロキシによる自律ツールガバナンスの設計

AIエージェントがローカルツールの実行方法を決定する際、標準的なネットワークファイアウォールはその意図を完全に把握できません。ここでは、モデルコンテキストプロトコル（MCP）のプロキシのアーキテクチャについて解説します。これは、自律エージェントの実行を監査しサンドボックス化するために構築された特殊なイン ingressポイントです。

---

エージェンシーの転換点

エンタープライズアーキテクチャは急速な非連続性の時代に入りました。大規模言語モデルはもはや要求に応じてテキストを生成するだけではなく、自律的にワークフローを調整し、生産データベースにクエリを投げ、ファイルシステムを変更し、CI/CDパイプラインをトリガーしています。この変化を可能にしているのが、AnthropicのModel Context Protocol（MCP）です。これは2024年11月に導入されたオープンソースの標準であり、Ars Technicaはこれを「AIのUSB-C」と表現しています。

MCPは、従来長らく叫ばれてきたN×M統合問題を解決しました。Protocolが存在しなかった頃、10のエージェントを20の内部ツールに接続するには200のカスタムインテグレーションポイントが必要でしたが、それぞれが独立して管理されていました。MCPはこれをJSON-RPC 2.0に基づく単一の標準化されたプロトコルに置き換えました。

リリース以降のエコシステムの成長は著しいものです。2025年12月にLinux FoundationのエージェンシーAI財団（AAIF）に寄贈された時点で、Anthropicは10,000以上の公開MCPサーバーを報告しています。2026年第2四半期には、PulseMCP、公式MCPレジストリ、Smithery、mcp.soの4つの主要レジストリで追跡されたサーバー数は約9,400に達し、四半期ごとに58％の持続的成長を示しています。GitHubリポジトリmodelcontextprotocol/serversは2026年5月までに86,000以上のスターと10,000以上のフォークを獲得しています。PythonとTypeScript SDKの合計ダウンロード数は9,700万に達しています。

この採用の軌跡は、新たなセキュリティリスクももたらしました。これまで設計者や導入企業のチームは、そのリスクを完全に予見していませんでした。

---

プロトコルのセキュリティアーキテクチャと省略点

MCPはクライアント-サーバーモデルで動作し、3つの参加者役割があります：

MCPホスト/クライアントは、AIモデルをホストするアプリケーション環境です。エンタープライズのオーケストレーションエンジン、Claude Desktop、CursorやWindsurfのようなAI搭載IDEなどです。

MCPサーバーは、外部システム（GitHub、Slack、ローカルファイルシステム、SQLデータベース）をラップし、標準化された機能を公開します。

プロトコル層は、クライアントとサーバー間でJSON-RPC 2.0メッセージを伝送します。主な通信手段は、stdio（ローカルプロセス間通信）とStreamable HTTP（リモート接続用）です。

MCPを通じて、エージェントは以下の3つのコアプリプリミティブとやり取りします：

• Resources（アプリ制御）：ログファイルやデータベーススキーマなどの読み取り専用のコンテキストデータ。副作用はありません。
• Prompts（ユーザ制御）：LLMのツールとのやり取りを誘導する再利用可能なテンプレート。
• Tools（モデル制御）：エージェントが呼び出して実行できる関数。例：execute_sql、push_code、restart_server。

Toolsプリミティブはセキュリティリスクの集中点です。ローカルマシンや本番サブネット上で動作するMCPサーバーは、LLMの非決定性出力に基づき任意のコードを実行可能です。標準的なネットワークセキュリティは、正当なHTTP接続に乗るJSONデータを観察しますが、エージェントがレポート用にテーブルをクエリしているのか、幻覚命令によってテーブルをドロップしているのかを区別できません。

このギャップは理論的な問題ではありません。NSAの人工知能セキュリティセンターは、2026年5月のCybersecurity Information Sheet（U/OO/6030316-26）で次のように述べています：MCPの急速な普及は、そのセキュリティモデルの開発を追い越しています。これは初期のWebプロトコルと似ています。CSIは、MCPの設計の根本的な問題を指摘しています。すなわち、従来クライアントがサーバーからデータを要求するやり取りのパターンを逆転させている点です。MCPはしばしば、サーバーがクライアントのためにクエリやアクションを実行することを期待しています。この逆転は、初期の展開では追跡が困難な攻撃経路を生み出します。

NSAの具体的な指摘は次の通りです： - MCPはセッションと検証可能なアイデンティティのマッピングを定義していません。 - 認証はオプションであり、基本仕様では必須ではありません。 - ロールベースアクセス制御はトランスポートレベルのプロトコルには含まれていません。

このガイダンスの要約は次の通りです：”MCP自体は、これらのセキュリティ原則をプロトコルレベルで強制できません。”

---

実際の脅威の状況

MCPプロキシが守るべき脆弱性の体系的分類を理解することが重要です。

プロンプトインジェクションとツールの毒性

OWASPは、2025年版のLLMアプリケーションのトップ10で、プロンプトインジェクションを最も危険な脅威の一つに挙げています。MCPのアーキテクチャはこのリスクを増幅します。ツールの毒性は、攻撃者がユーザ入力に悪意のある内容を注入するのではなく、ツール定義のメタデータに隠された命令を埋め込むことにあります。エージェントがtools/listを通じて利用可能なツールをリクエストすると、サーバーはツール名と説明を返します。これらはモデルのコンテキストに入り、攻撃者がそのメタデータを操作することで、セッションごとにモデルの挙動に影響を与えることが可能です。

Microsoftの開発者ブログは、この仕組みを正確に説明しています。ツールのメタデータに悪意のある命令が埋め込まれていると、ユーザには見えませんが、AIモデルには解釈される可能性があります。特に、ホスティングサーバシナリオでは、ツール定義の変更が静かに行われるため、非常に危険です。

MCPToxベンチマークは、20の代表的なLLMエージェントと45の実世界のMCPサーバーを対象に、353の実在ツールを用いて評価しました。結果は驚くべきもので、o1-miniモデルはツール毒性攻撃に対して72.8％の成功率を示しました。より高性能なモデルほど脆弱性が高くなる傾向にあります。Claude 3.7-Sonnetは、最も拒否率が高く、3％未満でした。

Rug Pulls（ラグプル）

ラグプルは、ツール毒性の脅威をさらに悪化させます。MCPサーバーはインストール時には正当な動作を示し、初期レビューを通過しますが、その後、ツール定義が静かに更新され、悪意のある命令が挿入されることがあります。2025年9月のPostmark MCP事件は、これを明確に示した例です。攻撃者は正当なPostmark MCPリポジトリをクローンし、ほぼ同一のnpmパッケージを公開し、信頼を築くために15バージョンまで正当な動作を維持した後、1行の隠しコードを挿入して、すべての送信メールを攻撃者のアドレスに無断でコピーしました。ユーザには何も変化がわかりませんでした。

CVE-2025-54136（CurXecute）は、Check Pointによって発見され、設定ファイルに対しても同じパターンが適用されました。承認済みのキー名を信頼し、コマンド内容を無視して実行される脆弱性です。

混乱した代理人攻撃（Confused Deputy Attacks）

MCPサーバーは、エージェントによるアクションを実行しますが、その権限はサーバー自体に付与されたものです。エージェントのアイデンティティを細かくマッピングするプロキシがなければ、最小権限の原則は守れません。侵害されたサーバーは、エージェントが本来アクセスすべきでないシステムに不正にアクセスできる可能性があります。OAuth 2.1は、トークンを特定の対象やスコープに結びつけることで一部対策していますが、多くの展開では正しく実装されていません。

重要なCVE：サプライチェーン攻撃の実例

2025年の2つのCVEは、理論を具体的な事例に落とし込みました。

CVE-2025-6514（CVSS 9.6）は、JFrogのセキュリティ研究によって発見されました。mcp-remoteというプロキシツールに脆弱性があり、悪意のあるサーバに接続すると、authorization_endpoint URLがシェルに渡され、PowerShellやLinuxの任意のコマンドを実行される可能性がありました。これにより、実世界での完全リモートコード実行が初めて証明されました。対象バージョンは0.0.5から0.1.15で、0.1.16で修正されました。

CVE-2025-49596（CVSS 9.4）は、MCP InspectorのUIに関する脆弱性です。ローカルホスト上で動作するUIに認証がなく、CSRF攻撃により悪意のあるコマンドを注入される可能性がありました。バージョン0.14.1で修正されました。

AnthropicのFilesystem MCP Serverには、さらに2つのCVEが報告されています： - CVE-2025-53110（CVSS 8.4）：シンボリックリンクのバイパス - CVE-2025-53109（CVSS 7.3）：ディレクトリの範囲外アクセス

2026年のセキュリティ監査では、公開MCPサーバーの25％が認証を行っておらず、53％が長期有効なAPIキーやパーソナルアクセストークンを使用していることが判明しています。NSAのCSIもこれを裏付けており、オプションの認証は、現状稼働中のサーバーがエージェントからの接続を許可していることを示しています。

---

stdioトランスポートのブラックボックス性

ローカル開発環境では、MCPはstdioトランスポートに大きく依存しています。これにより、AIモデルとローカルマシン間の通信が記録されません。サプライチェーン攻撃により、オープンソースのMCPサーバーが侵害されると、ホスト上で何が指示されているのかを把握できなくなります。JFrog Security Researchが詳細に分析したShai-Hulud wormは、これを悪用した例です。感染したパッケージは開発者のトークンを盗み、他のパッケージに自動的に感染を広げました。

---

標準的なセキュリティコントロールの限界

一般的なAPIゲートウェイは、認証トークンの検証やレート制限を行いますが、AI特有の攻撃ベクトルには無力です。攻撃の全表面積は、ツール呼び出しのHTTPヘッダや認証トークンではなく、そのセマンティックペイロードにあります。

例として、データベース操作を実行しようとするエージェントのリクエストを考えます：

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "execute_sql",
    "arguments": {
      "query": "DROP TABLE production_users CASCADE",
      "database": "primary_db"
    }
  },
  "id": 84
}

WAFは、HTTPヘッダやOAuthトークンが有効なため、このリクエストを検査せずに通過させます。脅威はarguments.queryの中にあり、従来のファイアウォールにはその内容を評価する仕組みがありません。

SC Mediaの2026年のアイデンティティセキュリティ分析は、次のように指摘しています： - ゼロトラストプログラムはエージェントのアイデンティティは検証しますが、伝えられる内容は検証しません。 - すべてのツール記述やAPIレスポンス、プロンプトは、パーミッションを通過した後は暗黙的に信頼されます。これはゼロトラストではありません。境界の外側にAIの穴があるモデルです。

---

MCPプロキシの設計

MCPプロキシは、MCPクライアントとサーバーの間の特殊な仲介役として機能します。JSON-RPC接続を終了し、ペイロードを意味的に検査し、ポリシーベースのガバナンスを適用します。これにより、自律エージェントとツール間のやり取りにゼロトラストの原則を拡張します。

研究は、いくつかのアーキテクチャアプローチに収束しています。2026年の論文で提案されたZT-MCPフレームワークは、能力ベースのアクセス制御モデル（CapBAC）を導入し、4つの展開可能なエンフォースメントコンポーネントを備えています。MCP-Guardは、多段階のディフェンスインデプスフレームワークを提案し、最初の静的スキャンとセマンティック評価を組み合わせています。TrueFoundry MCP Gateway、Portkey、Petaなどの商用プラットフォームも、プロキシパターンのバリエーションを実装しています。

本番用のMCPプロキシアーキテクチャは、5つのコアコンポーネントから構成されます。

1. プロトコル解析とインターセプション層

プロキシは、基盤となるトランスポートをインターセプトします。ローカルのstdioストリームを構造化されたHTTPトラフィックに変換し、可視化を可能にします。また、Streamable HTTPのリバースプロキシとしても機能します。JSON-RPC 2.0ペイロードをリアルタイムで解析し、リクエストされたメソッド（例：tools/call）とそのパラメータを抽出します。これにより、例のarguments.queryフィールドが可視化・検査可能になります。

この層の実用的な利点は、stdio、SSE、HTTPトランスポート間のプロトコル変換を集中化し、従来見えなかったローカル接続を監査可能にする点です。

2. セマンティック監査エンジン

ペイロードが解析されたら、その引数をセマンティック監査エンジンにルーティングします。実運用では、決定論的ヒューリスティクス（ASTパース、SQLパターンマッチング、シェルメタ文字検出）と軽量分類モデルを組み合わせて意図を評価します。エンジンは、ツール呼び出しのペイロードを企業のガードレールに照らして評価します。

例のDROP TABLEでは、パターンマッチング層が破壊的なDDL文を検出します。より曖昧なケースでは、force_overrideのような操作を試みるエージェントの呼び出し履歴やツール名、引数値を評価し、リスク分類を行います。

監査エンジンは、リクエストがサーバーに到達する前にJSON-RPCエラーを返し、インターセプトイベントをSIEMに記録します。

設計上の制約もあります。2025年11月25日のMCP仕様は、OAuth 2.1をHTTPトランスポートに必須としていますが、ツール定義の署名機能は標準装備されていません。Bhattらの論文で提案されたETDI（Enhanced Tool Definition Interface）は、OAuth強化と暗号チェックを用いたプロトコルレベルのアプローチですが、2026年半ば現在、ドラフト段階です。ツールの完全性を確保するには、プロキシ層での実装固有のコントロールが必要です。

3. アイデンティティマッピングとポリシー適用（RBAC）

プロキシは、OAuth 2.1トークンをMCPサーバー内の特定ツールにマッピングします。2025年11月の仕様改訂により、OAuth 2.1とPKCE（S256）がすべてのHTTPリモート接続に必須となっています。プロキシは、これらのトークンを検証し、アクセス制御ポリシーに従って適用します。

細粒度のRBACにより、読み取り専用のエージェントはlist_filesを呼び出せますが、write_fileやexecute_commandは拒否されます。特定のデプロイメントエージェントはexecute_pipeline権限を持ちます。

重要な点は、2025年6月の仕様改訂で、クライアントから受け取ったアクセス・トークンをアップストリームAPIに渡すことが禁止されたことです。これにより、誤用された場合の代理人攻撃を防ぎます。

4. ヒューマン・イン・ザ・ループ（HITL）サーキットブレーカー

高リスクな操作には自動化だけでは不十分です。MCP仕様は、「信頼と安全のために、常に人間が関与し、ツール呼び出しを拒否できるべき」と明記しています。OWASP Top 10（2025）も、重要な操作には人間の承認を推奨しています。

プロキシは、Tier 1操作のサーキットブレーカーとして機能します。リクエストは一時停止され、レビューキューに送られます。人間が承認すれば次に進み、拒否すればエラーを返します。これにより、LLMは再評価を促されます。

サンプルパターンは、サーバがクライアント側の介入を要求できる仕組みを提供しています。プロキシはこれを一元化し、すべてのサーバに適用します。

5. エージェンシーのレート制御とループ検出

エージェントは、誤った入力やエラーによりループに入りやすいです。これを放置すると、内部ツールやクラウドAPIのコスト増大、DoS攻撃のリスクとなります。OWASP Top 10（2025）のLLM10に該当し、レート制限やサーキットブレーカーの導入が推奨されます。

プロキシは、特定ツールのトークンバケットレート制御や、呼び出し頻度・エラー・引数の変動を分析し、ループを検出します。検出時は、LLMに対してエラーを返し、ループを中断させます。

---

認証層：OAuth 2.1が解決し、解決しない問題

2025年3月の改訂で、OAuth 2.1がリモートサーバ認証の標準となりました。6月の改訂では、MCPサーバーはRFC 8707のResource Serverとして定義され、RFC 9728のメタデータも必須化されました。11月の改訂では、PKCEがすべてのパブリッククライアントに必須となり、クライアントIDメタデータも標準化されました。

しかし、2026年のセキュリティ監査では、公開MCPサーバーの53％が長期有効なAPIキーを使用し続けていることが判明しています。OAuthは、接続者のアイデンティティとスコープを証明しますが、エージェントが呼び出すツールの正当性や、ツール定義の改変を検知しません。これらのギャップを埋めるには、プロキシ側でのツールスキーマのバージョニングやハッシュ化、異常検知が必要です。

---

サプライチェーンの強化：第三の防衛線

プロキシは、実行時の動作を制御しますが、その前段階の入力も管理すべきです。MCPのパッケージエコシステムは、オープンソースと同様のリスクを持ち、広範なシステムアクセスを持つAIエージェントのコード実行を伴います。2025年9月のPostmark MCP事件は、クローンパッケージが静かにメールトラフィックを抜き取った例です。

実用的な対策は次の通りです：

• 暗号化によるサーバー検証：プロキシは、承認済みツールの暗号署名を検証し、内部レジストリと照合します。ETDIはこれをプロトコルレベルで実現します。
• バージョンピンニングとスキーマ再検証：ツールスキーマはインストール時に固定し、新規セッションごとに再検証します。ミスマッチは人間のレビューをトリガーします。
• プライベートMCPサーバーの運用：NSAは、プライベートまたは敏感なデータを扱う場合は、外部サービスではなくローカルで運用することを推奨します。
• ネームスペース制御：パッケージ名のタイポスクワッティングは攻撃手法として知られています。プロキシは承認済みサーバーのリストを管理します。

---

集中監査ログ：SIEMにエージェントの行動を可視化

MCP仕様は基本的なログ記録を示すだけで、詳細な監査は個別実装に委ねられています。NSAのCSIは、ログ不足を最も多い問題の一つと指摘しています。

すべてのプロキシインタラクション（initializeハンドシェイク、tools/call実行、resources/readリクエスト、拒否された呼び出し、HITL一時停止、レートリミットイベント）は、テレメトリとしてストリーミングされるべきです。JSON-RPC 2.0は従来のHTTPアクセスログやsyslogとは異なるため、適切なインジェストルールの設計が必要です。OWASP Top 10は、十分なログ記録の欠如を第9位のリスクとしています。

SOCチームは、エージェントの挙動を検知するルールを作成すべきです。例：複数ツールでの連続失敗、引数パターンの変化、低権限から高権限ツールへの呼び出しなどです。NSAは、MCP監査ログをエンタープライズのアイデンティティシステムと連携させ、すべての行動を特定の認証済みアイデンティティに紐付けることを推奨しています。

---

ベストプラクティス：層状ガバナンスモデル

MCPプロキシの導入は、基本的なコントロールです。効果的なガバナンスには、より広範な層状モデルの一部として位置付ける必要があります。

• 入力スキーマの厳格な検証：プロキシは、ツールスキーマ定義を中央集権的に検証します。シェルメタ文字や型の不一致、予期しないパラメータキーを拒否します。これにより、意味的監査層に到達する前にインジェクションを防ぎます。
• MCPサーバーの実行環境のサンドボックス化：DockerやKubernetesを用い、リソース制限や最小権限を設定します。プロキシのレート制御も併用します。
• マイクロエージェントアーキテクチャの採用：広範なツールアクセスを避け、必要最小限の権限を持つエージェントを設計します。例：ドキュメントエージェントはread_fileとgit_commitのみ、デプロイメントエージェントはexecute_pipelineのみ。
• データ分類ゾーンとの整合性：公開ツールと敏感データ用ツールを分離し、RBACに反映させます。
• MCPツールの審査：高リスクツールは、コード監査やセキュリティレビューを経て導入します。資格情報を持つサーバーは、単一障害点となるため、厳格に管理します。

---

結論

Model Context Protocolは、AIモデルとエンタープライズインフラの連携障壁を排除しました。リソース、プロンプト、ツールのユニバーサルアダプタとして、受動的なAIアシスタントから能動的な自律エージェントへの移行を促進しています。2026年中には、公開サーバー10,000以上とSDKの月間ダウンロード97百万を超えました。

この接続性は、重大なセキュリティ義務も伴います。NSAの2026年5月のガイダンスやOWASPの分類、CVEs、サプライチェーン攻撃の事例は、標準的なネットワーク防御だけでは、MCPが露出する意味的攻撃面を守れないことを明確にしています。プロトコル自体は、アイデンティティを強制せず、すべてのトランスポートで認証を義務付けず、ツール定義の完全性検証機能も備えていません。

MCPプロキシは、これらのギャップをプロトコル境界で埋めます。リアルタイムのJSON-RPC解析、意味的ペイロード検査、OAuth 2.1に基づくアイデンティティマッピング、ヒューマン・イン・ザ・ループのサーキットブレーカー、エージェントのレート制御を通じて、エージェントとツール間のやり取りにゼロトラストを実現します。サプライチェーン管理、コンテナ化された実行環境、SIEMと連携した監査テレメトリとともに、これらは、エンタープライズ規模での自律マルチエージェントシステムの安全な展開を可能にします。

MCPの急速な採用に伴うセキュリティ負債は実在し、記録されています。これに対処するツール群は、プロキシフレームワーク、RBACモデル、暗号化ツール検証提案などとともに進化しています。安全にエージェントAIを運用できる組織は、MCPガバナンスを未来の課題とせず、今すぐにでも本番運用の前提とすべきです。

---

チェンジログ

#	セクション	変更内容	種類
1	はじめに	MCPのN×M統合問題による”200のカスタムポイント”解決の主張を削除し、著者の解釈として再構成。導入サーバ数の実績（Anthropic、2025年12月）、4つのレジストリの追跡サーバ数（2026年第2四半期）、SDKの月間ダウンロード数（9700万）を追加。	出典付きデータに拡充
2	プロトコルのセクション	2025年11月の仕様改訂（PKCE S256必須、RFC 9728必須）を正確に記述。stdioトランスポートは仕様上OAuthを必須としない点を削除。	正確化
3	脅威の状況	CVE-2025-6514（JFrog/mcp-remote、43万+ダウンロード）、CVE-2025-49596（MCP InspectorのCSRF/RCE）、CVE-2025-53110、CVE-2025-53109（Anthropic Filesystem MCP Server）を新たに追加。実例に基づく詳細な攻撃事例を記載。	具体的な事例として追加（出典付き）
4	脅威の状況	MCPToxベンチマークの結果を追加：o1-miniは72.8％の攻撃成功率、Claude 3.7-Sonnetは拒否率3％未満に。攻撃リスクの定量的評価に置き換え。	正確化・拡充
5	脅威の状況	Postmark MCPラグプル事件（2025年9月）、LiteLLM/TeamPCPのサプライチェーン攻撃、Shai-Hulud wormの事例を追加。実例に基づき、攻撃パターンを具体化。	具体的な事例として追加（出典付き）
6	NSAのガイダンス	NSAのAISC Cybersecurity Information Sheet（2026年5月）を全体に追加し、主要な情報源とした。	出典付きで追加
7	OWASPの分類	OWASP Top 10 for LLM Applications 2025のカテゴリ（LLM01、LLM06、LLM10）を具体的に記載。OWASP MCP Top 10（2025）も追加。	出典付きで拡充
8	セマンティック監査エンジン	ETDI（Enhanced Tool Definition Interface）がドラフト段階であり、標準化されていない点を明記。暗号化検証は標準機能ではなく、現状は実装固有のコントロールが必要と記述。	正確化
9	認証層	OAuth 2.1の仕様改訂（2025年3月、6月、11月）を詳細に記述。RBACは仕様に含まれず、アプリ層で実装すべきと明示。公開サーバーの認証不備の実態も追加。	出典付きで追加
10	産業用IIoTのユースケース	NVIDIA Omniverseや産業ミラーリングの記述を削除。未検証の技術的記述を排除し、設計パターンに基づくアーキテクチャに置き換え。	不支持のため削除
11	ベストプラクティス	既存の5つの原則を維持し、NSA CSIの推奨事項（データ分類ゾーン、プライベート運用、サーバー審査）を追加。	出典付きで拡充