AI エージェントが社内システムやクラウドAPIと直接やり取りできる MCP(Model Context Protocol)は、開発効率を飛躍的に高めるプロトコルです。しかし、MCP サーバーを介して API キーやデータベース接続情報といった機密情報が外部に流出するインシデントが2025年以降急増しています。Trend Micro の調査では、認証・暗号化が施されていない公開 MCP サーバーが492台発見され、そこから1,402個のツールへ無認証でアクセスできる状態でした(出典: Trend Micro)。

本記事では、MCP サーバーの機密情報保護を「攻撃手法の理解 → 業界標準フレームワーク → 実践的な防御設定」の3ステップで整理します。

MCPサーバーにおける機密情報漏洩の仕組み

MCP は、AI ホスト(Claude Desktop、Cursor など)と外部ツールを接続するためのオープンプロトコルです。Anthropic が2024年に公開し、現在はオープンソースとして仕様策定が進んでいます。

機密情報が漏洩する原因は、MCP のアーキテクチャそのものに起因します。

MCPの通信経路と情報の流れ

MCP の通信は「MCP ホスト → MCP クライアント → MCP サーバー → 外部サービス」の順で行われます。

ユーザー
  ↓ プロンプト入力
MCP ホスト(Claude Desktop / Cursorなど)
  ↓ ツール呼び出し
MCP クライアント
  ↓ stdio / Streamable HTTP
MCP サーバー(ローカル or リモート)
  ↓ API Key / DBパスワードで認証
外部サービス(GitHub, Slack, DBなど)

問題は、MCP サーバーが外部サービスへ接続するためにAPI キーやトークンを保持しているにもかかわらず、そのサーバー自体のセキュリティが十分に設計されていないケースが多い点です。

設定ファイルに埋め込まれた認証情報

多くの MCP サーバーは、設定ファイル(JSON)に API キーを直接記述する構成を取っています。

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxxxxxxxxxxxxxx"
      }
    }
  }
}

このファイルは通常 ~/.cursor/mcp.jsonclaude_desktop_config.json などに配置されますが、ファイルのパーミッション設定が甘い場合、他のプロセスやユーザーから読み取られる危険性があります。

実際に発生したMCPサーバーの機密情報漏洩インシデント

2025年以降、MCP サーバーに関連するセキュリティインシデントが複数報告されています。主要な事例を時系列で整理します。

2025年4月:WhatsApp MCP経由のチャット履歴流出

Invariant Labs の調査により、正規の whatsapp-mcp サーバーがツール汚染攻撃(Tool Poisoning)と組み合わさることで、ユーザーのチャット履歴全体が攻撃者の電話番号へ転送される脆弱性が発見されました(出典: Invariant Labs)。

2025年5月:GitHub MCP経由のプライベートリポジトリ漏洩

公開 GitHub Issue に埋め込まれた悪意あるプロンプトが、AI アシスタントの GitHub MCP サーバー接続を乗っ取り、プライベートリポジトリの内容や給与情報が公開プルリクエストへ書き出されました。根本原因は、過剰な権限を持つ Personal Access Token(PAT)の使用でした(出典: Invariant Labs)。

2025年6月:Asana MCPサーバーのテナント間データ漏洩

Asana の MCP 連携機能において、他組織のタスク、プロジェクトメタデータ、コメント、添付ファイルが閲覧可能な状態が約1ヶ月間続きました。影響を受けた顧客は約1,000組織にのぼります(出典: BleepingComputer)。

2025年6月:Anthropic MCP Inspector の RCE(CVE-2025-49596)

Anthropic 公式の MCP Inspector ツールに CVSS 9.4 の認証不要リモートコード実行脆弱性が発見されました。DNS リバインディング攻撃を通じてローカルホストの Inspector へブラウザ経由でアクセスし、任意コードが実行可能でした(出典: Recorded Future)。

2025年7月:mcp-remote のコマンドインジェクション(CVE-2025-6514)

CVSS 9.6 の OS コマンドインジェクション脆弱性が mcp-remote パッケージで発見されました。影響を受けたダウンロード数は43万7,000件以上で、Cloudflare や Hugging Face のデプロイメントにも波及しました(出典: JFrog)。

2025年10月:Smithery MCPホスティングのサプライチェーン侵害

MCP サーバーホスティングサービス Smithery でパストラバーサル脆弱性が発覚し、Docker 認証情報と Fly.io API トークンが漏洩しました。この脆弱性を突くと、Smithery の Fly.io アカウント上で稼働する3,000以上のアプリケーションを制御できる状態でした(出典: SC World)。

2025年12月〜2026年1月:Anthropic mcp-server-git の複数脆弱性

Anthropic の公式 Git MCP サーバーで3つの脆弱性が報告されました(出典: The Hacker News)。

CVE 番号CVSS v3内容
CVE-2025-681438.8git_init でのパストラバーサル
CVE-2025-681448.1git_diff / git_checkout での引数インジェクション
CVE-2025-681457.1–repository フラグによるパストラバーサル

OWASP MCP Top 10 ― 機密情報に関わる脅威の体系的な分類

OWASP は2025年、MCP に特化したセキュリティリスクの Top 10 を公開しました(出典: OWASP)。機密情報漏洩に直結する項目を中心に解説します。

順位脅威 ID名称機密情報との関連
1MCP01:2025トークン管理不備と秘密情報の露出API キーのハードコーディング、ログへのトークン出力
2MCP02:2025スコープクリープによる権限昇格広すぎる権限設定で不要なデータへアクセス
3MCP03:2025ツール汚染ラグプル、スキーマ汚染、ツールシャドーイング
4MCP04:2025ソフトウェアサプライチェーン攻撃悪意あるパッケージによるクレデンシャル窃取
5MCP05:2025コマンドインジェクション未検証入力を通じたシステムコマンド実行
6MCP06:2025コンテキスト経由のプロンプトインジェクションモデルへの悪意あるペイロードで情報抽出
7MCP07:2025不十分な認証・認可マルチエージェント環境での身元検証の欠如
8MCP08:2025監査・テレメトリの欠如インシデント発生時の原因追跡が困難
9MCP09:2025シャドー MCP サーバー未承認デプロイメント、デフォルト認証情報の放置
10MCP10:2025コンテキストインジェクションと過剰共有共有コンテキストウィンドウへの機密データ混入

MCP01:トークン管理不備の具体例

最も発生頻度の高い脅威です。設定ファイルへの API キー直書きだけでなく、MCP サーバーがログに認証トークンを出力してしまい、プロンプトインジェクション経由でログを読み取られるケースも含まれます。

MCP03:ツール汚染攻撃の3パターン

ツール汚染は次の3つに分類されます。

  • ラグプル(Rug Pull):信頼を得た後にツール定義を改ざんし、データ窃取機能を追加する
  • スキーマ汚染:ツールの入出力スキーマに悪意ある記述を埋め込み、LLM の挙動を変更する
  • ツールシャドーイング:正規ツールと同名の悪意あるツールを登録し、呼び出しを横取りする

MCP10:コンテキスト過剰共有の落とし穴

複数の MCP サーバーを同時接続している場合、あるサーバーから取得した機密データが LLM のコンテキストウィンドウに残り、別のサーバーへの出力に混入する危険性があります。たとえば、社内 Confluence から取得した人事データが、Slack MCP サーバー経由で外部チャンネルに投稿される可能性があります。

MCPサーバーの脆弱性統計 ― 数字で見る現状

複数のセキュリティ企業が MCP サーバーの脆弱性調査を実施しています。

Equixly の調査結果

セキュリティ企業 Equixly が公開 MCP サーバーを対象に実施したペネトレーションテストでは、以下の結果が報告されています(出典: Equixly)。

脆弱性カテゴリ検出率
コマンドインジェクション43%
SSRF(Server-Side Request Forgery)30%
パストラバーサル22%
不適切なセキュリティプラクティス全般66%
ツール汚染5.5%

Backslash Security の大規模調査

Backslash Security は 7,000以上の MCP サーバーを調査し、数百台のサーバーが 0.0.0.0 にバインドされてネットワーク上の任意の端末からアクセス可能な「NeighborJack」脆弱性を抱えていました。また、数十台のサーバーで任意コマンド実行が可能な状態でした(出典: GlobeNewsWire)。

MCPTox ベンチマーク(学術研究)

2025年8月に公開された MCPTox ベンチマークでは、20種類の LLM エージェントに対して45のリアルワールド MCP サーバーと353のツールを使い、1,312件の攻撃テストを実施しました。o1-mini の攻撃成功率は72.8%、Claude 3.7 Sonnet でも拒否率は3%未満という結果でした(出典: arXiv)。高性能なモデルほど指示追従性が高いため、攻撃に対してもより脆弱になるという逆説的な傾向が確認されています。

MCPサーバーの機密情報を守る5つの実践的防御策

防御策1:認証情報を設定ファイルに直書きしない

MCP 公式仕様では、トークンの直接パススルーを明確に禁止しています(出典: MCP Specification)。

推奨方法:環境変数または OS のキーチェーン/シークレットマネージャーを使用する

# NG: 設定ファイルに直書き
"env": { "API_KEY": "sk-xxxxxxxxxxxx" }

# OK: 環境変数参照(MCP仕様の記法)
"env": { "API_KEY": "${env:MY_API_KEY}" }

クラウド環境では AWS Secrets Manager、GCP Secret Manager、Azure Key Vault などのシークレット管理サービスを利用し、実行時にのみ認証情報を取得する方式が望ましいです。

防御策2:OAuth 2.1 + PKCE によるアクセス制御

MCP の公式仕様(2025年ドラフト版)は、リモート MCP サーバーの認可に OAuth 2.1(IETF draft-ietf-oauth-v2-1-13)を採用しています(出典: MCP Authorization Spec)。

主要な要件は次のとおりです。

  • PKCE(Proof Key for Code Exchange)の S256 が必須 ― 認可コード横取り攻撃を防止
  • RFC 8707 Resource Indicators でトークンの対象サーバーを明示的に紐付け
  • RFC 9728 Protected Resource Metadata でクライアントが認可サーバーを正しく検出
  • アクセストークンは短命にし、リフレッシュトークンのローテーションを実装
  • 全エンドポイントでHTTPS必須
認可フロー:
1. MCP Client → 認可サーバー: 認可リクエスト(PKCE code_challenge 付き)
2. ユーザー → 認可サーバー: 承認
3. 認可サーバー → MCP Client: 認可コード
4. MCP Client → 認可サーバー: トークンリクエスト(code_verifier 付き)
5. 認可サーバー → MCP Client: アクセストークン(短命)+ リフレッシュトークン
6. MCP Client → MCP Server: Authorization ヘッダにアクセストークンを付与

防御策3:Docker コンテナによるサンドボックス隔離

Docker は MCP サーバー専用のセキュリティソリューション「Docker MCP Toolkit」を提供しています(出典: Docker Docs)。

各 MCP サーバーをコンテナ内で実行することで、次のセキュリティ制御を適用できます。

制御項目内容
リソース制限CPU 1コア、メモリ 2GB に制限
ファイルシステム分離ホストのファイルシステムへのアクセスをデフォルト遮断
出所検証Docker が構築したイメージか検証、SBOM によるサプライチェーン確認
シークレット保護機密情報を含むリクエストをブロック
OAuth 自動処理認証フローを自動的にハンドリング
{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run", "--rm",
        "--memory=2g", "--cpus=1",
        "--network=none",
        "-e", "GITHUB_TOKEN",
        "mcp/github"
      ]
    }
  }
}

--network=none を指定すると、コンテナからの外部通信が完全に遮断されます。必要なエンドポイントのみ許可する場合は、Docker のカスタムネットワークと iptables ルールで制御します。

防御策4:最小権限の原則とスコープ制限

MCP 公式仕様は「スコープ最小化」と「段階的権限昇格」を推奨しています(出典: MCP Security Best Practices)。

実装のポイント:

  • GitHub PAT は repo:read のみに限定し、repo:writeadmin を付与しない
  • データベース接続はリードオンリーアカウントを使用する
  • ファイルシステムアクセスは特定のディレクトリのみに制限する
  • 複数の MCP サーバーを接続する場合、扱う情報の機密レベルを揃える

アンチパターン:過剰権限の PAT を使い回す

GitHub MCP サーバーに repo, admin:org, gist, user すべてのスコープを持つ PAT を渡すと、AI が意図せずリポジトリの削除や組織設定の変更を実行できてしまいます。2025年5月に発生したプライベートリポジトリ漏洩インシデントは、まさにこのパターンでした。

防御策5:セキュリティスキャンツールの導入

MCP サーバーの脆弱性を自動検出するためのツールが複数公開されています。

ツール名開発元主な機能GitHub Stars
MCP-ScanInvariant Labsプロンプトインジェクション検出、ツール汚染スキャン、ラグプル監視(ハッシュ比較)、ハードコードされたシークレット検出1,400+
Cisco MCP ScannerCiscoYARA ルールベースの静的解析
MCP-ShieldRise and Igniteツール汚染検出、データ抽出チャネルの特定、クロスオリジン権限昇格の検出
mcpscan.aiオンラインスキャナー(URLを入力して診断)

MCP-Scan の実行方法:

# インストールと実行
pip install mcp-scan
mcp-scan

# 特定の設定ファイルを対象にスキャン
mcp-scan --config ~/.cursor/mcp.json

# プロキシモードでランタイムトラフィックを監視
mcp-scan proxy --port 8080

MCP-Scan はローカル stdio サーバーとリモート HTTP/SSE サーバーの両方に対応しており、PII(個人識別情報)検出やシークレットブロックのカスタムガードレールも設定できます。

組織で導入すべき MCPセキュリティチェックリスト

以下のチェックリストを、MCP サーバーの導入・運用時に活用してください。

導入前

  • MCP サーバーのソースコードまたはイメージの出所を検証した
  • 使用するツールの権限スコープを最小限に設定した
  • 認証情報を設定ファイルに直書きしていない
  • MCP-Scan 等のスキャンツールで初回診断を実施した
  • Docker コンテナ等でサンドボックス隔離を構成した

運用中

  • MCP サーバーのツール定義ハッシュを定期的に検証している(ラグプル対策)
  • アクセストークンの有効期限を短く設定し、ローテーションを実装した
  • MCP サーバーのアクセスログを収集・監視している
  • 複数サーバー接続時、機密レベルの異なるサーバーを分離している
  • 社内で未承認のシャドー MCP サーバーが稼働していないか定期調査している

インシデント対応

  • MCP サーバー経由の不正アクセスを検知するアラートルールを設定した
  • 認証情報漏洩時の即時ローテーション手順を文書化した
  • MCP サーバーの緊急停止(キルスイッチ)手順を定めた

まとめ

MCP サーバーは AI エージェントの能力を拡張する強力な仕組みですが、設定ファイルへの認証情報直書き、過剰な権限付与、サプライチェーンの未検証など、機密情報漏洩のリスクを内在しています。Equixly の調査ではテスト対象の43%にコマンドインジェクション脆弱性が検出され、Trend Micro は認証なしで公開された MCP サーバーを492台確認しています。

OWASP MCP Top 10 をリスク評価の基準とし、OAuth 2.1 + PKCE による認可制御、Docker コンテナによる隔離、MCP-Scan によるスキャンの3層防御を組み合わせることが、現時点で最も実効性の高いアプローチです。