シャドーMCP：SOCがまだ監視していないAIエージェントの死角

2025年10月、私たちはAgentic AIとMCPサーバーの連携について前向きな記事を書いた。そのアーキテクチャ自体はいまも有効だ。変わったのは、この11か月でその周囲のセキュリティ状況が大きく動いたこと、そして多くのSOCがそれに追いついていないことである。

MCP(Model Context Protocol)は、Cursor、Claude Desktop、VS Code、そして各種エージェントフレームワークといったAIクライアントが、データベース、Gitリポジトリ、チケット管理システム、シェルなどの実ツールに接続するための仕組みだ。接続ひとつひとつがMCPサーバーになる。2026年半ばに集計されたデータによれば、MCPサーバーの86%は開発者の端末上でローカルに動いており、本番環境で稼働しているのはわずか5%にすぎない。問題の本質はこの一文に集約される。企業内で最も急速に広がっている連携レイヤーが、SOCにとっては「普通のノートPC」でしかない端末の上で、誰も台帳に載せていない子プロセスとして起動し、誰もローテーションしていない認証情報を握っているのだ。

2026年に何が変わったか：数字で見る

• 2026年初頭のわずか60日間で、MCPサーバーに対して30件以上のCVEが登録された。その約43%がコマンドインジェクション系である。
• コミュニティ運営のVulnerable MCP Projectは、50件以上の既知の脆弱性を追跡しており、そのうち13件がクリティカルと評価されている。
• 5,200以上のMCPサーバーを対象とした監査では、53%が固定のAPIキーやパーソナルアクセストークンに依存し、79%が環境変数経由でキーを渡し、OAuthを使っているのはわずか8.5%だった。
• GitGuardianは公開GitHub上のMCP関連設定ファイルから24,008件のシークレットを発見し、うち2,117件はまだ有効だった。
• mcp-remoteのCVE-2025-6514(CVSS 9.6)は、信頼できないサーバーに接続しただけでクライアント端末上でリモートコード実行を許すもので、影響範囲は43万7,000件超のダウンロードに及んだ。
• CursorのCVE-2025-54136(通称「MCPoison」)はより巧妙なパターンを示した。一度承認されたMCP設定が、後から悪意あるものに静かに差し替えられ、永続的なコード実行につながるというものだ。

検知の観点で最も重要なのは最後の事例である。攻撃面はサーバーのコードだけではない。AIクライアントに「どのサーバーを、どの認証情報で起動するか」を指示する設定ファイルそのものが攻撃面になる。

なぜMCPはSOCの死角になるのか

以前の記事「2026年のAgentic AI SOC」で扱ったのは、セキュリティチーム自身が把握し管理しているAIエージェントだった。シャドーMCPはそれとは違う。従業員が自分で設定したエージェントとツール接続であり、多くの場合は善意で、仕事を速く進めるために導入されている。

flowchart TD
    A["開発者のノートPC"] --> B["CursorやClaude DesktopなどのAIクライアント"]
    B --> C["MCP設定ファイルにサーバーとキーを記載"]
    C --> D["ローカルMCPサーバーが子プロセスとして起動"]
    D --> E["Git DB SaaS API向けの固定トークン"]
    E --> F["開発者本人の権限で社内システムに到達"]

SOCの側から見ると、この連鎖のどの段階もごく普通に見える。

1. プロセスが普通に見える。 STDIOで起動されるMCPサーバーは、たいていログインユーザー権限で動くnode、npx、python、uvxにすぎない。新しいサービスもインストーラーも、検知すべき見慣れないバイナリもない。
2. 認証情報が正当に見える。 トークンは実在する従業員のものだ。エージェントが顧客データベースに問い合わせても、DB側のログに残るのはその従業員のIDであり、「ツール記述の指示に従って動いたAIエージェント」ではない。
3. ツール呼び出しが、収集しているどのログにも残らない。 MCPのやり取りはクライアントのプロセス内部で完結する。間にゲートウェイを置かない限り、どのツールがどの引数で呼ばれたかの監査証跡は存在しない。
4. 台帳の持ち主がいない。 情報システム部門がインストールしたわけでも、セキュリティ部門が承認したわけでもない。開発者は先週さらに3つ追加しているかもしれない。

Obsidianの研究チームがMCPセキュリティを「何よりもまず台帳(インベントリ)の問題」と位置づけるのはこのためだ。存在を知らないサーバーは、パッチもローテーションも監視もできない。

今月から導入できるWazuhの4層の検知策

以下はいずれも新製品の購入を必要としない。simpliSOCを含むWazuh 4.x環境で使えるリファレンスパターンであり、simpliSOCのパッケージ化されたMCPモジュールではない。この区別は後の節で明示する。

flowchart TD
    L1["第1層 MCP設定ファイルのFIM"] --> W["Wazuh manager"]
    L2["第2層 プロセス生成テレメトリ"] --> W
    L3["第3層 新規待受ポート"] --> W
    L4["第4層 コミット前のシークレットスキャン"] --> W
    W --> R["DFIR-IRISでアナリストがレビュー"]

第1層：MCP設定ファイルのファイル整合性監視(FIM)

MCPoisonは、設定ファイルが永続化の手段になり得ることを示した。だから監視する。開発者端末について、既知のクライアント設定ファイルの場所をWazuhのsyscheckに追加する。全社のユーザープロファイルを走査しないよう、対象は「開発者端末」のエージェントグループに限定する。

<!-- agent.conf, group: dev-workstations (Linux/macOSの例) -->
<syscheck>
  <directories check_all="yes" realtime="yes"
    restrict="mcp\.json$|claude_desktop_config\.json$">/home</directories>
  <directories check_all="yes" realtime="yes"
    restrict="mcp\.json$|claude_desktop_config\.json$">/Users</directories>
</syscheck>

続いて、これらのファイルの追加・変更時にアラートレベルを引き上げる。

<!-- local_rules.xml -->
<group name="mcp,syscheck,">
  <rule id="100910" level="10">
    <if_sid>550, 554</if_sid>
    <field name="file">mcp.json$|claude_desktop_config.json$</field>
    <description>MCP client configuration added or modified: $(file)</description>
    <mitre>
      <id>T1546</id>
    </mitre>
  </rule>
</group>

あえて外している設定がひとつある。これらのパスではreport_changesを有効にしないこと。 これらのファイルにはAPIキーが含まれていることが多く、report_changesを有効にすると差分がシークレットごとアラートインデックスにコピーされる。知りたいのはファイルが変わったという事実であり、守るべき場所をもうひとつ増やすことではない。

第2層：MCPサーバー起動のプロセス生成テレメトリ

すでにSysmonのイベントID 1をWazuhに送っているWindows端末であれば、低レベルの台帳用ルールでMCPの起動を検索可能な記録に変えられる。

<group name="mcp,sysmon,">
  <rule id="100911" level="5">
    <if_group>sysmon_event1</if_group>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)(mcp-remote|@modelcontextprotocol|mcp-server|mcp_server)</field>
    <description>MCP server process launched: $(win.eventdata.commandLine)</description>
  </rule>
</group>

レベル5は意図的な設定だ。開発者端末では頻繁に発火するが、それこそが狙いである。2週間もすれば、どのMCPサーバーが、どの端末で、どの親プロセスから実際に起動しているかの台帳ができあがる。平常時の姿がわかってから、例外向けの高レベルルールを書けばよい。たとえば0.1.16より古いmcp-remoteや、開発者グループ外の端末で起動したMCPサーバーなどだ。Linuxではauditdのexecve記録やosqueryで同じパターンを実現できる。

第3層：開発者端末の新規待受ポート

HTTPトランスポートを使うMCPサーバーの中には、デフォルトで0.0.0.0にバインドするものがある。そうなるとローカルのツールが、同じセグメントの誰からでも呼び出せるネットワークサービスに変わってしまう。Wazuhのデフォルト設定には、待受ポートを取得するnetstatコマンドと、ポート構成の変化で発火するルール533がすでに含まれている。開発者グループでこのコマンドが有効になっているかを確認し、同グループからのルール533のアラートをノイズに埋もれさせずレビューキューへ回すこと。ノートPC上でnodeやpythonが新たにポートを開いていれば、確認する価値がある。

第4層：設定ファイルがGitに入る前のシークレットスキャン

24,008件のシークレットは本番環境から漏れたのではない。リポジトリにコミットされた設定ファイルから漏れたのだ。この層はWazuhの守備範囲ではない。gitleaksやTruffleHogのようなシークレットスキャナーをpre-commitとCIに組み込み、MCP設定ファイル名を対象に加えるのが正解だ。スキャン結果はWazuhにログソースとして転送し、キー漏えいのイベントを他のアラートと同じケース管理フローに乗せる。

検知だけでなく、ID管理モデルを直す

検知によって「開発者のMCPサーバーが長期有効なGitHubトークンを持っている」ことはわかる。だが、そのトークンが存在するという事実は変わらない。MCP仕様の2025年6月改訂では、HTTPベースのサーバーに対してOAuth 2.1とPKCEの利用を推奨し、リソースサーバーと認可サーバーを分離している。それでも現実には、社内のMCPサーバーの多くが固定キーを受け付けている。最も早く作れる方法だからだ。

自社チームが作る社内MCPサーバーについては、既存のIDプロバイダーの背後に置くのがより良いパターンだ。すべてのツール呼び出しが実在ユーザーに紐づく短命なトークンを持ち、そのユーザーが必要とするツールだけにスコープされ、中央から失効させられる状態にする。AuthentikをベースとしたsimpliSSOは、私たちが顧客案件でこの役割に使っているコンポーネントだ。ただし正確に言えば、MCPサーバー向けの認可サーバーとしてsimpliSSOを使うのは案件ごとにスコープを定める統合パターンであり、simpliSSOに組み込み済みのMCP機能ではない。

日本企業にとってこの問題が重い理由

個人情報保護法(APPI): 開発者端末上のMCPサーバーが顧客DBにアクセスできるトークンを保持し、それが漏えいした場合、個人情報保護委員会への漏えい等報告(速報と確報)の対象になり得る。そのとき最初に問われるのは「そのトークンで何が行われたのか」だ。MCPの台帳もツール呼び出しのログもなければ、この問いにはほぼ答えられない。

能動的サイバー防御法: 2025年5月に成立し、2027年までの全面施行が予定されているこの法制度は、基幹インフラ事業者に対してサイバー攻撃の報告や重要な電子計算機導入時の届出を求める。影響を受けるのは事業者本体だけでなく、その事業者が利用するシステムに関わる事業者やITベンダーにも及ぶ。基幹インフラ事業者の開発を請け負う立場であれば、自社の開発者端末に何のMCPサーバーが動いているかを説明できることは、今後の取引条件になっていく可能性が高い。

経済安全保障推進法: 特定社会基盤事業者の重要設備に関わる委託先管理の観点でも、社内システムへの経路として可視化されていないMCP接続は、説明責任の空白になる。

提供済み機能とリファレンスパターンの明確な線引き

本記事が前提としている、simpliSOCが現在提供しているもの:

• 顧客ごとに導入・チューニングするWazuhのファイル整合性監視、Sysmonログの取り込み、コマンド監視
• 上記アラートをアナリストがレビューするためのDFIR-IRISによるケース管理
• Agentic AI SOCの記事で説明した、読み取り専用のローカルLLMによるトリアージ支援(これらのアラートを平易な言葉で説明できる)

本記事ではリファレンスパターンであり、提供済み機能ではないもの:

• 上記のMCP向けルール(ルールID 100910と100911)。顧客案件で導入・調整しているが、simpliSOCのパッケージ化されたルールセットには含まれていない
• MCPゲートウェイやプロキシによる個々のツール呼び出しの記録
• 組織全体のMCPサーバー台帳の自動レポート
• MCP向けOAuth 2.1認可サーバーとしてのsimpliSSO(案件ごとにスコープを定める)

30日間の導入プラン

1. 第1週: 開発者端末用のエージェントグループを作成し、第2層をレベル5で有効化する。まだ通知はせず、収集だけ行う。
2. 第2週: 集まった台帳をレビューし、各MCPサーバーを「承認」「当面許容」「撤去」に分類する。
3. 第3週: 同グループに第1層(設定ファイルFIM)と第3層(待受ポート)を展開し、シークレットスキャナーにMCP設定ファイル名を追加する。
4. 第4週: 第2週で見つかった固定トークンをすべてローテーションし、最もよく使われる社内MCPサーバーをIDプロバイダーの背後に移す。

よくある質問

MCPは設計上安全なのでは。2025年の記事では「MCPが信頼を提供する」と書いていたが。
MCPは統制を置くための標準的な場所を提供するが、統制そのものを置いてくれるわけではない。仕様上、認可はオプションであり、STDIOサーバーにはネットワーク認証がそもそも存在しない。実際に使われているサーバーの多くは固定キーだ。2025年の記事はMCPが可能にすることを説明したもので、本記事は2026年の実際の導入状況を説明している。

社用端末でMCPを全面禁止すべきか。
可能だし、規制の厳しい部門では禁止すべき場合もある。ただし多くの組織では、一律禁止は開発者を私物端末へと追いやり、より悪い死角を生む。まず台帳を作り、サーバーごとに判断するのがよい。

第2層のルールでSIEMがあふれないか。
開発者端末では最初の数日はにぎやかになる。だからこそレベル5で始め、対象を開発者グループに限定している。このルールの役割は台帳づくりであり、誰かを呼び出すことではない。

simpliSOCのAIはツールポイズニングを自動で検知できるか。
できない。私たちのローカルLLM支援機能は、Wazuhがすでに上げたアラートを説明するものであり、実行時にMCPのツール記述を検査するものではない。ツールポイズニングの検知にはプロトコルのやり取りそのものの可視化が必要で、それは上で「未提供」と明記したゲートウェイのパターンにあたる。

---

Wazuhを運用していて、これらのパターンを自社端末向けに調整したルールに落とし込みたい方、あるいは社内MCPサーバーを適切なID基盤の背後に置きたい方は、私たちにご相談いただきたい。詳細はsimpliSOCとsimpliSSOを、ご連絡は環境の概要を添えて hello@simplico.net まで。

---

出典:

• MCP Security Statistics 2026: CVEs, Vulnerabilities & Breach Data — Practical DevSecOps
• MCP Security Vulnerabilities: Complete Threat Inventory — Obsidian Security
• Agentic AI と MCP サーバー — Simplico
• 2026年のAgentic AI SOC — Simplico