MCPサーバーを繋ぐだけで情報漏洩?4つの危険と接続前の7確認

「このMCPサーバーを入れたら、AIがチケットも監視ツールも見られて便利だよ」。先輩や同期にそう勧められて、設定ファイルに数行足しただけで使い始めていませんか。

この記事では、MCPサーバーをつなぐときに起きうる情報漏洩の4つのパターンと、実際に起きた事例を整理します。そのうえで、接続する前に確かめたい7つの項目を、運用の現場目線でまとめます。

結論を先に言います。MCPサーバーは「便利なプラグイン」ではなく「AIに渡す合鍵」です。誰が作ったか、何を読むか、どこまで触れるか、誰が承認するかの4点を確かめてからつなぎましょう。

MCPサーバーとは?AIに外部ツールをつなぐ仕組み

MCP(Model Context Protocol)とは、AIとGitHubやデータベース、チャットなどの外部ツールをつなぐための共通の約束ごとです。MCPサーバーは、その約束に沿ってAIに「使える道具」を差し出す小さなプログラムを指します。

たとえるなら、新しく来た派遣スタッフ(AI)に、社内の部屋ごとの鍵(MCPサーバー)を渡すようなものです。鍵が多いほど仕事は早く進みます。一方で、そのスタッフがだまされたとき、開けられる部屋も同じだけ増えます。

2026年9月にはZennで、Snowflakeが管理するMCPサーバーを使い、エンジニア以外の社員がClaude Desktopからデータを集計できるようにした事例も紹介されています。つなぐ手間はどんどん小さくなっています。だからこそ、つなぐ前の確認が抜けやすくなっているのです。

つまり、MCPサーバーは「AIの手足を増やす仕組み」であり、増えた手足のぶんだけ守る範囲も広がります。

MCPサーバーで情報が漏れる4つの危険パターン

Qiitaの解説記事では、危険を次の4つに分けています。どれも「サーバーにバグがある」話ではなく、AIの使われ方そのものに原因がある点が特徴です。

• ツールポイズニング: ツールの説明文に指示を仕込み、AIを乗っ取る。公開されているMCPサーバー1,899件を調べたHasanらの論文では、5.5%のサーバーでこの種の問題が見つかった
• 間接プロンプトインジェクション: issueやWebページ、PDFなど、第三者が書いた文章に隠れた指示をAIが実行してしまう
• 過剰な権限と長期キー: 乗っ取られたときの被害が大きく、鍵を止めるのも遅れる。Astrix Securityが5,000件を超えるMCPサーバーを調べた2025年の調査では、約53%がAPIキーやアクセストークンといった固定の資格情報を使っていた(OAuthは約8.5%)
• 自動承認: 人の確認をはさまず、指示がそのまま実行される。MCPの仕様では、人が確認して止められるようにすることは「推奨(SHOULD)」で、「必須(MUST)」ではない

プロンプトインジェクションとは、AIへの指示に見えない形で別の命令を混ぜ込む攻撃のことです。人間なら読み飛ばす一文でも、AIは「やるべき作業」と受け取ってしまいます。

4つは単独ではなく、つながって被害を大きくします。だまされる入口(1と2)と、被害の広さ(3と4)の両方を見る必要があります。

MCPサーバー経由の情報漏洩で実際に起きた2つの事例

机上の話ではありません。Qiitaの解説記事では、すでに報告された事例が2つ紹介されています。

1つ目は2025年5月26日にInvariant Labsが報告したものです。攻撃者が公開リポジトリのissueに指示を埋め込むと、GitHub MCPを使うAIエージェントがそのissueを読んだときに非公開リポジトリの中身を取り込み、公開リポジトリに自動で作ったプルリクエストに書き出してしまうおそれがありました。

2つ目は2026年8月3日に公表されたCVE-2026-18655です。AWS LabsのAmazon MQ向けMCPサーバーでは、接続先のホスト名をAIが指定でき、その値が検証されていませんでした。そのため、AIが読む内容にプロンプトインジェクションを仕込まれると、ブローカーの資格情報やOAuthトークンを攻撃者のサーバーへ送らされるおそれがありました。深刻度は中程度(CVSS 6.5)で、2.0.24で修正されています(2.0.23以前が対象)。

どちらも「外から書き込める文章」を読んだことが引き金でした。読むだけの操作でも、読んだ中身しだいでAIの行動は変わるということです。

図解: MCPサーバーを接続する前に確かめる7項目

Qiitaの解説記事のチェックリストを、どの危険を防ぐためのものかがわかる形に筆者が並べ直しました。上から順に確かめてください。

1. 提供元とバージョンを確かめる → ツールポイズニングの対策。自分で作ったものか、信用できる提供元のものか。更新は続いているか
2. 第三者が書いた文章を読み込むかを確かめる → 間接プロンプトインジェクションの対策
3. 追加する範囲(自分だけ/プロジェクトで共有/すべてのプロジェクト)を選ぶ → 過剰な権限の対策
4. 使うツールと権限を最小にする → 過剰な権限の対策。読むだけで済むなら書き込みは渡さない
5. キーの置き場所と取り消し方を確かめる → 長期キーの対策
6. 承認の既定と「常に許可」を見直す → 自動承認の対策。「常に許可」は、人が見ていなくても動かしてよいツールだけにする
7. 承認画面の出ない使い方を把握する → 自動承認の対策。claude -p(対話なしで動かすコマンド)やAgent SDK、クラウドでの実行では承認を求める画面が出ないため、事前にどのツールを許可しているかがそのまま効く

4番の好例が、先ほどのSnowflakeの事例です。読み取り専用のロールを作り、特定のテーブルにSELECTだけを許可していました。さらにACCOUNTADMINなどの管理者ロールをOAuth接続から明示的に締め出し、認可の途中でやり取りされるコードを横取りされても使われにくくするPKCEという仕組みも有効にしています。

7項目すべてを1人で判断する必要はありません。わからない項目があれば、それ自体を先輩に聞く材料にしてください。

運用・インフラ現場でMCPサーバーを安全に使うには(筆者の考察)

ここからは筆者の考えです。運用・監視の現場では、MCPサーバーの危険は開発の現場より大きくなりやすいと考えています。

理由は、運用担当が扱う情報の多くが「外から書き込まれる文章」だからです。アラート本文、問い合わせチケット、外部ベンダーからのメール、ログに残ったユーザー入力。どれも攻撃者が文字を差し込める場所です。そこをAIに読ませ、同じAIが本番サーバーを操作できるなら、事例1と同じ構図になります。

そこでおすすめしたいのが、「読む役」と「動かす役」を分けることです。チケットやログを読むAIには書き込み権限を持たせません。本番を操作する手順は、人が承認してから別の経路で実行します。夜勤で眠いときほど自動承認に頼りたくなりますが、そこを守るのが仕組みの役目です。

読み取り専用で回す設計は深夜アラートの一次調査をAIに任せる設計で詳しく書きました。鍵の渡し方はAPIキーを.envに置くのが危ない理由、暴走の止め方はAIエージェントの暴走を止める4層が参考になります。

「この道具は何を読み、何を触れるのか」を言葉で説明できる人は、AIを任せてもらえる人です。MCPサーバーはその練習にちょうどよい題材です。

設定ファイルに書いた鍵をGitHubへ送ってしまった場合に、自動の検査がどこまで守ってくれるかは、シークレットスキャンとは｜業務システム65件中53件が対象外を参考にしてください。

まとめ

• MCPサーバーはAIに渡す合鍵で、つなぐほど便利になる一方、漏れる経路も増える
• 危険はツールポイズニング・間接プロンプトインジェクション・過剰な権限と長期キー・自動承認の4つ
• 接続前に提供元・読む内容・権限・キー・承認設定など7項目を確かめ、読む役と動かす役を分ける

まずは今使っているMCPサーバーを1つ選び、「読み込む文章に第三者が書けるか」だけでも確かめてみてください。

参考リンク

• Tools – Model Context Protocol 仕様(2026-07-28版) ― 人の確認はSHOULD、サーバー側の入力検証・アクセス制御などはMUST
• Model Context Protocol (MCP) at First Glance(Hasanら・arXiv) ― MCPサーバー1,899件の調査、ツールポイズニング5.5%
• State of MCP Server Security 2025(Astrix Security) ― 固定の資格情報約53%・OAuth約8.5%
• GitHub MCP Exploited(Invariant Labs・2025年5月26日) ― 事例1の報告
• CVE-2026-18655のセキュリティアドバイザリ(GitHub・awslabs/mcp) ― 事例2の対象バージョンと修正内容
• MCP サーバーと繋いだだけで情報漏洩？ 危険の4パターンと事前に確認すべき7つのことをまとめてみた – Qiita ― 4つの危険と7つの確認の整理
• Snowflake管理のMCP serverでエンジニア以外の社員がClaude Desktopから簡単にデータを集計・分析できる環境を作る – Zenn ― 読み取り専用ロール・管理者ロールの締め出し・PKCEの設定例