MCPにおける有害なフローとAIネイティブシステムに潜むリスクを理解する

AIセキュリティに関する議論の多くは、今もプロンプト、モデル、データへの直接アクセスに焦点を当てています。これらは重要な領域ですが、AIエージェントがツールを呼び出し、APIを実行し、複数のシステムにまたがって動作できるようになると、リスクの本質は変わります。もはや問題は、モデルが何を見られるかだけではありません。エージェントが独自にツールを組み合わせ始めたとき、何を実行できるかが問題になります。

こうした状況で重要になるのが、有害なフローという概念です。

有害なフローとは、攻撃者が制御する指示から機密データへと環境を導き、さらにそのデータを流出先へ送るエージェントの一連のアクションです。個々のステップが悪意あるものである必要はありません。それぞれのツールは、設計どおりに動作しているだけかもしれません。危険なのは、AIエージェントの制御下でツール、データ、指示が組み合わさり、エンドツーエンドの経路が作られることです。

Model Context Protocol（MCP）は、この両面を増幅させます。MCPは、モデルやエージェントがツール、リポジトリ、サービス、データソースに接続する方法を標準化します。開発チームにとって、これは大きな利点です。課題の閲覧、チケットの更新、ログの照会、コードの変更、スクリプトの実行など、日常のワークフローにAIを組み込む一貫した方法が得られます。一方でMCPは、柔軟なツール群をエージェントに提供するため、意図せず有害なフローを作り出しやすくもなります。

従来の決定論的なアプリケーションでは、特定の入力はコード内で定義された経路をたどります。エンジニアはその経路をすべて洗い出し、テストし、セキュリティ特性を検討できます。MCPベースのエージェントは異なります。自然言語の指示、コンテキスト、ツールの説明に基づき、多数のツールから選び、さまざまな順序で実行できます。考えられるすべての手順をあらかじめ明示的に記述する人はいません。モデルが実行時に経路を選択します。

この変化により、新たな種類のリスクが生まれます。モデルが機密情報やプライベートリポジトリにアクセスできるかどうかを問うだけでは不十分です。より重要なのは、どのような条件下でエージェントが機密データをツールの連鎖に通し、最終的に信頼できない相手へ公開すると判断するのか、という問いです。

この一連の経路を「有害なフロー」と呼びます。この言葉は、リスクが複数の要素の相互作用から生じることを表しています。単一の設定ミスの単純な結果ではなく、多数のコンポーネントを通じたデータと制御の流れがもたらす性質です。MCP環境では、エージェントがすでに開発環境、ソース管理、インシデント対応ワークフロー、本番環境に隣接するサービスなど、重要なシステムに接続されているため、こうしたフローを理解し、管理することが不可欠です。

致命的な三要素：ツールの連鎖が侵害につながる仕組み

エージェントの動作にはばらつきがありますが、有害なフローのパターンには驚くほど一貫性があります。実際のインシデントを調べると、単一のエージェント実行の中で、次の3つの要素が同時に現れる傾向があります。

• 攻撃者の影響を受けた指示

• 機密データへのアクセス

• そのデータを流出させる手段

この3つの条件が1つのフロー内でそろうと、関係するツールがそれぞれ正当な目的で追加されたものであっても、環境はリスクにさらされます。

多くの場合、出発点となるのは信頼できない指示です。MCP環境での指示は、チャットのプロンプトに限りません。攻撃者は、GitHubの課題、カスタマーサポートのチケット、監視対象のチャットチャンネルに投稿されたメッセージなど、エージェントが読み取るよう設定されたあらゆるオブジェクトの内容を操作できます。そうした項目のトリアージ、要約、処理を目的とするエージェントであれば、攻撃者はその推論プロセスに入り込む経路を手にしたことになります。

機密データは通常、生産性向上のために導入されたツールの先にあります。リポジトリの内容の読み取り、設定ファイルの取得、課題管理システムの照会、ログの取得、社内記録へのアクセスなどが該当します。エンジニアは、バグの修正や本番環境の問題の把握に自分が使う情報を、エージェントにも見せたいと考えます。その結果、エージェントのツール群には価値の高いデータへの直接アクセスが含まれることがよくあります。

流出先となるのは、安全な境界の外へデータを移動できるツールやチャネルです。一般的な例として、任意のURLにリクエストを送信できるHTTPクライアント、サードパーティのシステムに書き込むコネクタ、メールやチャットメッセージを送るインテグレーションなどがあります。呼び出し元が信頼できない場合は、モデルの応答自体が流出先になることもあります。チームがエージェントをより多くのワークフローに接続するにつれて、こうした機能は段階的に追加されることがよくあります。

単純なMCPのシナリオで、致命的な三要素がどのようにそろうかを見てみましょう。開発支援アシスタントを動かす、GitHubに接続されたMCPサーバーを考えてください。アシスタントはリポジトリの課題を読み、MCPツールを使って関連ファイルや設定の詳細を取得し、メンテナー向けに役立つ要約を作成します。インテグレーションテストに対応するため、任意のエンドポイントにリクエストを送信できるHTTPツールも公開されています。

攻撃者が、そのリポジトリに詳細な指示を含む課題を投稿します。その課題には、複雑なバグの原因を特定するにはコードベースから環境ファイルや設定データを収集し、特定のURLにJSONペイロードとして送信して、外部の分析システムに調査させる必要があると書かれています。エージェントから見ると、これは詳細で妥当な依頼に見えます。

エージェントがその指示に従うと、課題を読み（信頼できない指示）、リポジトリ内を調べて設定ファイルや環境ファイルを収集し（機密データ）、HTTPツールを呼び出してその情報を攻撃者のURLに送信します（流出先）。明らかな設定ミスがあるツールは一つもありません。モデルの制御下でツールが組み合わされた結果、侵害が発生します。

従来のAIセキュリティ対策では、このパターンへの対応が困難です。プロンプトフィルターやLLMファイアウォールは、個々のプロンプトと応答を検査します。一方で、プロンプトを外部システムにつなぐ中間的なツール呼び出しやデータの移動を可視化する機能は限られています。コードスキャンで検証できるのはツールの実装方法であり、実行時にどのように組み合わされるかではありません。アクセスレビューでは、各ツールに正当な用途があることを確認しますが、信頼できないコンテンツがツールを連結する一連の処理を引き起こし、有害なフローを作る可能性までは、ほとんど評価されません。

その結果、ギャップが生まれます。組織はプロンプト、モデル、ツールを保護できていると思っていても、実際のリスクはMCPを通じてオーケストレーションされる動的なアクションの連鎖に潜んでいる可能性があります。このギャップを「致命的な三要素」と捉えることで、本当の問題に焦点を当てられます。つまり、攻撃者が制御する指示、機密データ、流出経路のすべてに1つのフロー内から到達できる場合、各コンポーネントをどれほど慎重に導入していても、環境はリスクにさらされます。

多くのAIセキュリティ対策が有害なフローを見逃す理由

致命的な三要素を理解すると、現在の多くのAIセキュリティ対策が、別の種類の問題に最適化されていることが分かります。相互接続されたシステム全体でエージェントが何をするかではなく、モデルが何を見て、何を答えるかに重点を置いているのです。

組織が最初に導入する対策として一般的なのは、プロンプト制御、コンテンツフィルター、LLMファイアウォールです。これらのシステムは入出力を検査し、ポリシー違反や機密性の高い用語を探します。明白な不正利用を減らし、特定の種類のプロンプトインジェクションを防ぐことはできます。しかし、有害なフローは、一見正当な複数のステップとして進行することがよくあります。GitHubの例では、アシスタントは詳細なデバッグ依頼に従っているように見えます。中間のツール呼び出しを通じて秘密情報が流出したことは、最終的な回答からは必ずしも分かりません。

従来のアプリケーションセキュリティツールも、静的な成果物や決定論的な経路を前提としています。静的解析、ソフトウェア構成分析、Infrastructure as Codeのスキャンは、コードと設定によって許可されるすべてのアクションが定義される環境に適しています。MCPツールが安全に実装されているか、依存関係が最新か、アクセストークンが適切に管理されているかは検証できます。しかし、自然言語の入力を受けたエージェントが、予想外の方法でツールを連鎖させる判断を容易に捉えることはできません。

実行時のログ記録や監視も、さらに対策を加えるものの、この状況では制約があります。エンジニアはツールの呼び出し、応答、エラーのトレースを収集し、個々のインシデントを調査できます。課題は組み合わせの爆発です。MCP経由で接続されるツールやシステムが増えるほど、可能なフローの数は急増します。特に、入力やコンテキストのわずかな変化でエージェントの動作が変わる可能性がある場合、危険なパターンの検出を手作業のレビューに頼るのは現実的ではありません。

新しいAI特化型のセキュリティ製品でさえ、個別のチェックに重点を置いていることがよくあります。特定のツールに対するパラメーター制約を強制したり、特定のエージェントがアクセスできる秘密情報を制限したりするものです。こうした対策はあくまでコンポーネント単位です。信頼できないコンテンツから始まり、信頼境界の外へデータが出ていくまでの経路全体を推論することは、一般にできません。

その結果、カバレッジにギャップが生まれます。モデルの安全性、プロンプトの検証、個々のツールのセキュリティに投資しても、MCPが生み出す相互作用の領域まで自動的に保護されるわけではありません。それぞれの要素を個別に見れば環境が適切に管理されているように見えても、それらを組み合わせると有害なフローが可能なままになっていることがあります。

これに対処するには、セキュリティチームは別の問いを立てる必要があります。攻撃者の影響を受けた指示によって機密データが流出先へ送られる経路が、環境内に存在するでしょうか。Toxic Flow Analysisは、この問いに体系的に答えるために設計されています。

Toxic Flow Analysisの紹介

Toxic Flow Analysis（TFA）は、AIを活用するシステムをグラフで捉える視点を提供します。プロンプトやツールを個別に見るのではなく、エージェント、MCPサーバー、ツール、基盤となるシステムの接続関係をマッピングし、致命的な三要素が成立する経路を探索します。

まず、環境を表現するところから始めます。MCP環境の場合、MCPサーバー、そのツールマニフェスト、モデルとエージェントの設定、さらにソース管理、チケット管理プラットフォーム、メッセージングシステム、汎用HTTPエンドポイントなど、ツールが接続する外部システムが含まれます。TFAはこれらの入力からフローグラフを構築し、どのコンポーネントがどのツールを呼び出せるか、ツールが何にアクセスできるか、出力をどこに送信できるかを可視化します。

次に、このグラフにセキュリティ関連の属性を追加します。ノードとエッジには、信頼できない相手が元の指示に影響を与えられるか、扱うデータが機密か、そのステップが信頼境界を越えるかを示す情報が付与されます。これにより、通常の内部フローと、攻撃者が制御できる接点から価値の高い資産を経由し、外部の送信先へ至るフローを区別できます。

注釈付きのグラフを使うことで、TFAは致命的な三要素の3条件すべてが存在する経路を体系的に探索できます。信頼できない指示がエージェントに届き、そのエージェントが機密データを扱うツールへアクセスでき、同じコンテキスト内に流出先も存在する一連の経路を特定します。こうした有害なフローは、カスタムマルウェアではなく、自然言語と既存のインテグレーションを利用する意欲的な攻撃者にとって、現実的な攻撃経路となります。

要件は検出だけではありません。TFAを実運用で役立てるには、優先順位付けと対処も支援する必要があります。潜在的なフローのすべてが同じリスクを伴うわけではありません。本番環境の秘密情報を任意の外部エンドポイントへ漏えいさせる可能性がある経路と、機密性のないメタデータが管理下の社内システムに公開される可能性がある経路では、影響の度合いが異なります。Toxic Flow Analysisは、データの分類、悪用の容易さ、アクセス範囲、流出先の性質などの要素に基づいて影響スコアを割り当て、チームがどこに注力すべきか判断できるよう支援します。

グラフを考慮したこの視点により、セキュリティチームやプラットフォームチームは、通常なら答えるのが難しい問いに対応できます。どのMCPサーバーが、有害なフローを生み出す可能性のあるツールの組み合わせを公開しているのか。信頼できない指示の入力元とデータ流出先の両方に同時接続されているエージェントはどれか。汎用HTTPクライアントなどの新しいツールを導入すると、実現可能なフローはどう変わるのか。

重要なのは、TFAが一度きりの取り組みではないということです。エージェントの進化、MCP設定の変更、新しいツールの追加に合わせて、フローグラフを更新し、再評価する必要があります。継続的な機能として取り組むことで、Toxic Flow AnalysisはAIネイティブ環境のリスクに対する、より成熟したアプローチの基盤となります。個々のコンポーネントの設定だけでなく、環境全体の振る舞いを把握できるアプローチです。

ここから、次のステップへと話が進みます。有害なフローを可視化して評価できるようになったら、次は実際に実行されないようにする方法を決めなければなりません。エージェントにすでに実行権限が与えられている環境では、可視化だけでは不十分です。

MCP環境に必要なのは可視化だけではなくガードレール

Toxic Flow AnalysisによってAIネイティブのリスクがどこに潜んでいるかを把握できますが、分析結果だけではインシデントを防げません。特定のエージェント、MCPサーバー、ツールの組み合わせが有害なフローを生み出すと特定できても、そのフローが実行されようとする際に介入する仕組みが必要です。

MCPは、単一のプロトコルで異種システムを接続するため、この要件の緊急性を高めます。MCPを介して、エージェントはソース管理、ビルドパイプライン、監視システム、コラボレーションプラットフォーム、社内サービスにアクセスできます。こうした各インテグレーションは、異なるチームやベンダーが管理しています。通常、基盤となる各システムには、それらに関わるすべてのフローを統制する単一のポリシーを適用できる中央の管理点はありません。

ポリシーを適用するうえで最も現実的な場所は、AIレイヤーそのものです。つまり、MCPサーバー、それが公開するエージェント、そして利用可能なツールとその使い方を決めるオーケストレーションロジックのレベルです。この文脈におけるガードレールとは、実行予定または実行中の一連のアクションを調べ、有害なフローの分析結果やポリシーと照合し、その一連のアクションを許可、変更、またはブロックする具体的な適用メカニズムです。

ガードレールが効果的に機能するには、コンテキストが必要です。現在のプロンプトや単一のツール呼び出しだけでは不十分です。どのエージェントが実行中なのか、環境でどのツールを利用できるのか、それらのツールがどう設定されているのか、どのデータや外部システムにアクセスするのかを理解する必要があります。ここでAI-BOMとMCPスキャンが重要な役割を果たします。

AI-BOMは、モデル、データセット、フレームワーク、MCPサーバー、主要なインテグレーションなど、AIスタックを体系的に記述します。MCPスキャンでは、開発者や運用担当者のエンドポイントに実際に導入されているものを把握できます。インストール済みのMCPサーバー、そのサーバーが公開するツール、設定内容などです。これらを組み合わせることで、オーケストレーションレイヤーはTFAの分析結果を具体的な実行コンテキストに対応付けられます。

この情報を使えば、的確なポイントにガードレールを適用できます。たとえばToxic Flow Analysisによって、特定のエージェントとMCP設定の組み合わせが、信頼できないGitHubのissueを起点としてシークレットを外部HTTPエンドポイントに送信できると判明した場合、その組み合わせを防ぐポリシーを適用しながら、ほかのフローは維持できます。これにより、エージェントの有用性を損なう広範で過剰な制限を避けられます。

こうした統合された適用の仕組みがなければ、組織は見慣れたパターンを繰り返すリスクがあります。充実したダッシュボード、鋭い分析結果があっても、日々の行動にはほとんど影響しないというパターンです。ガードレールは分析と実際の対応をつなぎ、有害なフローへの認識を、エージェントに許可する操作への具体的な制約へと結び付けます。

分析から制御へ：実際のガードレールと統合ガバナンスの必要性

有害なフローの分析結果を効果的なMCPガードレールにつなげるには、ポリシー、オーケストレーション、既存ツールとの連携が必要です。

まずはポリシーの策定です。セキュリティ、プラットフォーム、開発の各チームが、越えてはならない境界について合意します。たとえば、外部チケットに触れるエージェントが本番環境のシークレットにアクセスし、任意のURLへデータを送信するフローを禁止する、あるいは規制対象データが関わるフローに追加の制御を求める、といった内容です。Toxic Flow Analysisは、こうしたポリシーの策定と正当化に必要な根拠を提供します。

次に、オーケストレーションレイヤーがエージェントの動作をポリシーに照らして評価します。エージェントがMCP経由で、有害なフローを成立させる一連のツール呼び出しを実行しようとすると、ガードレールが介入できます。一連の処理をブロックする、追加の承認を求める、より安全なパターンにリクエストを振り分けるなどの対応が可能です。フローの全体像を把握できる、エージェントの意思決定に近い段階で適用されます。

このアプローチを拡張するには、エコシステム全体を連携させるガバナンスレイヤーが必要です。AI-BOMとMCPスキャンによって、このレイヤーは一元管理されたMCP環境とローカルにインストールされたMCP環境の両方について、正確かつ最新の情報を得られます。そのうえで、エージェントが共有プラットフォーム上で実行される場合も、開発者のマシン上で実行される場合も、一貫したガードレールを適用できます。

ローカル環境での修正も欠かせません。CI/CDシステム、IDEアシスタント、チケット管理プラットフォーム、データガバナンスツールを置き換えることが目的ではありません。リスクに対する共通認識に基づいて、それらが動作するようにすることが目的です。TFAが新たな有害なフローを検出すると、オーケストレーションプラットフォームは、チームがすでに利用しているシステムでissueを作成したり、設定変更を提案したり、アクセスルールを更新したりできます。ガバナンスレイヤーが調整役となり、既存ツールが変更を実行します。

導入が進むにつれ、これらの機能によって、組織は実験的な制御から一貫性のあるAIセキュリティプログラムへと移行できます。まずToxic Flow Analysisで可視化を始め、最もリスクの高いフローに的を絞ったガードレールを追加し、時間をかけて適用範囲を広げられます。このプロセスを通じて、AI-BOMとMCPスキャンにより、ポリシーを環境の実態に合わせた状態に保てます。

MCPは、AIネイティブシステムの中核をなす構成要素になろうとしています。正確なインベントリと統合ガバナンスに基づくガードレールをToxic Flow Analysisと組み合わせることで、重大なリスクを制御しながら、そのメリットを実現できます。こうした機能の進化とともに、進むべき道は明らかになります。この種の分析を実運用に活かす、実践的な方法が組織には必要です。

もっと詳しく知りたいですか？SnykがAIネイティブシステムの保護をどのように進化させているかをご覧になり、今すぐSnyk MCP Scanをお試しください。