AI エージェントはデータの操作方法に革命をもたらしていますが、AI とビジネスシステムをつなぐ架け橋であるモデルコンテキストプロトコル（MCP）が企業を危険にさらしている可能性があります。
MCP は、大規模言語モデル（LLM）とAI エージェントが外部ツールやデータソースに接続する方法を標準化するため、「AI 用のUSB-C」とよく表現されます。しかし、その利便性と相互運用性が急速な導入を後押ししている一方で、MCP のセキュリティ対策は追いついていません。実際、多くの企業がリスクを理解せずにすでにMCP を利用したワークフローを導入しています。
この記事では、最近の調査で特定されたセキュリティ上の懸念、安全なMCP システムの実装における課題、そしてこの新興エコシステムでデータとインフラストラクチャを保護するために企業が何をしなければならないかを探ります。
現在のセキュリティ状況
最近のセキュリティ調査では、憂慮すべき状況が示されています。MCP の人気が高まるにつれ、実験的で安全性に欠ける導入の数も増加しています。
実装の脆弱性
オープンソースのMCP サーバーの包括的な調査により、広範な欠陥が明らかになりました（PromptHub）：
サーバーの43% がコマンドインジェクションの脆弱性に悩まされています
33% が無制限のURL フェッチを許可し、SSRF スタイルの攻撃が可能になっています
22% が意図したディレクトリ外にファイルを漏洩しています
最近の2件のCVE は、これらの欠陥の深刻さを浮き彫りにしています：
プロトコルレベルのセキュリティギャップ
セキュリティリスクは実装に限ったものではありません。MCP のプロトコル設計は、悪用の機会を生み出します：
約2,000台のMCP サーバーが公開されており、その多くは認証なしでデプロイされています（TrollySec）
認可にはOAuth 2.1 が推奨されていますが、MCP では実際のデータプロトコルのセキュリティは実装者に委ねられています（Christian Posta）
これにより、開発者は各レイヤーでセキュリティを正しく確保するという大きな負担を強いられることになります（AppSec Enfineer）
認証と認可の課題
MCP は、AI ドリブンインタラクションのセキュリティ確保において新たな課題をもたらします：
AI エージェントは非決定論的に動作することが多く、決定論的な認証ワークフローを複雑にします
プロンプトインジェクションや隠されたツール指示により、エージェントが秘密情報を暴露したり認証情報を漏洩したりする可能性があります
システム間でのアクセストークンのマッピングには複雑な設定が必要で、容易に過剰な権限付与につながる可能性があります
エンタープライズ vs. 実験的：信頼の格差
MCP エコシステムは、オープンマーケットプレイスで匿名または半匿名で公開される実験的なプロジェクトが主流です。これらのツールは革新性を示す一方で、基本的なセキュリティ制御すら欠如していることが多々あります。多くの問題は、ハードコードされた認証情報、ユーザー入力からのシェルコマンドの実行、入力サニタイズの欠如など、エンタープライズ開発では長らく解決済みと考えられてきた問題を再び引き起こしています。
エージェントが権限レベルの異なるツールを連鎖的に使用し始めると、リスクは増大します。明確な境界がなければ、エージェントは信頼できるツールを使用して信頼度の低いツールの権限を昇格させ、エクスプロイトチェーンを作成する可能性があります。
企業にとって、このような実験的な文化は受け入れ難いものです。企業が求めるのは以下です：
既知のベンダーによる監査済みで信頼できる実装
エンタープライズグレードのサポートとインシデント対応
既存のインフラストラクチャに適合するセキュリティモデル
認証プロトコルとデータアクセスロジックの明確な分離
MCP セキュリティへのさまざまなアプローチ
すでにいくつかの企業が、本番環境でMCP を安全に運用するためのベストプラクティスを先駆的に導入しています。
1Password は明確な境界と認証情報の安全性を確立
1Password は、MCP（1Password Blog）経由でAI エージェントに生の認証情報を公開することを拒否しています。代わりに、以下のアプローチを採用しています：
認証情報を直接渡すのではなく、エージェントに代わって認証情報を挿入する
認証情報を配信する必要がある場合は、有効期間の短いスコープ付きトークンを使用する
MCP を、読み取り専用メタデータへのアクセスなど、低リスクで高価値なインタラクションに制限する
このアプローチは、非決定論的なエージェントの動作と機密性の高い認証情報は混在できないという認識に基づいています。
Epic AI はジャストインタイム認証を使用してより安全な探査を実現
Epic AI は動的な認可モデルを採用し、ユーザーはログイン前にパブリックツールを自由に利用でき、認証によって機密性の高い機能へのアクセスが可能になります（Epic AI）。主な原則は以下です：
この進歩的なアプローチは、ユーザーのコンテキストと信頼レベルに基づいてアクセスを許可することで、使いやすさと安全性のバランスを実現します。
MCP 実装におけるセキュリティのベストプラクティス
MCP の安全確保には、認証、開発、デプロイにまたがる多層防御戦略が必要です。
認証と認可
PKCE を使用したOAuth 2.1 を実装して認可フローを保護する
特注のログインシステムではなく、信頼できるID プロバイダーを使用する
各エージェントまたはツールのインタラクションに最小限の権限を適用する
トークンのライフサイクルを管理する：ローテーション、取り消し、スコープを適切に設定する
開発セキュリティ
デプロイ前にコード監査と侵入テストを実施する
すべての入力を検証してサニタイズする（特にシェルコマンドを呼び出す場合やURL を取得する場合）
許可された操作には許可リストを使用し、それ以外の操作はすべて拒否する
AI とツールの相互作用に関する包括的なログを維持する
デプロイメントセキュリティ
強化された信頼できるインフラストラクチャでMCP サーバーを実行する
ネットワーク分離（VPC、ファイアウォール）を使用してアクセスを制限する
定期的にサーバーにパッチを当てて更新する
MCP 関連の侵害に対するインシデント対応計画を策定し、テストする
安全なデプロイはオプションではない
モデルコンテキストプロトコルは強力なイノベーションです。これにより、AI エージェントがエンタープライズシステムと有意義なインタラクションを行うための扉が開かれます。しかし、その力には現実のリスクが伴います。セキュリティインシデントはもはや仮説ではなく、すでに実世界で発見されています。
既存のMCP サーバーのほとんどは実験的なプロジェクトです。エンタープライズグレードの基本的な保護機能さえ備えていません。MCP 仕様自体も、本番環境に対応するには慎重な実装と追加のセキュリティ対策が必要です。
MCP の導入を検討している企業は、次の要件を満たす必要があります：
セキュリティ、出所、サポート可能性の観点からサーバーとツールを検査する
不明または監査されていないMCP 実装を避ける
エンタープライズグレードのセキュリティ制御、監査可能性、インシデント対応を要求する
AI ワークフロー全体にわたって既存のガバナンスとアクセス制御を引き続き適用する
CData MCP Servers でデータと安全に対話
リスクを理解することは、最初のステップにすぎません。次回の記事では、安全でエンタープライズ対応のMCP ソリューションの実装方法と、CData MCP Servers がAI を最も機密性の高いシステムに安全に接続するためにどのように役立つかについて説明します。
※本記事はCData US ブログ Is MCP Secure? The Hidden Risks in AI's Universal Connector の翻訳です。
