MCPセキュリティ問題:企業が対処すべき隠れたリスク
.webp)
Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
企業がAIエージェントのデプロイメントを拡大するにつれて、モデルと現実世界のツールを接続するインフラストラクチャは、重要なセキュリティ境界になりつつあります。モデルコンテキストプロトコル(MCP)は、この変化の中心にあり、エージェント、データソース、外部システム間の構造化されたやり取りを可能にします。統合とオーケストレーションを加速する一方で、多くの組織がまだ理解し始めたばかりの新たなリスク層も導入しています。
導入速度とセキュリティ準備の間のギャップにこそ、MCPセキュリティリスクが存在します。このコンテキストプロトコルは、AIエージェントがツールやデータソースに接続する方法を標準化しますが、これらの接続がどのように保護されるかを強制するものではありません。認証、アクセス制御、監査ログは組み込まれていません。組織はそれらの層を自分たちで追加する必要がありますが、ほとんどの組織はまだ行っていません。
このガイドでは、MCPセキュリティリスクが実際に何であるか、現在エンタープライズデプロイメントに影響を与えている具体的な脆弱性、従来のアプリケーションセキュリティツールではそれらを処理できない理由、そして適切に管理されたデプロイメントが実際にどのようなものかについて説明します。
MCPセキュリティリスクとは何ですか?
MCPセキュリティリスクとは、AIエージェントが二次的なガバナンス層なしにMCPサーバーを介して認証、認可、データ交換を行う際に発生する脆弱性のことです。このプロトコルは、クライアントとサーバー間でメッセージがどのようにフォーマットされ、交換されるかを定義していますが、セキュリティの強制については言及していません。
チームが外部制御なしにMCPサーバーをデプロイすると、インフラストラクチャに「開かれた扉」を作ることになります。
- 未検証のリクエスト: 発信者の身元を確認せずに指示を受け入れるサーバー。
- 不正なツール呼び出し: エージェントに実行が許可されているかを確認せずに、アクション(データの削除など)を実行するサーバー。
- 目に見えない侵害: 何か問題が発生した際に、セキュリティチームを盲目にする監査証跡の欠如。
トレンドマイクロは最近、認証なしでインターネットに公開されている492台のMCPサーバーを発見しました。このパターンは、ガバナンスへの並行投資なしに、その機能のためにプロトコルを高速で採用するという危険な傾向を反映しています。
設定ミスが問題をさらに悪化させます。チームがクラウド環境全体でより多くのサーバーを立ち上げるにつれて、ローカル開発では問題なかったデフォルト設定が本番環境に持ち込まれてしまいます。監視されていないAIエージェントの動作が、残りの問題を引き起こします。プロトコルが提供するものと、本番デプロイメントが必要とするものの間の構造的なギャップこそが、悪意のあるアクターが侵入する経路となります。
.webp)
企業を脅かす中核的なMCPセキュリティ課題
モデルコンテキストプロトコル 組み込みのセキュリティフレームワークとしてではなく、純粋にトランスポート層として機能します。AIシステムが外部ツールやデータに接続する方法を標準化する一方で、保護は完全に周辺インフラストラクチャに委ねられています。
その結果、これらの制御が不十分または欠如している場合、エンタープライズデプロイメントは、4つの繰り返し発生するセキュリティリスクカテゴリを露呈する傾向があります。
過剰なサーバーアクセス権限
開発者は、認証エラーを避けるため、プロトタイプ作成時にMCPサーバーに広範な権限を設定します。これは最小権限の原則に反する行為です。そして、これらの権限が本番稼働前に縮小されることは稀です。
例えば、Jiraチケットを要約するために作られたAIエージェントが、基盤となるサーバーが管理者アクセス権で設定され、一度も制限されなかった場合、そのチケットを削除したり、プロジェクトを閉じたり、権限を変更したりする認証情報を持っている可能性があります。
攻撃者や注入された命令がそのエージェントを侵害すると、サーバーが実行できることの全範囲を継承します。その影響範囲は、エージェントが本来行うべきことではなく、アクセス制御がどれほど過剰にプロビジョニングされていたかによって決まります。
不正な操作につながるプロンプトインジェクション
MCP環境におけるプロンプトインジェクションは、基本的なチャットボット操作とは異なります。AIエージェントがアクションを実行できる場合、注入された命令は単に不適切な応答を生成するだけでなく、外部システムに対して実際の操作をトリガーします。
悪意のあるアクターは、エージェントが処理するドキュメント、サポートチケット、メール、またはウェブページ内に命令を埋め込みます。2025年6月に発生したSupabase Cursorインシデントは、その明確な例です。この事例では、サービスロールアクセスを持つAIエージェントがSQL命令を含むサポートチケットを処理し、統合トークンを読み取って公開スレッドに漏洩させました。ネットワーク侵害もマルウェアもありません。エージェントがコマンドとして扱った単なるテキストが原因でした。
2025年5月のGitHub MCPインシデントも同様のパターンをたどりました。公開Issueにおける間接的なプロンプトインジェクションにより、プライベートリポジトリのコードが流出しました。
このため、大規模言語モデル向けのOWASP Top 10では、プロンプトインジェクションを最も重要な脆弱性として位置付けており、企業がインフラ層で対処すべき主要なMCPセキュリティリスクとなっています。
サーバーサイドリクエストフォージェリ (SSRF) とデータ流出
MCPサーバーは企業ネットワークの奥深くに位置し、内部データベース、ファイルシステム、クラウドインフラにアクセスできます。その位置付けが、それらを便利にしている理由です。また、それがSSRFを危険にする理由でもあります。 MCPセキュリティ 制御がない場合です。
BlueRock Securityは7,000台以上のMCPサーバーを分析し、そのうち36.7%がSSRFに対して潜在的に脆弱であることを発見しました。MicrosoftのMarkItDown MCPサーバーに対する概念実証では、研究者たちはEC2インスタンスのメタデータエンドポイントからAWS IAM APIキー、シークレットキー、SSHキーを直接取得しました。このサーバーは、検証なしに任意のURLを取得していました。
SSRF脆弱性のあるサーバーを使用する侵害されたAIエージェントは、直接的に境界を侵害する必要はありません。サーバーに内部リソースを取得するよう指示し、外部への応答を通じて機密データを表面化させます。そこから、悪意のあるアクターは内部アーキテクチャをマッピングし、追加の侵入ポイントを見つけることができます。
ツールと緩和戦略の詳細については、当社のガイド「 最高のMCPセキュリティツール」を参照してください。
分散した認証情報の拡散
一元化されたゲートウェイがない場合、各AIエージェントは独自の認証情報を管理します。APIキーは環境変数に存在し、OAuthトークンは設定ファイルに保存されます。長期間有効な静的シークレットは、ローテーションするために存在するすべての場所を追跡する必要があるため、サーバー全体に蓄積されます。
558,000回以上ダウンロードされたOAuthプロキシであるmcp-remoteにおけるCVE-2025-6514は、MCPセキュリティリスクのサプライチェーンの側面を示しました。悪意のあるMCPサーバーが細工された認証URLを送信し、mcp-remoteがそれを直接システムシェルに渡すことで、リモートコード実行が達成され、そのマシン上のすべての認証情報が公開されました。
多くのMCPサーバーは、サービス認証情報を平文またはメモリに保存しています。侵害されたサーバーが1台あるだけで、そのサーバーが保持するすべての認証情報が漏洩します。認証情報が分散している場合、それらを一元的にローテーションする場所がなく、ローテーションが完了したかどうかを確実に検証する方法もありません。
.webp)
エージェントの脆弱性が運用に与える影響
従来のAPIコール侵害に対処してきたセキュリティチームは、明確なフォレンジックパスを持っていました。リクエストが来て、ログに記録され、何が起こったかを追跡できました。MCPはそのモデルを破壊します。
間接的なプロンプトインジェクション攻撃は、明白な痕跡を残しません。AIエージェントはログが示す通りに動作しました。つまり、ドキュメントを読み込み、ツール呼び出しを実行したのです。ドキュメントに悪意のあるプロンプトが含まれていたという事実は、異常なネットワークパターンのみを監視するツールには見えません。
メモリポイズニングはこれをさらに悪化させます。研究者たちは、複数のインタラクションにわたってエージェントのコンテキストに注入された悪意のあるコードが、個々のインタラクションが疑わしく見えないまま、エージェントの動作を徐々に変化させる攻撃を記録しています。The 脆弱なMCPプロジェクト、SentinelOne、Snyk、Trail of Bits、CyberArkの32名の研究者によって維持されており、現在、MCPエコシステム全体で50の脆弱性を追跡しており、そのうち13はクリティカルです。
The シスコ AIセキュリティ現状レポート 2026 は、組織のわずか29%しか、エージェント型AIアプリケーションを保護する準備ができていると感じていないことを明らかにしました。残りの71%は、適切に監視できないAIエージェントを運用しており、外部データソースやファイルシステムアクセス接続全体にわたって重大なセキュリティリスクを生み出しています。
.webp)
従来のセキュリティツールが機能しない理由
ほとんどの企業は、まず既存のセキュリティインフラをMCPの導入に適用します。しかし、それは機能しません。何に置き換えるかを選択する前に、その理由を理解することが重要です。
レガシーAPIゲートウェイは意味的コンテキストを欠いている
従来のAPIゲートウェイはHTTPトラフィックを検査します。ヘッダーをチェックし、レート制限を適用し、トランスポート層の認証トークンを検証します。しかし、ユーザーの入力ペイロードの内容を読み取って、含まれる命令が正当なものか、それとも注入されたものかを判断することはできません。
ネットワークレベルで見ると、20の連続したツール呼び出しをトリガーするAIエージェントタスクは、20の認証済みHTTPリクエストのように見えます。どれもレート制限のしきい値を超えず、ヘッダーチェックも失敗しません。ゲートウェイは終始クリーンなトラフィックと認識します。間接的なプロンプトインジェクションは、エージェントが処理したドキュメントの内部、つまり3層上で発生しました。
レガシーゲートウェイをAIアシスタント対応にするためのカスタムミドルウェアを記述することは、行き止まりです。エージェントの動作が進化するにつれて絶え間ないメンテナンスが必要となり、悪意のあるアクターが回避策を見つけられるような脆弱なカバレッジしか生み出しません。
SaaS AIプラットフォームがデータ流出のリスクをもたらす
マネージドAIアプリケーションオーケストレーションプラットフォームは、デプロイメントの問題を解決しますが、別の問題を生み出します。内部のMCPトラフィックがセキュリティ制御を適用するためにサードパーティのSaaSレイヤーを経由すると、独自のデータ、外部データ、ツールリクエスト、AIエージェントの出力が、すべてのインタラクションでネットワーク境界を離れてしまいます。
医療、金融サービス、または政府機関にとって、それはSaaSベンダーが信頼できるかどうかに関わらず、コンプライアンス違反となります。HIPAAは、承認されていないサードパーティのインフラストラクチャを介したPHIの転送を許可していません。GDPRは、ユーザーデータがどこを流れるかについて、実証可能な制御を要求します。SaaSルーティングレイヤーは、これら両方を破綻させます。
これらのプラットフォームはまた、RBAC、監査ログ、ツールごとのアクセス制御を含む、実際に必要とする堅牢なセキュリティ制御機能を、エンタープライズ価格帯の背後に閉じ込める傾向があります。維持できるセキュリティ体制は、契約ティアに依存します。
TrueFoundryはMCPセキュリティ課題をどのように解決するか?
TrueFoundryのMCPセキュリティへのアプローチは、他社の環境を経由するのではなく、お客様の環境内のインフラ層でセキュリティ制御を適用することです。その MCPゲートウェイ はお客様のAWS、GCP、またはAzureアカウント内に完全にデプロイされます。
すべてのAIエージェントのリクエスト、ツール呼び出し、モデルとのやり取りは、お客様のネットワーク境界内に留まり、外部システムからのアクセスやデータ取得による重大なセキュリティリスクに、コンプライアンス上の例外なく対処します。
お客様のVPC内で管理されるゲートウェイ
すべてのMCPトラフィックは、お客様の境界内に留まります。ディスカバリリクエスト、ツールペイロード、AIエージェントの出力が外部インフラを経由することはありません。これにより、SaaS経由のプラットフォームに伴うデータアクセス流出のリスクが排除され、例外処理や補償制御なしに、規制対象業界のデータソースの所在要件を満たします。
Innovaccerは、HIPAAに準拠した臨床ワークフロー全体で、毎月約1,700万件のAI推論リクエストを処理しており、これらはすべて彼らのAWS GovCloud環境内で実行されています。すべてのやり取りは、彼らのクラウド境界内に留まります。監査証拠は彼ら自身のログにあり、要求があればいつでもレビュー担当者に提示できます。これが MCPセキュリティのベストプラクティス がエンタープライズ規模でどのようなものかを示しています。
サーバーごとのRBAC適用
アクセス制御ポリシーは、リクエストがモデルやMCPサーバーに到達する前にツールレベルで適用され、 TrueFoundry AIゲートウェイを通じてMCPセキュリティのベストプラクティスが実装されます。カスタマーサポートAIエージェントはCRM検索ツールを参照できますが、データベース書き込み操作は参照できません。財務エージェントは支払い記録を照会できますが、外部送金を開始することはできません。
TrueFoundryは、Okta、Azure AD、およびカスタムSSO設定と統合します。AIエージェントは、リクエスト元のユーザーの正確な権限を OAuth 2.0 On-Behalf-Ofフローを通じて継承します。共有サービスアカウントはありません。すべてのツール呼び出しは特定の人間IDに帰属し、規制対象業界でのMCP導入を非常に困難にしているconfused deputy問題を解決します。
完全な監査ログ機能
すべてのリクエストは、ユーザーID、AIエージェントID、モデル、ツール、引数、応答、レイテンシ、コスト、および適用されたポリシーといった完全なメタデータとともにログに記録されます。ログは構造化されており、お客様自身の環境に保持され、Grafana、Splunk、Datadog、または既存のオブザーバビリティパイプラインへの統合のためにJSON形式でエクスポート可能です。
Innovaccerは、TrueFoundryのOpenTelemetry出力を利用して、本番環境のGrafanaダッシュボードにデータを供給しています。SOC 2監査人がアクセス制御の証拠を要求した場合や、HIPAAレビューで機密情報処理の証明が必要な場合、その答えは彼ら自身のログにあり、MCPセキュリティの証拠のためにサードパーティプラットフォームに依存することなく、すぐに提示できます。
仮想サーバーの抽象化
バックエンドツールの実装は、レジストリ内の仮想抽象化レイヤーの背後にあり、サプライチェーンのMCPセキュリティリスクから保護します。ツールの基盤となるサービスが変更された場合や、侵害されたMCPツールインスタンスを交換する必要がある場合でも、それに依存するAIエージェントに影響を与えることなく、レジストリレベルで変更が行われます。
これはツールポイズニング問題にも対処します。ツール定義はレジストリを通じてバージョン管理されます。レジストリは各ツールが登録時にどのような状態であったかの履歴を保持しているため、インストール後にツール記述メタデータを密かに変更するツールは検出可能であり、コミュニティ提供のMCPコンポーネントにおける悪意によって引き起こされるMCPセキュリティリスクを排除します。
この TrueFoundry Agent Gateway は、この保護をマルチエージェントワークフローに拡張し、エージェントごとのアクセス制御と、意図しないアクションがMCPエコシステム全体に連鎖する前に停止させるサーキットブレーカーを適用します。
.webp)
結論:リスク軽減のためのガバナンス確立
MCPはAIエージェントの能力を向上させるために構築されましたが、セキュリティは当初の設計に含まれていませんでした。そのギャップこそが現在の企業リスクの源であり、自然に解消されることはありません。2026年1月から2月の間に、研究者は60日間でMCPインフラストラクチャに対して30件のCVEを提出しました。プロトコルは、それを取り巻くセキュリティ対策よりも速く成長したのです。
このギャップを埋めるには、プロトコルに含まれていない制御を追加する必要があります。具体的には、すべての接続におけるID検証、ツールレベルでのアクセス制御、一元化された資格情報管理、破壊的な操作に対する人間の承認、そして自社環境内に保持される構造化された監査ログです。
TrueFoundry はその基盤を提供します。ガバナンスはプラットフォームに組み込まれており、アドオンとして追加料金がかかることはありません。データは貴社のクラウドに留まり、監査証跡は貴社のものです。そして、断片化したMCPサーバーの集合体から、エージェントアーキテクチャをゼロから再構築することなく、統制され監査可能なコントロールプレーンへと移行できます。
デモを予約する 今日から始めましょう。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.


Recent Blogs
Frequently asked questions
MCPセキュリティにはどのような問題がありますか?
MCPセキュリティにおける根本的な問題は、AIエージェントとMCPツール間の通信方法を定義するモデルコンテキストプロトコル(MCP)自体に、強力な認証、アクセス制御、監査ログを強制する仕組みが備わっていない点にあります。
ガバナンス層が存在しないため、MCPのセキュリティリスクとして、認証なしで実行されるサーバーや、過剰な権限で動作するAIエージェントといった問題が生じています。「Vulnerable MCP Project」の調査によると、現在MCPエコシステム全体で50件の脆弱性が確認されており、調査対象となった実装の38%から41%が認証機能を全く備えていないことが明らかになっています。
プロンプトインジェクションは、どのようにしてMCPの脆弱性を悪用するのでしょうか?
プロンプトインジェクションは、AIエージェントが処理するコンテンツ(要約対象のドキュメント、転送するメール、読み込むWebページなど)の中に悪意のあるプロンプトを埋め込むことで実行されます。MCPクライアントは外部データと指示を確実に区別できないため、埋め込まれた指示を正当なものとして扱い、自身のアクセス制御権限を使用して実行してしまいます。
MCP環境において間接的なプロンプトインジェクションが成功すると、Supabase Cursorの事例で示されたように、機密データの流出、レコードの改ざん、あるいは外部システムへのAPI呼び出しが実行される恐れがあります。
なぜサードパーティ製のMCPサーバーはサプライチェーンリスクと見なされるのでしょうか?
多くのMCPサーバーは、体系的なセキュリティレビューを経ることなくパブリックレジストリからダウンロードされており、MCPのサプライチェーンにおけるセキュリティリスクを生んでいます。トレンドマイクロは、認証が一切設定されていない状態でインターネットに公開されているMCPサーバーを492件確認しました。また、55万8,000回以上ダウンロードされているパッケージ「MCP-remote」では、CVE-2025-6514の脆弱性が確認されています。
環境内に取り込まれるサードパーティ製のMCPサーバーはすべて、悪意のあるコードの侵入、APIキーの窃取、あるいはツールポイズニングの入り口となる可能性があり、MCPアーキテクチャ層において機密情報が侵害されるリスクを孕んでいます。
企業はどのようにしてMCPサーバー上のアクセス制御を強制できるのでしょうか?
効果的なMCPセキュリティを実現するには、すべてのAIエージェントのリクエストを検証済みのユーザーIDに紐付ける「ID認識型の強力な認証」、エージェントが自身の役割で許可された操作のみを実行できるようにする「ツールレベルのロールベースアクセス制御」、そしてリクエストがサーバーに到達する前にMCPセキュリティのベストプラクティスを適用する「一元化されたゲートウェイ」が不可欠です。
TrueFoundryのようなプラットフォームは、これら3つの要素をインフラストラクチャ層に組み込んでいます。これにより、各MCPサーバーで個別にセキュリティ制御コードを記述することなく、すべてのMCP接続に対して一貫した強固なセキュリティを適用できます。
なぜ従来のAPIセキュリティではAIエージェントに対して不十分なのでしょうか?
従来のAPIゲートウェイはトランスポート層で動作し、HTTPヘッダーに基づいてレート制限を適用します。そのため、ユーザー入力のペイロードを解析したり、ツール呼び出しが正当な指示によるものか、あるいはドキュメント内に隠されたコマンドインジェクションによるものかを判断したりすることはできません。
SSRFの脆弱性があるサーバーを介して20回連続でツール呼び出しを行うAIエージェントは、一見すると正常なトラフィックを生成します。MCPのセキュリティリスクに対処するには、単なるトラフィックパターンではなく、MCPコンポーネントのセマンティクスを理解する制御が必要です。これこそが、AIインフラストラクチャのセキュリティが解決すべき根本的な課題です。
MCPセキュリティにおいて、MCPゲートウェイはどのような役割を果たしますか?
MCPゲートウェイは、AIエージェントとそれらが接続するMCPサーバーの間に配置され、プロトコル自体には含まれていないMCPのセキュリティ強化レイヤーを提供します。ガバナンス機能を備えたゲートウェイは、ID検証の処理やMCPツールレベルでのRBAC(ロールベースのアクセス制御)の適用を行い、エージェントが許可された範囲にのみアクセスできるように制御します。また、
APIキーを一元管理し、プロンプトインジェクションのパターンを検知してユーザー入力をフィルタリングするほか、セキュリティおよびコンプライアンス監査のためにすべてのやり取りを完全なメタデータとともに記録します。ゲートウェイがない場合、MCPの導入環境全体においてセキュリティリスクが放置されることになります。












.webp)
.webp)


.png)

.png)














