2026年におけるMCPのセキュリティリスクとベストプラクティス

Anthropicが2024年後半にモデルコンテキストプロトコルをリリースした際、それは実際の問題を解決しました。AIエージェントが使用する必要のあるツールごとにカスタム統合コードを書く代わりに、チームは標準化されたインターフェースを通じて、エージェントをデータベース、API、および内部システムに接続できるようになりました。導入は急速に進み、2025年までに数万台のMCPサーバーが企業環境全体に展開されました。

しかし、その導入の速さは、ほとんどの組織が準備できていなかったギャップを露呈しました。MCPはAIエージェントの能力を向上させるために設計されましたが、エンタープライズセキュリティを第一の原則として設計されたわけではありません。元の仕様には必須の認証フレームワークが含まれておらず、暗黙の信頼モデルはMCPサーバーが無害であると仮定していました。また、それらのサーバーが公開するツールは、新たな攻撃対象ではなく、適切に動作するシステムの出力として扱われていました。

セキュリティ研究者たちは、その結果を迅速に記録しました。CVSSスコア9.4のCVE-2025-49596は、認証されていないMCP Inspectorインスタンスが悪用され、任意のコマンドを実行できることを示しました。Invariant Labsは、悪意のあるMCPサーバーがWhatsAppのメッセージ履歴全体を密かに持ち出すことができることを実証しました。2025年6月に発生したSupabase Cursorエージェントのインシデントでは、ユーザーが提供したサポートチケットを処理する特権エージェントが、プロンプトインジェクションによって統合トークンを漏洩するように騙される可能性があることが示されました。

これらは、不十分に構築された実験による特殊なケースではありません。MCPのアーキテクチャは、従来のセキュリティツールでは認識できない攻撃対象領域を生み出すため、これらは実際の運用システムで発生しました。 

本記事では、企業が直面する具体的なMCPセキュリティリスク、それらに対処する制御策、そして、それらの制御策を適用するために用いるアプローチが、制御策そのものと同じくらい重要である理由について解説します。

Your AI Agents Have Access to Everything, Does Your Security?

TrueFoundry enforces identity-aware execution and granular RBAC inside your private cloud environment.

Book Demo

企業が直面する主要な5つのMCPセキュリティリスク

これらは、MCPの導入において最も一般的に遭遇する5つのMCPセキュリティリスクです。

過剰な特権を持つエージェントアクセス

開発者がAIエージェントを企業システムに初めて接続する際、彼らは通常、すでにアクセス権を持つ認証情報、多くの場合、管理者レベルのAPIキーや広範な権限を持つサービスアカウントを使用します。それは、開発中に認証エラーに遭遇することなくエージェントを動作させたいと考えるためです。問題は、エージェントが本番環境に移行する前に、それらの広範な権限が絞り込まれることがほとんどない点です。

MCPの脆弱性を追跡するために特別に立ち上げられたOWASP MCP Top 10プロジェクトは、過剰な特権アクセスを根本的なリスクとして特定しています。顧客サポートエージェントがデータベース管理者と同じ認証情報を持っている場合、そのエージェントに対する一度の攻撃が成功しても、サポートキューが露呈するだけではありません。データベースが露呈します。いかなる侵害の爆発半径も、エージェントに与えられたアクセス権の量に直接比例します。

これは理論上の懸念ではありません。Supabaseのインシデントでは、攻撃者が制御するコンテンツを含む入力を処理する、特権的なサービスロールアクセスを持つエージェントが関与していました。その特権レベルが攻撃を可能にしました。サポートデータへの読み取り専用アクセスに限定されたエージェントであれば、統合トークンを持ち出すための認証情報を持っていなかったでしょう。

外部コンテンツを介したプロンプトインジェクション

プロンプトインジェクションは、OWASP Top 10 for LLM Applications 2025で最も重要な脆弱性としてランク付けされており、単純なチャットボットの導入とは異なり、MCP環境では異なる性質を帯びます。エージェントがアクションを実行する能力を持つ場合、インジェクションが成功しても、単に不適切な出力が生成されるだけではありません。メール送信、API呼び出し、レコード変更、外部アドレスへのデータ転送など、実際の操作を引き起こす可能性があります。

攻撃パターンは間接的です。攻撃者はあなたのシステムへのアクセスを必要としません。彼らは、エージェントが通常の作業の一部として処理するコンテンツ（要約を依頼されたPDF、ルーティングする顧客メール、調査のために読み込むウェブページなど）に悪意のある指示を埋め込みます。エージェントはコンテンツを読み込み、埋め込まれた指示に遭遇すると、言語モデルがコンテキストを処理する方法においてデータと指示の間に明確な境界がないため、それらの指示を正当なものと解釈し、それに基づいて行動します。

2022年からこの問題を追跡しているセキュリティ研究者のサイモン・ウィリソン氏は、次のように述べています。「プロンプトインジェクションの厄介な点は、この問題が2年半以上前から知られているにもかかわらず、未だに説得力のある緩和策がないことです。」

MCPの仕様書自体もこのリスクを認識しており、常に人間が関与すべきであると指摘しています。

ツールポイズニングとラグプル攻撃

MCPエージェントはツールのメタデータを信頼します。エージェントがMCPサーバーに接続し、利用可能なツールのリストを要求すると、サーバーはツール名、説明、パラメータスキーマで応答します。エージェントはそのメタデータを使用して、どのツールをどのように呼び出すかを決定します。ツールポイズニングはこの信頼関係を悪用します。

ツールポイズニング攻撃では、攻撃者はツールのメタデータを作成または侵害し、隠された指示を含ませます。ツールの説明は目視では正常に見えますが、エージェントに有害なアクションを実行させたり、データを外部に持ち出させたり、自身の権限を昇格させたりする埋め込まれた指示が含まれています。悪意のあるコンテンツはユーザー入力ではなくツール定義内にあるため、ユーザー向けのコンテンツのみをチェックする入力検証レイヤーを回避します。

Invariant Labsは2025年にその亜種を実証し、正当なWhatsApp MCPサーバーと同じエージェントコンテキストにある悪意のあるMCPサーバーが、ツールポイズニングを使用してユーザーのメッセージ履歴全体を密かに読み取り、エクスポートできることを示しました。この攻撃には、ユーザーエラーやネットワークレベルの悪用は不要でした。

関連する攻撃としてラグプルがあります。これは、ツールがインストール時には正当に動作し、ユーザーが権限を付与した後に密かにその動作を変更するものです。MCPサーバーはクライアントに通知することなくツール定義を更新でき、ほとんどのクライアントはその変更をフラグ付けしたり検出したりしません。 

管理されていないMCPサーバー全体での認証情報の乱立

一元化された認証情報管理がない環境では、各MCPサーバーが独自の認証設定を維持します。開発者はAPIキーを環境変数に保存し、ハードコードします OAuth トークンを設定ファイルに記述し、短命なスコープ付きトークンよりも管理が容易であるため、長期間有効なサービスアカウント認証情報を使用します。MCPデプロイメントを追跡した調査では、基本的な認証または暗号化を欠く492の公開されたMCPサーバーが発見されました。

Cloudflare、Hugging Face、Auth0の統合で使用され、437,000回以上ダウンロードされているOAuthプロキシであるmcp-remoteにおける深刻なOSコマンドインジェクションの脆弱性CVE-2025-6514は、このリスクのサプライチェーンの側面を示しました。 

悪意のあるMCPエンドポイントは、細工された認証URLを送信する可能性があり、それをmcp-remoteがシステムシェルに直接渡すことで、クライアントマシン上でリモートコード実行を達成し、そのマシンに保存されているAPIキー、クラウド認証情報、ローカルファイル、SSHキーへのアクセスを提供する可能性があります。

コンプライアンス違反を引き起こす監査の死角

標準的なMCPサーバーは、構造化された、コンプライアンス対応の形式で実行コンテキストをログに記録しません。ツールが呼び出されたことはログに記録するかもしれませんが、通常、リクエストがどの人間ユーザーから発信されたか、呼び出し時点でのエージェントの推論、どのようなデータが返されたか、または操作が許可される前にアクセスポリシーが参照されたかどうかはログに記録しません。

SOC 2、HIPAA、またはGDPRの下で運用する企業にとって、これは軽微なギャップではありません。SOC 2はデータ管理および処理制御の証拠を要求します。HIPAAは、保護された医療情報に触れるすべてのシステムアクセスについて、識別可能なユーザーまたはサービスに帰属する監査証跡を要求します。GDPRは、どのようなデータが、いつ、誰によって処理されたかを実証する能力を要求します。構造化された監査ロギングがないMCPデプロイメントは、これらすべての要件を同時に満たしません。

2025年の企業環境におけるAIシステム利用に関する調査では、AIシステムの30%未満しかエージェントツールアクセスの構造化された監査証跡を持っておらず、15%未満しかエージェントアクションの意思決定パス全体を再構築できなかったことが判明しました。

その環境でセキュリティインシデントが発生した場合、調査は不完全なログからのフォレンジック再構築に依存するため、インシデント対応時間が数週間延長され、監査人向けの証拠を作成することがほぼ不可能になります。

必須のMCPセキュリティベストプラクティス

上記のMCPセキュリティリスクには共通点があります。それらはすべて、AIエージェントとそれらがアクセスするシステムとの間に制御された境界がないことに起因します。以下に示す各ベストプラクティスは、攻撃が発生するレイヤーでその境界を確立し、強制するように設計されており、事後的に行うものではありません。

ID認識型実行の強制

どのようなMCPデプロイメントにおいても、最も重要なアーキテクチャ上の決定は、AIエージェントのIDがどのように管理されるかです。共有サービスアカウントは、いかに多くのログがあっても埋めることのできない説明責任のギャップを生み出します。5つのエージェントが1組の認証情報を共有している場合、特定のアクションを特定のエージェントに、ましてやそれをトリガーした人間ユーザーに帰属させる方法はありません。

適切なアプローチは、On-Behalf-Of (OBO) 認証です。これは、各AIエージェントのリクエストが、それを開始した人間のユーザーと全く同じ権限を保持し、行使するものです。開発者がMCP接続エージェントを介してデータソースを照会する場合、その操作は、サーバーに設定されている管理者レベルの認証情報ではなく、開発者のアクセスレベルで行われます。アクセスは、その人物が組織内の他の場所で許可されている範囲に限定されます。

これには、Okta、Azure AD、またはカスタムSSO設定など、企業のIDプロバイダーとの統合が必要です。これは、トークンがユーザーにスコープされ、短命で自動的に更新される動的なクライアント登録と認可コードフローを意味します。手動で取り消されるまで存続する長寿命の静的キーとは異なります。

ツールレベルで詳細なロールベースアクセス制御を適用する

本番環境のMCPデプロイメントでは、サーバーレベルのアクセス制御は粗すぎます。ユーザーまたはエージェントがMCPサーバーにアクセスできるかどうかを制御することは出発点に過ぎません。実際に必要なのは、そのサーバー内のどの特定のツールを各ロールが呼び出せるかを制御する機能です。

実用的な要件は次のとおりです。顧客サポートエージェントはCRMサーバーで読み取り操作を呼び出すことはできますが、削除操作はできません。財務エージェントは支払い記録を照会できますが、外部送金をトリガーすることはできません。これらの区別は、サーバーレベルのアクセスポリシーでは表現できません。これにはツールレベルのRBACが必要です。サーバー内の各ツールが独自の認可要件を持ち、それらの要件は呼び出しごとに評価されます。

MCP仕様の2026年更新では、インクリメンタルスコープ同意が導入され、クライアントはすべての権限を事前に要求するのではなく、各操作に必要な最小限のアクセスのみを要求できるようになりました。これを実装するには、ネットワークレベルのルーティングだけでなく、ツールレベルのセマンティクスを理解する認可レイヤーが必要です。

不可逆的なアクションには人間の承認を必須とする

エージェントは、人間のチェックポイントなしに破壊的または高リスクな操作を実行できるべきではありません。データベースの削除、外部データ転送、金融取引、一括記録変更、および外部通信はすべて、誤った指示や注入された指示が、元に戻すのが困難または不可能な損害を引き起こす可能性がある操作です。

MCP仕様はこれを明示的に認めています。ツール呼び出しを拒否する能力を持つ人間が常にループ内にいるべきです。これを実際に実装するには、 MCPツール にリスク分類を付与し、破壊的または不可逆的とタグ付けされた操作に対して承認フローを強制することです。エージェントは実行前に意図されたアクションとその引数を提示し、明示的な人間の承認を待ちます。

これは単なる安全メカニズムではありません。プロンプトインジェクションの緩和策でもあります。人間の承認なしには実行できない注入された指示は、密かにデータを持ち出すことはできません。承認ステップは、入力レイヤーでの検出が失敗した場合でも、実行レイヤーで攻撃チェーンを断ち切ります。

ツール接続を単一の統制されたレジストリに統合する

個々のエージェントと個々のMCPサーバー間のポイントツーポイント接続が、リスクセクションで説明されている可視性のギャップとガバナンスの失敗を生み出します。各チームが独自のサーバー接続を管理している場合、どのようなツールが存在し、誰がそれらにアクセスでき、現在本番環境で何が呼び出されているかを確認できる一元的な場所はありません。

統制された中央レジストリがこれを変えます。ツールは一度登録されます。アクセスポリシーは一度定義され、一貫して適用されます。ツールが更新または廃止された場合、その変更は一箇所に反映され、エージェントは廃止されたエンドポイントを呼び出し続けたり、変更を知らされなかったために機能しなくなったりすることなく、自動的にそれを認識します。セキュリティチームは、常に遅れをとっているスプレッドシートではなく、単一のインベントリを入手できます。

レジストリは、ラグプルリスクも軽減します。ツール定義が一元的に管理されている場合、ツールメタデータへの変更はバージョン管理され、監査可能です。インストール後に自身の説明を密かに変更するツールは、レジストリが各ツールが登録時にどのようなものであったか、現在どのようなものであるかの履歴を保持しているため、検出可能です。

包括的で構造化された監査ログを維持する

すべての認証イベント、トークン発行、ツール呼び出し、およびポリシー決定は、誰がリクエストを行ったか、どのエージェントが実行したか、どのツールが呼び出されたか、どのような引数が渡されたか、何が返されたか、およびポリシーが適用されたかまたは上書きされたかを含む構造化されたメタデータとともにログに記録されるべきです。

ログがあることと、コンプライアンス対応のログがあることの間には、大きな違いがあります。 監査ログ ツール名とタイムスタンプを記録するログは、狭い技術的要件を満たすに過ぎません。一方、ユーザーID、エージェントID、完全なリクエストコンテキスト、適用されたポリシー、および出力コンテンツを、オンデマンドでクエリおよびエクスポート可能な構造化形式で記録するログは、SOC 2、HIPAA、およびGDPRの要件を満たします。これらは異なるものであり、その間のギャップがほとんどの監査失敗の原因となっています。

ログは自社の環境内に保持されるべきです。サードパーティのSaaSシステムに存在するログは、完全に管理下に置くことができず、確実なオンデマンド生成が不可能であり、また、コンプライアンスフレームワークが要求するデータ処理制限と矛盾するデータ処理制限の対象となる可能性があります。

現在の市場ソリューションの欠陥

MCPセキュリティソリューションとして販売されているツールは数多く存在します。問題は、それらのツールがセキュリティ脆弱性が実際に発生するレイヤーでMCPセキュリティ問題に対処しているのか、それともより具体的な対策が必要な問題に対して汎用的な制御を適用しているのか、という点です。

• レガシーなAPIゲートウェイはエージェントの意図を読み取れません。 従来のAPIゲートウェイは、サービス間のHTTPトラフィックのために構築されました。これらはヘッダーを検査し、レート制限を適用し、トランスポート層でMCP認証を行います。20種類の異なるMCPツールへのツール呼び出しをトリガーするAIエージェントタスクは、ネットワークレベルでは正当で認証されたリクエストのシーケンスとして見えるトラフィックを生成します。HTTPエンベロープには、それらのリクエストがユーザーアクションによって駆動されたものか、エージェントが3ステップ前に読み込んだドキュメントに埋め込まれた注入された指示によるものかを示すものは何もありません。MCPプロトコルのセマンティクスを解析できないゲートウェイは、AIアプリケーションに対するセマンティックレイヤーの攻撃ベクトルを検出または阻止できません。

• マネージドSaaSプラットフォームは、お客様が制御できないインフラストラクチャを介してデータをルーティングします。 クラウドホスト型AIプラットフォームはデプロイメントの問題を解決しますが、データレジデンシーの問題を引き起こします。AIエージェントのツール検出リクエストやMCPインタラクションがサードパーティのクラウドを経由すると、機密情報がすべてのインタラクションでネットワーク境界を離れます。HIPAA、GDPR、または金融サービスにおけるデータレジデンシー義務を負う組織にとって、これは AIコンプライアンス SaaSベンダー自身のセキュリティ体制が適切であるかどうかにかかわらず存在するリスクとなります。他社のインフラストラクチャを信頼するだけでは、データレジデンシー要件を満たすことはできません。これは、ユーザーデータにアクセスできるリモートMCPサーバーを運用するチームにとって、深刻なセキュリティ上の懸念となります。

• DIYのオープンソース構成は、大規模になると破綻します。 オープンソースコンポーネントからカスタムプロキシを構築することは、ベンダー費用を回避し、エンジニアリングチームに最大限の制御を与えますが、管理チームの成長よりも速く増大するメンテナンス義務を生み出します。静的なYAMLまたはJSONファイルによるツール登録は、新しい統合ごとに手動編集、コードレビュー、デプロイメントが必要であることを意味します。設定ファイルに記述されたRBACポリシーはリアルタイムで変更できません。監査ロギングには、すべてのサーバーに対するカスタムインストルメンテーションが必要です。少数のエージェントを管理している場合は、これは管理可能です。しかし、数十のエージェントを管理するようになると、これはフルタイムのプラットフォームエンジニアリングの問題となります。

Legacy Gateways Cannot Read Agent Intent, Your MCP Security Layer Must

Get semantic-aware governance, credential vaulting, and SOC 2 audit trails built in with TrueFoundry.

Book Demo

TrueFoundryによるエージェントワークフローの保護

TrueFoundryの MCPゲートウェイ は、企業が本番環境でMCPを安全に実行するために必要な制御は、既存のインフラストラクチャに後付けできるものではなく、インフラストラクチャの一部である必要があるという前提に基づいて構築されています。

このゲートウェイは、お客様のAWS、GCP、またはAzure環境内に完全にデプロイされます。すべてのツールリクエスト、すべての検出呼び出し、すべてのプロンプトと応答のペアは、組織のネットワーク境界内に留まります。データパスにはSaaSルーティングレイヤーやサードパーティのインフラストラクチャは存在しません。データ流出のリスクを生み出す外部依存関係もありません。これはコンプライアンスだけでなく、脅威モデルにとっても重要です。環境を離れないデータは、転送中に傍受されることはありません。

• OAuth 2.0のOn-Behalf-OfフローによるIDインジェクション： エージェントは、組織の既存のIDプロバイダーを介して継承された、リクエスト元のユーザーの正確な権限の下で動作します。Okta、Azure AD、およびカスタムSSO設定がすぐに利用可能です。共有サービスアカウントはなく、すべてのツール呼び出しは特定の人間IDに帰属され、あらゆるコンプライアンスレビューに耐えうる説明責任チェーンを生成します。

• ゲートウェイ層で適用されるツールレベルのRBAC： アクセス ポリシーは、リクエストがモデルやツールに到達する前に適用されます。レジストリは、各ロールまたはチームが使用を許可されているツールのみを公開し、接続されているすべてのサーバーの全機能は公開しません。サポート担当者はCRM検索ツールを参照できますが、データベース管理コマンドは参照できません。この区別は、開発者の慣習ではなく、プラットフォームレベルで強制されます。

• サプライチェーン保護のための仮想MCPサーバーの抽象化： バックエンドツールの実装は、レジストリ内の仮想抽象化レイヤーの背後にあります。ツールの基盤となる実装が変更された場合、または侵害されたツールを交換する必要がある場合、その変更は、それに依存するエージェントに影響を与えることなくレジストリで行われます。これにより、エージェントはラグプル攻撃からも保護されます。ツールの定義はレジストリを通じてバージョン管理され、ツールメタデータへの変更は追跡および監査可能です。

• 高リスク操作に対するヒューマン・イン・ザ・ループ承認フロー： ツールにはリスク分類を付与できます。破壊的または不可逆的とタグ付けされた操作は、実行前に明示的な人間の承認を必要とします。これはツールごと、ロールごとに設定可能であるため、チームはデータベース削除に承認を要求しつつ、読み取りは中断なく続行させることができます。

• お客様自身の環境内に保持される構造化された監査ログ： すべてのリクエストは、ユーザーID、エージェントID、モデル、ツール、引数、応答、適用されたポリシー、レイテンシー、コストといった完全なメタデータとともにログに記録されます。ログは顧客自身のインフラストラクチャに保持され、Grafana、Splunk、Datadog、または既存のオブザーバビリティパイプラインとの統合のために構造化されたJSON形式でエクスポートできます。Innovaccer社は、AWS GovCloudでHIPAAに準拠し、毎月約1,700万件のAI推論リクエストを処理していますが、OpenTelemetryを介したTrueFoundryの構造化テレメトリを使用し、Grafanaでそれを閲覧しています。機密データがクラウド境界を離れることはありません。

TrueFoundryのAI Gatewayを体験してみませんか？ 今すぐデモを予約する!

まとめ：MCPを本番環境で安全に運用する

MCPは統合問題を解決しましたが、ガバナンス問題は解決しませんでした。2025年に企業環境に展開された数万台のMCPサーバーは、膨大な量の新しい機能を生み出す一方で、ほとんどの組織が管理する準備ができていなかった攻撃対象領域の著しい拡大ももたらしました。

Supabase、Asana、Atlassian、mcp-remote CVEなど、すでに発生したインシデントは、エンジニアリングの不備によって引き起こされたものではありません。それらは、企業の本番環境のセキュリティ要件を考慮していないアーキテクチャによって引き起こされました。基本プロトコルは、これらの要件を念頭に置いて構築されていませんでした。

本番環境で実際に機能する方法でMCPのセキュリティリスクに対処するには、インフラストラクチャ層で制御を強制する必要があります。具体的には、ID認識型実行、ツールレベルのアクセス制御、一元化された資格情報管理、破壊的操作に対する人間の承認、およびお客様自身の環境に保持される構造化された監査ログです。これらは、規制対象業界にとってオプション機能ではありません。ビジネスクリティカルなシステムに触れるAIエージェントを実行するための基本要件です。

TrueFoundry これらすべての制御をお客様自身のクラウド内に展開します。お客様のデータは、お客様のガバナンスが適用される場所に留まります。お客様の監査ログは、お客様のスケジュールで生成、クエリ、エクスポートできます。