MCPを安全に受け入れる：Evo ADSでAIコーディングエージェントをガバナンスする方法

Evo Agentic Development Security（ADS）でMCP Governanceが一般提供開始となったことを発表した際、最も多く寄せられた質問は実践的なものでした。「いいですね。では月曜日に何から始めればいいですか？」

もっともな質問です。Snykが1万近くの開発者環境を調査したところ、4,524種類のMCPサーバーが実際に使われており、MCPサーバーをインストールしている開発者の12人に1人で、高または重大と確認された問題が見つかりました。これらのサーバーの多くは、エージェントに何か役立つ作業をさせようとした開発者によって、レビューを受けることなく、わずか数秒で追加されていました。

その答えがこちらです。4つのステップで、最初のインベントリ作成から、リスクのあるサーバーだけをブロックするポリシーの設定まで進められます。Evo ADSはMCPサーバーのリスクスコアを提供するため、許可リストの有無にかかわらず、すべてのサーバーを手作業で確認したり、広範囲にブロックして開発者の作業を遅らせたりせずに、リスクに基づいてガバナンスできます。すべての処理は、エージェントがすでに動作しているエンドポイント上で、プロキシを介さず軽量なフックを使って実行されます。何があるかを把握し、許容範囲を定め、ポリシーが検出する内容を確認してから、自信を持って適用しましょう。

ステップ1：すでに稼働しているものを把握する

MCPサーバーはCIや依存関係のレビューを経由しません。開発者が設定ファイルを1つ編集するだけで、エージェントが新しいツールを使えるようになります。だからこそ、最初のステップは、すでに何があるのかを把握することです。見えないものはガバナンスできません。Evo ADSでは次の2つのビューを利用できます。

• 開発者のマシン上のMCPサーバー：フリート全体にEvo ADSインストーラーを展開します。リポジトリに一度も触れていない一時的なローカルインストールも含め、エージェントが実際に接続しているMCPサーバーを表示します。

• コードリポジトリ内のMCPサーバー：SnykのSCMインテグレーションを通じて設定したEvo AI-SPMが、コード内で参照されているMCPサーバーを検出します。

この2つを合わせることで、「コード内で何が設定されているか」と「ノートPC上で何が稼働しているか」という、異なる2つの問いに答えられます。どちらもEvoのUIのインベントリ → MCPサーバーに表示されます。

Evo MCP Serverを使えば、独自のエージェントワークフローからこのデータにアクセスすることもできます。MCP環境全体を1つのビューで把握でき、何もブロックせず、開発者の作業も妨げません。このステップだけで、ほとんどのセキュリティチームが答えられない問いに答えられるようになります。エージェントは何に接続しているのか？

ステップ2：「許容できる」とは何かを定義する

47番目のサーバーを許可すべきか判断するために、Slackで議論したりウェブ検索したりする必要はありません。Evo ADSは各サーバーに関する根拠をその場に提示するため、自信を持って、より迅速に承認または却下できます。

インベントリを確認する

高リスクで広くインストールされている非公式サーバーと、1台のマシンにだけある高リスクサーバーとでは、問題の性質が大きく異なります。各行には、手作業で調べる必要があった情報がまとまっています。このサーバーを誰が開発したか、どこにインストールされているか、承認済みか、どれほどリスクが高いかがわかります。

• サーバー：名前、配布元（例：NPM）、トランスポート（SSEまたはSTDIO）、ローカルかどうか。

• ベンダーの配布元：サーバーが公式かどうか。不明であることも判断材料になります。

• ソース：コード、マシン、ランタイムでの出現回数。

• 許可リストのステータス：許可済みかどうか。

• リスクスコア：サーバーごとに統一されたスコア。並べ替えやフィルタリングが可能です。

• 深刻度別の問題：重大、高、中、低の件数。

リスクスコア順に並べ替えて、一覧を確認します。

リスクプロファイルを開く

サーバーをクリックすると詳細ビューが開きます。ヘッダーには認証方式が追加され、3つのカードにサーバーの所在が表示されます。コード内で宣言されているか、何台のマシンに存在し最後にスキャンされたのはいつか、過去7日間にエージェントが何回呼び出したかを確認できます。

次に、リスクプロファイルタブを開きます。Slackでの議論やウェブ検索の代わりになるのが、このタブです。

調査したあるサーバーでは、12件中8件のツール説明に「以前の指示を無視して」という文言が含まれていることをEvoが検出しました。すべてのツール説明を自分で読まなければ気づけない、プロンプトインジェクションです。

スコアは0から1000までです。

• 低（0～249）

• 中（250～499）

• 高（500～749）

• 重大（750～1000）

このタブでは、ツール説明に含まれるプロンプトインジェクション、破壊的な機能、信頼できないコンテンツなどの属性ごとにスコアを分解して表示します。それぞれのスコアは1000点満点です。項目を展開すると、説明と根拠を示す「このリスクの理由」が確認できます。

このサーバーはすでに許可リストに登録されていました。誰かが承認したにもかかわらず、スコアは931で、明確に「重大」です。許可リストに記録されるのは、その時点での判断です。リスクスコアがあれば、その判断を見直すべきタイミングがわかります。このページから「許可しない」に変更することも、ランタイムでブロックすることもできます。

サーバーのスコア算出方法

MCPのリスクスコアは3つのシグナルを組み合わせています。サーバーの動作（エージェントに送信する指示やツールの説明）、信頼性（URLの評判とメンテナーの身元）、そしてソースを利用できるローカルサーバーの場合は、実装、メンテナンス、依存関係です。制約の1つとして、Evoは署名のないサーバーを確実に特定できません。該当するのはサーバーの20%未満で、スコアは付与されません。レビュー手順でこれらを考慮してください。

ベースラインを設定する

許可リストは、承認したMCPサーバーを記録するためのものです。各サーバーには承認済みかどうかを切り替えるトグルがあります。切り替えると、インベントリの「許可リストのステータス」列に判断が反映され（許可済みまたは許可しない）、インベントリを見ている全員が同じ状態を確認できます。サーバーの詳細ビューで許可リストを表示すると、一覧全体を確認できます。

すでに信頼しているものから始めましょう。ゼロから作成する必要はありません。既存のインベントリ、厳選されたリスト、またはEvo ADSがすでに検出したサーバーをもとに登録できます。インベントリでサーバーを手動で切り替えるか、チャットでEvoに依頼してください。

候補ごとに、ここまでに得た情報を確認しましょう。スコアの範囲、ベンダーが公式かどうか、認証方式、そして高または重大のサーバーについては「このリスクの理由」に示された根拠です。スコアが低く、公式で、認証済みのサーバーなら、簡単に承認できます。重大なサーバーは、承認する前に理由を確認しましょう。却下するのも、まったく問題のない判断です。

許可リストに記録されるのは判断です。それ自体が何かをブロックするわけではありません。ポリシーがその判断に基づいて動作します。次のステップでは、ここがポイントになります。

ステップ3：ブロックする前に監視する

初日からブロックを有効にすると、まだ把握できていない開発者のワークフローを壊す可能性があります。監視モードでは、実際にブロックする前に、ポリシーによってブロックされる対象を正確に確認できます。ポリシーページで許可されていないMCPサーバーを監視テンプレートから最初のポリシーを作成します（ポリシー → 問題 → ポリシーを作成）。このポリシーは、リスクのある各サーバーをレビュー対象の問題として登録し、何もブロックしません。これにより、開発者とエージェントは作業を続けながら、ポリシーが検出するすべての項目を継続的に一覧で把握できます。

次に、ステップ2で確認した一覧とリスクプロファイルを使って、インベントリ → MCPサーバーで各項目に対応します。検出されたサーバーごとに、スコア、公式かどうか、認証方式、スコアに影響した属性を確認します。そのうえで、許可リストに登録するか、却下するかを判断します。1～2週間続けて、傾向を確認しましょう。一度だけ出てくるサーバーは気になる程度かもしれませんが、50台のマシンに出現するサーバーについては、意識的な判断が必要です。

2週目の終わりまでには、実際の環境でテストされ、セキュリティチームと開発者が動作を確認したうえで、開発者の作業を止めることなく使える、リスク許容度に合ったポリシーが完成します。

ステップ4：リスクの高いものから適用する

ポリシーが検出する内容を信頼できるようになったら、適用を有効にします。許可されていないMCPサーバーをブロックポリシーテンプレート（ポリシー → ポリシー → ポリシーを作成）を使うと、許可リストに登録されておらず、高または重大なリスクと評価されたサーバーを、エンドポイント上のランタイムでコーディングエージェントが呼び出すのを防止できます。テンプレートが自社のリスク許容度に合わない場合は、ゼロから作成を選び、独自の基準でカスタムポリシーを構築してください。

ポリシーがサーバーをブロックするのは、許可リストに登録されておらず、かつリスクが「高」または「重大」と評価された場合のみです。それ以外はすべてログモードで動作するため、まだ誰も承認していない低リスクのサーバーによって開発者の作業が止まることはなく、監査証跡も保持できます。また、適用はプロキシやゲートウェイを経由せず、エージェントのそばで動作する軽量なフックを通じて、開発者のマシン上でランタイムにローカル実行されます。ポリシーは一度、中央で設定します。フックは、エージェントがサーバーを呼び出す際に各マシンで適用します。対象はClaude Code、Cursor、Codex、GitHub Copilotのいずれでも同じです。

MCPを、管理しながら受け入れる

つまり、月曜日にインストーラーを展開してSCMに接続すれば、金曜日にはインベントリを作成し、許可リストの初期設定まで完了できます。Evo ADSなら、MCPを受け入れながら、エージェントの接続先を把握し、迅速に判断し、リスクのあるものをブロックできます。これはエージェントの振る舞いをガバナンスするための最初のユースケースです。まだ始まったばかりです。今年の残りの期間を通じて、同じ「検出、分類、適用」のモデルを、エージェントスキル、機密データへのアクセス、プロンプトインジェクション対策、シークレットの露出へと拡張していきます。

エージェントの接続先を確認しませんか？デモを予約するか、Evo Agentic Development Securityをご覧ください。