Token Securityが「MCPwned: MCP RCE Vulnerability Leads to Azure Takeover」という研究テーマをRSAC 2026で発表予定であることが、同社の公開プロフィール更新で示されている。RSAC 2026（2026年3月23日-26日、サンフランシスコ）を前に、Model Context Protocol（MCP）の攻撃面を、プロトコル層・実装層・クラウド権限層の3層で整理する必要がある。本稿は公開情報を基に、Azure上のRCE連鎖とEntra侵害シナリオを技術的に分解し、企業向けAIエージェント統合で採るべき防御設計を提示する。

MCPの本質は「接続標準化」であり、攻撃面も標準化される

MCPは、LLMアプリケーションと外部ツール・データソースの接続を統一するためのオープン仕様として2024年11月に公開され、以後、仕様拡張と実装が進んでいる。標準化の価値は高いが、同時に「どの実装でも繰り返し成立し得る失敗パターン」が生まれる点がセキュリティ上の要点である。とくに、ツール呼び出し時の権限制御、認可サーバー分離、トークンのスコープ制約が弱い実装では、MCP接続自体が横断的な攻撃面になる。

2025-06-18版のMCP仕様では、OAuth 2.1ベース認可、Resource Indicators（RFC 8707）、Protected Resource Metadata（RFC 9728）など、権限境界を明確化する要素が整理されている。言い換えると、仕様準拠レベルが低い実装ほど、プロンプト注入やツール悪用から高権限操作へ遷移しやすい。

MCPwnedが示唆するAzure RCE連鎖: ツール実行からクラウド制御面へ

現時点で公開されているのは研究発表タイトルと概要レベルであり、完全な技術詳細は未公表である。ただし、タイトルが示す「MCP RCE → Azure Takeover」という流れは、既知のクラウド攻撃連鎖と整合する。典型的には、(1) MCP経由で到達可能なツールにコマンド実行系の欠陥がある、(2) 実行コンテキストからAzure Instance Metadata Service（IMDS）へアクセスしトークン取得を試行する、(3) 過剰権限のマネージドIDやサービスプリンシパルを起点に制御プレーン操作へ拡大する、という段階を踏む。

この連鎖の成立条件は「LLM層の脆弱性」単体ではなく、実行基盤・ネットワーク到達性・IAM設計の複合不備である。したがってRCE対策はアプリ修正だけで閉じず、IMDS到達制御、権限最小化、監査ログ相関まで含める必要がある。

Entra侵害リスクは認証突破より「正規トークン悪用」で拡大する

エンタープライズ環境では、AIエージェント連携にGraph APIや内部SaaS APIの委任権限が付与される。ここで重要なのは、攻撃者が常に認証情報を窃取する必要はない点である。すでに発行済みトークン、または過剰同意済みアプリ権限が残っていれば、正規経路としてEntra配下の資産へ横移動できる。近年のアイデンティティ防御でも、資格情報防御に加えてトークン保護・条件付きアクセス・ワークロードID管理が強調される背景はここにある。

AIエージェント導入時の実務論点は、ユーザーIDとワークロードIDを同列で監査対象に置くことである。とくにMCPサーバーがバックエンド連携のハブになる構成では、単一サーバー侵害が複数SaaSの統合権限に波及しやすい。

LLMサプライチェーンとしてのMCP: 依存先の信頼境界を再定義する

MCP普及は、組織内で「どのツールをエージェントに接続するか」という選定を高速化する。一方で、ツール定義、サードパーティMCPサーバー、認証ブローカー、プロンプトテンプレートが新しいサプライチェーン要素になる。OWASPのLLMセキュリティ指針でも、プロンプト注入、過剰権限、プラグイン/ツール連携リスクは継続的な重点項目である。

企業が最初に実施すべきは、MCP接続を「便利機能」ではなく「特権統合面」として扱う設計原則への転換である。具体的には、接続前審査（権限・データ分類・実行権限）、接続中統制（allowlist、出力検証、署名付きツール定義）、接続後監視（トークン利用異常、操作列の検知）を標準運用に組み込む必要がある。

防御設計チェックリスト: エンタープライズAIエージェント統合の最小要件

実装優先順位としては、第一にMCPサーバーごとの権限分離と短寿命トークン化、第二にAzure実行基盤でのIMDS到達制御と最小RBAC、第三にEntra側でワークロードIDの継続レビューを置くのが実践的である。加えて、セッション単位で「どのプロンプトがどのツール呼び出しを誘発したか」を追跡できる監査証跡を残すことで、インシデント時の封じ込め速度が大きく改善する。

MCPwnedの詳細公開はRSAC 2026セッション本編待ちであるが、企業側は発表待ちの受動姿勢を取るべきではない。公開済み仕様とクラウド運用原則だけでも、攻撃連鎖の大半は予見できる。2026年3月時点の最適解は、MCPを禁止することではなく、ゼロトラスト型の接続制御として再設計することである。

FAQ

MCPを使うと必ず危険になるのか

必ずしも危険になるわけではない。問題はMCPそのものより、接続先ツールの実行権限と認可境界の設計不備である。仕様準拠と最小権限運用ができていれば、リスクは大幅に低減できる。

Azure RCEはMCP特有の脆弱性なのか

MCP特有というより、MCPが「実行可能ツールへの到達面」を広げることで既存のRCE連鎖が成立しやすくなる、という理解が正確である。クラウド実行基盤の基本対策は従来どおり有効である。

Entra侵害を防ぐ最優先施策は何か

ワークロードIDを含む権限棚卸しと、トークン悪用を前提にした監視設計が最優先である。ユーザー認証強化だけでは、サーバー側トークン悪用に十分対応できない。

RSAC 2026で確認すべき論点は何か

再現条件、影響範囲、必要権限、そして緩和策の実装コストである。PoCの派手さより、企業システムに適用可能な防御要件へ翻訳できるかが評価軸になる。

参考文献