MCPサーバーの導入が進んでいます。
しかし、そのセキュリティ対策は追いついているでしょうか。
Redditで興味深い投稿が話題になりました。
あるセキュリティチームが、公開されている8,000以上のMCPサーバーをスキャン調査した結果を報告しています。
本記事では、その調査結果とコメント欄での議論を紹介します。
そして、MCPサーバーのセキュリティについて考えていきます。
MCPとは何か
MCP（Model Context Protocol）は、AIエージェントが外部ツールやサービスと連携するためのプロトコルです。
AIアシスタントがファイル操作やAPI呼び出し、データベースアクセスなどを行う場面を想像してください。
その際に仲介役を果たすのが、MCPサーバーです。
つまり、MCPサーバーはAIと外部世界をつなぐ橋のような存在と言えます。
この橋に脆弱性があれば、AIを経由して深刻な被害が生じるリスクがあるわけです。
調査の概要
投稿者のチームは、「MCP Trust Registry」というオープンなスキャンプロジェクトを運営しています。
OWASP MCP Top 10に対応した22のルールを使い、各MCPサーバーのセキュリティ状態を評価しました。
調査手法も興味深いものでした。
コメント欄での説明によると、エージェント型のシステムが新しいセキュリティ問題を動的に監視しているとのこと。
そして、SASTおよびDASTツールを組み合わせてソースコードを分析しています。
単一のスキャンツールに頼るのではありません。
複数のエージェントが証拠を収集しながら評価を行う仕組みです。
調査結果：3つの数字が示す現実
スキャン結果から浮かび上がった数字は、MCPエコシステムの現状を率直に物語っています。
まず、約36.7%のサーバーで、制限のないURI処理が確認されました。
これはSSRF（サーバーサイドリクエストフォージェリ）のリスクに直結する問題です。
実際に、MicrosoftのMarkItDown MCPサーバーでは、この脆弱性を通じてインスタンスメタデータの認証情報が取得可能だったと報告されています。
次に、約43%のサーバーが、悪用される恐れのあるコマンド実行パスを持っていました。
具体例を挙げましょう。
OllamaのMCPサーバーでは、複数のツールがテンプレート文字列の補間を通じてユーザー入力を直接シェルコマンドに注入していました。
つまり、任意のOSコマンド実行が可能な状態だったのです。
この脆弱性にはCVE-2025-15063が割り当てられています。
そして、約9.2%のサーバーには、深刻度が「クリティカル」に分類される問題が存在していました。
ゲートウェイだけでは守れない
コメント欄では、「ゲートウェイで保護すれば安全ではないのか」という質問が出ていました。
これに対する回答が、セキュリティの本質を突いています。
ゲートウェイの役割は、境界でのリクエスト監視です。
ツールの呼び出し許可リストや送信先URLの制限を設定すれば、多くの攻撃を防げるでしょう。
しかし、ゲートウェイには見えない領域があります。
それは実行レイヤーの内部です。
投稿者の説明によれば、エージェントが行う個々のツール呼び出しは、ゲートウェイから見ると「正当なリクエスト」に映ります。
ところが、複数のツール呼び出しが連鎖すると話は変わってきます。
意図しない結果や悪意ある結果につながる恐れがあるのです。
ツールの選択だけで安全な動作は保証できません。
前述のMicrosoftのMarkItDown MCPサーバーの事例がまさにそれでした。
ゲートウェイの観点では正当なツール呼び出しに見えていました。
しかし実行時には、サーバーがインスタンスメタデータの認証情報を取得する方向に誘導されていたのです。
問題は境界ではなく、実行の内部で起きていました。
あるコメント投稿者も、ゲートウェイの限界を認めています。
その上で、以下の組み合わせが効果的だったと述べていました。
- 実行時のシークレット注入
- リスクの高いツールに対する承認フローの導入
- 制限付き入力を持たないサーバーをCI段階で拒否するルール
サーバーサイドとクライアントサイドの区別
もう一つ、コメント欄で重要な論点が提起されていました。
MCPサーバー自体の脆弱性と、悪意あるMCPサーバーがクライアントに対して行う攻撃は、別の問題だという指摘です。
前者がサーバーサイド、後者がクライアントサイドのリスクに該当します。
投稿者によると、今回の調査はサーバーサイドの脆弱性に特化しています。
SSRFや安全でない実行パスといった、MCPサーバー実装そのものの問題です。
一方、クライアントサイドのリスクには、別のアプローチが必要になります。
実行レイヤーでの可視性と封じ込めを提供する仕組みです。
両者は異なる障害モデルに対応する補完的な制御であり、片方だけでは不十分でしょう。
なぜこの問題が見過ごされるのか
投稿者の言葉で印象的だったものがあります。
「問題はセキュリティ意識の欠如ではない。MCPが新しすぎて、標準的なセキュリティゲートが追いついていないのだ」という指摘です。
多くの開発チームは、セキュリティを軽視しているわけではないでしょう。
ただ、MCPサーバーという新しいカテゴリに対して、既存のセキュリティレビュープロセスがそのまま当てはまらないだけです。
また、同じMCPサーバーであっても、実装によってセキュリティレベルは大きく異なります。
コメント欄でも指摘されていましたが、同じ機能を提供するサーバーの中にセキュリティが優れたものとそうでないものが混在しているのが現状です。
実務への示唆
この調査結果から、MCPサーバーを運用するチームが意識すべきポイントが見えてきます。
まず、ゲートウェイに頼りすぎないこと。
境界での防御は必要です。
しかし、実行レイヤーでの可視性がなければ、想定外の動作を検知できません。
次に、CI/CDパイプラインにMCPサーバー固有のセキュリティチェックを組み込むこと。
制限のない入力やサニタイズされていないコマンド実行パスは、デプロイ前に検出すべき問題です。
そして、導入するMCPサーバーの実装品質を評価すること。
オープンソースであっても、セキュリティ面の精査なしに本番環境へ投入するのはリスクが高いと言えるでしょう。
まとめ
MCPサーバーは、AIエージェントの能力を大きく拡張する強力な仕組みです。
しかし、その急速な普及に対して、セキュリティの整備は遅れています。
8,000以上のサーバーをスキャンした結果、約4割にコマンド実行パスの問題がありました。
そして、約1割にクリティカルな脆弱性が存在していたのです。
この事実は、軽視すべきものではないでしょう。
ゲートウェイだけでは防げない問題があること。
サーバーサイドとクライアントサイドで異なるリスクモデルが存在すること。
そして、既存のセキュリティプロセスをMCPサーバーに適応させる必要があること。
これらを踏まえた上で、MCPの利便性を享受する姿勢が求められています。
新しい技術の導入と安全性の両立は、いつの時代も難しいテーマです。
MCPも例外ではありません。
だからこそ、今のうちにセキュリティ体制を整えておくことが、長期的な信頼性につながるはずです。
