7月29日、InfoQが「Securing MCP in Production: Defense-in-Depth Beyond the Gateway」と題した記事を公開した。この記事では、本番環境におけるMCP（Model Context Protocol）の多層防御アーキテクチャについて詳しく紹介されている。

ゲートウェイだけでは足りない

MCP（Model Context Protocol）は、AIエージェントがツールやデータソースと通信するための標準プロトコルだ。AIエージェント基盤の統合レイヤーとしてその採用が進む一方、セキュリティの整備は追いついていない。2026年最初の60日間で、MCPデプロイメントに対して30件以上のCVEが報告された。Adversa AIが500以上のMCPサーバーをスキャンしたところ、38%がクリティカルなエンドポイントに認証なし、43%がコマンド実行の脆弱性ありという結果だった。

多くのチームが最初に取る対策は「ゲートウェイを前段に置く」ことだ。認証・認可・監査をそこに集約するアプローチは合理的だが、ゲートウェイは1つの強制ポイントに過ぎない。ツールハンドラーが引数を安全に処理するかどうか、管理コンソールが適切に保護されているか、MCPサーバーが過剰な権限で外部に接続していないか——これらはゲートウェイでは制御できない。

筆者（元記事著者）のチームはこの問題を4つの制御レイヤーとして整理した。

4つの制御レイヤー

各レイヤーには「最も早い信頼できる強制ポイント」が存在し、それぞれ異なる担当チームと制御手段を持つ。ゲートウェイが関与できるのは4レイヤーのうち2つ、しかも部分的に過ぎない。

Layer 1 が最重要：ツール実行のコマンドインジェクション

直近30件のCVEのうち13件がこのパターン——ユーザー制御の入力がシェルや動的インタープリターに到達している。CVE-2026-2130（mcp-maigret）、CVE-2026-2178（xcode-mcp-server）、CVE-2026-2131（HarmonyOS-mcp-server）はいずれもツールパラメーターをexec()に渡していた。

問題の根本はMCPのトラストモデルにある。ツール引数はJSON Schemaで型定義されているが、そのスキーマは値がシェル実行に対して安全かどうかについては無言だ。

修正は単純だが徹底が必要だ：

// NG: 文字列補間でシェルコマンドを組み立てる
exec(`docker run maigret ${username}`);
// usernameが "; rm -rf /" だとセミコロンがシェルに解釈される

// OK: 配列でコマンドと引数を分離する
execFile('docker', ['run', 'maigret', username]);
// メタ文字はリテラル値として渡されるのでシェル解釈されない

コードレビューのチェックリストより確実なのがCIゲートだ。以下のSemgrep ルールを使えば、ツールハンドラーからシェルインタープリターへの危険なパスをビルド時点で検出できる：

rules:
  - id: mcp-unsafe-exec-js
    languages: [javascript, typescript]
    severity: ERROR
    message: >
      MCPツールハンドラーがシェルインタープリターにパラメーターを渡しています。
      配列引数でexecFileまたはspawnを使用してください。
    pattern-either:
      - pattern: exec(`...${$PARAM}...`)
      - pattern: exec($CMD + $PARAM)
      - pattern: eval($PARAM)
  - id: mcp-unsafe-exec-py
    languages: [python]
    severity: ERROR
    pattern-either:
      - pattern: subprocess.run(..., shell=True, ...)
      - pattern: os.system($CMD)
      - pattern: eval($PARAM)

Layer 2：管理インフラの見落とし

著者のチームが検査したところ、テスト用ハーネスが認証なしで内部ネットワークにリスニングしていた。デフォルトがオープンだったからだ。

CVE-2026-23744（MCPJam Inspector）は未認証のエンドポイントが0.0.0.0でリスニングし、任意のMCPサーバーのインストールを可能にしていた。CVE-2026-23523は悪意あるディープリンクを介してクライアントアプリケーションを操作できる問題で、いずれも管理インフラ側の設計上の欠陥に起因する。

開発環境は本番より広いアクセス権（ソースコード、シークレット、ビルドシステム、デプロイ認証情報）を持つことが多い。管理プレーンを侵害されると、攻撃者は単一のツール呼び出し以上の権限を手にする。対策の基本は全管理エンドポイントへの認証必須化とネットワーク分離だ。開発用ツールであってもインターネットや社内ネットワークに露出させないことが前提となる。ローカルバインド（127.0.0.1）の徹底と、ファイアウォールルールによるアクセス制限を組み合わせることで、このレイヤーの攻撃面は大幅に縮小できる。

Layer 3：アウトバウンドのSSRF

2026年3月10日にMicrosoftが修正したCVE-2026-26118（CVSS 8.8）は、Azure MCPサーバーのSSRF（サーバーサイドリクエストフォージェリ）脆弱性がマネージドIDトークンを漏洩させるものだった。インバウンドの認証だけでは不十分であることを端的に示した事例だ。

攻撃者は細工したリクエストをMCPサーバーに送ることで、サーバーを踏み台にしてクラウドのメタデータエンドポイントへアクセスし、IAMトークンを窃取できる。MCPサーバーがアウトバウンド通信を制限していなければ、インバウンドの認証が堅牢であっても内部リソースへの横断的アクセスを許してしまう。

対策はネットワーク層のEgressアローリスト（許可済みの宛先のみに通信を絞る設定）と、ツールの用途ごとにスコープを絞ったトークンの組み合わせだ。クラウド環境ではマネージドIDに付与する権限を最小化し、メタデータエンドポイント（169.254.169.254など）へのアクセスをネットワークポリシーで明示的にブロックすることが有効な緩和策となる。

Layer 4：ツール定義のドリフトと「rug-pull」

登録時に承認されたツール定義が後から変更される「rug-pull」攻撃は、ゲートウェイには検出できない。攻撃者がMCPサーバーのツール定義を差し替えることで、エージェントは意図しない動作（機密データの送信や権限昇格につながる操作）を実行させられる可能性がある。タイポスクワッティングによる悪意あるMCPサーバーへの誘導も同様のリスクを持つ。

対策はマニフェストのSHA-256ピン留めと差分ベースのレビューだ。ツール定義を初回登録時にハッシュとして記録し、実行前に照合することで定義の改ざんを検出できる。「承認/拒否」の二値ゲートではなく、変更差分のレビューを運用モデルとして持つことが重要になる。ツール定義の変更をGitのプルリクエストと同等に扱い、承認フローを経ずに本番反映されない仕組みを構築することが現実的なアプローチだ。

仕様の整備を待てない

2026年3月9日に公開されたMCPロードマップはエンタープライズ対応を優先領域として挙げているが、4領域の中で「最も定義が進んでいない」と明記されている。4月のMCP Dev Summitではすでに本番アーキテクチャが共有されており、仕様の成熟を待たずに本番運用が先行している状況だ。

CoSAI（Coalition for Secure AI）は、AIシステムのセキュリティに取り組む業界横断の団体で、Googleやマイクロソフトなど主要テック企業が参加している。同団体の共有責任フレームワークが示すように、これらの強制ポイントは、MCPサーバーを構築・ホスト・運用するチームとベンダーに責任を分散させる。仕様は追いついてくる。だが本番環境は待てない。

詳細はSecuring MCP in Production: Defense-in-Depth Beyond the Gatewayを参照していただきたい。