ブログに戻るAIセキュリティ

MCPサーバーセキュリティ2026:8,000が公開、492は認証なし

8,000以上のModel ContextProtocolサーバーが公開されています。492個はゼロ認証です。36.7%はSSRFに脆弱です。MCPツール呼び出しでPIIを保護する方法。

March 16, 20267 分で読めます
MCP serverModel Context ProtocolAI securityPII protectionCursorClaude Desktopdeveloper security

MCPエコシステムは急成長した — セキュリティは追いつかなかった

Model Context Protocolは2024年末に登場した。18か月も経たないうちに、AIツールを外部システムに接続するための標準となった。2026年3月までに、このエコシステムはデータベースコネクター、ファイルサーバー、GitHubブリッジ、Slackクライアント、メールツール、数百の専門サーバーを網羅している。

成長曲線は急峻だ。セキュリティの状況はそうではない。

2026年3月時点で、8,000以上のMCPサーバーが公開インターネット上に存在する。エンドポイントをスキャンした研究者は、492件が認証ゼロであることを発見した — APIキーなし、OAuthなし、IPフィルターなし。どのHTTPクライアントでも呼び出せる。調査対象サーバーの36.7%がSSRF(Server-Side Request Forgery)に脆弱だ。つまり、ツール入力を制御できる攻撃者は、内部ネットワークリソースに到達できる。

同じ期間に、60日間で30以上のCVEが報告された。この速度は、エコシステムの未成熟さと、研究者の注目度の高さの両方を示している。

プロトコルがPIIリスクを生む理由

MCPはAIアシスタントにデータに対して行動する力を与える。それが同時にPIIリスクのベクターでもある理由だ。

開発者がCursorやClaude Desktopをデータベースコネクターと一緒に使う場合、AIは自然言語からSQLを生成する。そのクエリは実際のデータ行を返す — 名前、メールアドレス、支払いデータ、その他のPIIだ。そのデータは次の経路を移動する:

  1. データベースエンドポイント → AIアシスタントのコンテキストウィンドウ
  2. コンテキストウィンドウ → モデルプロバイダーのログシステム
  3. 会話履歴 → 開発者のローカルマシン
  4. デバッグセッション → 開発者がコンテキストを貼り付けた際の別のAIツール

これらのステップはどれも侵害ではない。システムが意図した動作だ。しかしPIIは本来扱うよう設計されていない複数の場所に行き着く。多くの場合、エンドポイントとAIクライアント間の暗号化もない。

CVE-2026-25253(CVSS 8.8)は2026年2月に公開され、具体的な攻撃経路を示した。悪意あるエンドポイントは、レスポンスに隠された命令を埋め込める。その命令は接続されたAIに、他のアクティブなツールからデータを引き出すよう指示する。侵害されたコミュニティエンドポイントを自分のデータベースコネクターと併用していた開発者は、データベース全体を漏洩させる可能性があった。

認証ゼロの492サーバー

492の公開エンドポイントはCVE-2026-25253とは別の問題だ。ハッキングされたのではない。設定が間違っていた。

ほとんどはローカルで動作するよう設計されていた。誰かがポートフォワーディングやアクセス制御なしのクラウドデプロイで公開してしまった。

これらのエンドポイントがよく公開しているもの:

  • ホームフォルダへの読み取りアクセスを持つファイルシステムツール
  • 設定ファイルに本番環境の認証情報が含まれたデータベースコネクター
  • 実際の受信トレイに紐づいたメールツール
  • コード実行ツール — 任意のコード、認証なし、制限なし

開発者はほぼ確実に公開するつもりはなかった。しかしCursorとClaude Desktopは設定内のどのURLにも接続する。ホストがローカルか公開かを確認する組み込みチェックはない。

anonym.legalのMCPソリューション

ツールパイプラインにおけるPIIリスクへの構造的な解決策は、LLMに送信されるどの呼び出しにもデータが届く前に匿名化することだ。これがanonym.legalのMCPサーバーが提供するものだ。

7つのツールを公開している:

ツール目的
analyze_textPIIエンティティを検出し、その位置と種類を返す
anonymize_text検出されたPIIを除去または仮名化する
deanonymize_text暗号化キーを使って仮名化を元に戻す
anonymize_batch複数のテキストを1回の呼び出しで処理する
get_supported_entities指定言語の273のエンティティ種類を一覧表示する
get_supported_languagesサポートされている48言語を一覧表示する
health_check接続性を確認する

AIアシスタントにanonym.legalサーバーとデータベースコネクターの両方が設定されている場合、開発者は「顧客データを表示する前に、結果に対してanonymize_textを呼び出してください」と指示できる。AIがオーケストレーションを処理し、PIIは識別可能な形式で表示出力や会話履歴に届くことはない。

Cursor IDEの設定

anonym.legalサーバーをCursorに追加するには:

// .cursor/mcp.json
{
  "mcpServers": {
    "anonym-legal": {
      "url": "https://anonym.legal/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

設定後、Cursorに「このサポートチケットをトラッカーに貼り付ける前にPIIを分析してください」と依頼できる。Cursorがanalyze_textを呼び出し、エンティティリストを返し、貼り付け前に匿名化するかどうかを判断する。

Claude Desktopの設定

// claude_desktop_config.json
{
  "mcpServers": {
    "anonym-legal": {
      "command": "npx",
      "args": ["-y", "@anonym-legal/mcp-server"],
      "env": {
        "ANONYM_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

この設定により、Claude Desktopは他のエンドポイントへのツール呼び出しに含める前にテキストを匿名化できる。PIIは識別可能な形式でAnthropicのサーバーに届くことはない。

設定を強化する

anonym.legalの使用に加え、これらのステップを適用してほしい。セキュリティ概要とコンプライアンスセンターも参照のこと。

ツールリストを監査する。 設定内のすべてのエントリーを確認する。オペレーターを信頼できるか?どのデータにアクセスできるか把握しているか?

ローカルをリモートより優先する。 ローカルエンドポイントはstdio経由で動作する。ネットワーク露出がない。ローカルの選択肢がない場合のみリモートエンドポイントを使用する。

認証を確認する。 すべてのリモートエンドポイントはAPIキーまたはOAuthトークンを要求すべきだ。要求しない場合、実際のユーザーデータを含むコンテキストで使用してはならない。

開発と本番を分離する。 開発作業(テストデータ、PIIなし)と実際のユーザーに触れるフローで設定を分ける。

監査ログを有効にする。 ログをサポートしている場合は有効にする。どの呼び出しでどのデータが流れたかを把握する。

MCP機能ページにはエンティティ種類と言語の完全なリストがある。

60日間で30以上のCVEは、プロトコルが積極的な調査下にあることを示している。新しい脆弱性は現れる。しかし、中核となる防御 — データがLLM呼び出しに届く前に匿名化する — は、次に発見されるどの特定のCVEに対しても有効だ。

CursorでAnonym.legalサーバーを設定する →


anonym.legalは、お客様の暗号化キーを使ってサーバー側で個人情報を匿名化します。仮名化されたデータは、そのキーがある場合にのみ元に戻せます。発行:anonym.legal — ISO 27001認証取得のHetznerインフラでホスト。

出典

  • ShodanのMCPサーバー露出データ、2026年3月 — 8,000以上のサーバー、492件が認証なし
  • CVE-2026-25253、CVSS 8.8、Model Context Protocol経由のクロスサーバー注入
  • SSRFデータ:公開アクセス可能なエンドポイントのセキュリティ調査スキャン、2026年3月
  • Anthropic MCPスペック v1.2、セキュリティ考慮事項セクション

データを保護する準備はできましたか?

48言語で273のエンティティタイプを使用してPIIを匿名化し始めましょう。