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.
The fastest way to build, govern and scale your AI


Recent Blogs
Frequently asked questions
What are the problems with MCP security?
The core MCP security problem is a model context protocol that defines how AI agents communicate with MCP tools but provides no native enforcement of strong authentication, access control, or audit logging.
Without a governance layer, MCP security risks include servers running without authentication and AI agents operating with excessive permissions. The Vulnerable MCP Project currently tracks 50 vulnerabilities across the MCP ecosystem, with 38% to 41% of surveyed implementations having no authentication at all.
How do prompt injections exploit MCP vulnerabilities?
Prompt injection works by embedding malicious prompts inside content an AI agent processes: a document it summarizes, an email it routes, or a web page it reads. The MCP client cannot reliably distinguish between external data and instructions, so it treats embedded directives as legitimate and executes them using its own access control credentials.
In MCP environments, a successful indirect prompt injection can exfiltrate sensitive data, modify records, or trigger API calls to external systems, as demonstrated by the Supabase Cursor incident.
Why are third-party MCP servers considered a supply chain risk?
Most MCP servers are downloaded from public registries without systematic security review, creating supply chain MCP security risks. Trend Micro found 492 internet-exposed MCP servers with zero authentication. CVE-2025-6514 affected MCP-remote, a package with over 558,000 downloads.
Any third-party MCP server pulled into your environment is a potential entry point for malicious code, API keys theft, or tool poisoning that compromises sensitive information at the MCP architecture layer.
How can enterprises enforce access control on MCP servers?
Effective MCP security requires identity-aware strong authentication, where every AI agent request is tied to a verified user identity; role-based access control at the tool level, so agents invoke only operations their role authorizes; and a centralized gateway enforcing MCP security best practices before requests reach any server.
Platforms like TrueFoundry embed all three into the infrastructure layer, applying robust security consistently across every MCP connection without requiring custom security controls code on each MCP server individually.
Why is traditional API security insufficient for AI agents?
Traditional API gateways operate at the transport layer and enforce rate limiting on HTTP headers. They cannot parse user inputs payloads or determine whether a tool call was triggered by a legitimate instruction or command injection buried in a document.
An AI agent executing twenty sequential tool calls through an SSRF-vulnerable server generates traffic that appears clean throughout. MCP security risks require controls that understand MCP components semantics, not just traffic patterns, which is the fundamental gap that artificial intelligence infrastructure security must address.
What role does an MCP gateway play in MCP security?
An MCP gateway sits between AI agents and the MCP servers they connect to, providing the MCP security enforcement layer the protocol does not include natively. A governed gateway handles identity verification, enforces RBAC at the MCP tool level so agents only access what they are authorized to, manages
API keys centrally, filters user input for prompt-injection patterns, and logs every interaction with full metadata for security and compliance review. Without a gateway, MCP security risks are unaddressed across the entire MCP adoption deployment.










.webp)




.png)








.webp)
.webp)








