Evo ADSのエージェント動作ガバナンスが一般提供開始：MCPの利用を管理

本日、AIコーディングエージェントが実行時に実行できる操作を制御する、Evo Agentic Development Security (ADS)の機能であるGovern Agent Behaviorが、MCP Governanceを皮切りに一般提供開始となったことをお知らせします。

6月にEvo ADSを発表して以来、私たちはシンプルな考え方を軸に開発を進めてきました。エージェント型開発は3つの領域にリスクをもたらし、それぞれに独自の制御が必要です。

1. エージェントが利用するもの：取り込むMCPサーバー、スキル、ツール。これらには検出と評価が必要です。

2. エージェントが生成するもの。生成時点での検証が必要です。

3. そして、エージェントが実行すること：行動を決定した後に取るアクション。これらはリアルタイムで強制する必要があります。

Govern Agent Behaviorは、Evo ADSがこの3つ目の課題に応える機能です。MCP Governanceは、そのもとで最初に提供されるユースケースです。

MCP Governanceにより、セキュリティチームやプラットフォームチームは、組織全体のMCPサーバーを検出し、利用を許可するサーバーを定義し、エージェントがポリシーから逸脱した時点で把握できます。また、Claude Code、Cursor、Codex、GitHub Copilot全体で、実行時にMCPの利用を記録またはブロックできます。

自律型エージェントが呼び出せるツールを管理することは、セキュリティの基盤です。多くのセキュリティチームは、すでにそのような制御があると思っていましたが、探しても見つからないことに気づきました。MCP Governanceは、エージェントのサプライチェーンを検出し、AI生成コードを検証するのと同じワークフロー内で、このギャップをネイティブに解消します。後付けの独立したツールは必要ありません。

今、MCPのガバナンスが重要な理由

Model Context Protocol（MCP）は、AIコーディングエージェントが共通のインターフェースを通じて、リポジトリ、データベース、クラウドインフラ、社内APIなどの外部ツール、データソース、システムに接続するための標準です。エージェントが単なるオートコンプリートではなく、同僚のように感じられるようになってきた大きな理由の一つです。MCPにアクセスできるエージェントは、コードを1行提案するだけでなく、同じセッション内でチケット管理システムに問い合わせたり、本番データベースからレコードを取得したり、社内サービスを呼び出したりできます。

その強力さこそが、問題でもあります。MCPは、エージェントがツールに接続する方法を標準化しますが、どのツールを信頼すべきか、また接続可能なツールをエージェントがどう使ってよいかについては何も定めていません。エージェントが接続するMCPサーバーはすべて、実質的にソフトウェアサプライチェーンの新たな一部となります。しかし、マニフェストに固定された依存関係とは異なり、多くの場合、開発者が数秒でインストールすることで動的に導入され、レビューのプロセスもありません。

このリスクは仮説ではありませんし、新しいものでもありません。別の経路で発生している、従来と同じ悪意のあるパッケージの問題です。侵害されたMCPサーバーは、実行された瞬間にローカルファイルを読み取ったり、認証情報を外部に持ち出したり、社内システムにアクセスしたりする可能性があります。セキュリティチームがそのサーバーの存在を知る前はもちろん、レビューする機会を得る前にです。リスクは開発者のマシン上で、呼び出された瞬間に顕在化するため、そこで検知しなければなりません。

その規模は、ほとんどのセキュリティチームが想定する以上です。約1万件の開発環境を対象にしたSnyk独自のスキャンデータでは、実際に利用されているMCPサーバーが4,524種類確認され、最も多くの計測機器が導入されたマシンでは、同時に13台以上が稼働していました。開発者の半数以上が、すでに本番環境のツールやシステムにMCPで接続しています。さらに、これらの接続のセキュリティ状況を調査したところ、MCPサーバーをインストールしている開発者の12人に1人で、今日、重大または深刻な問題が確認されました。

MCPサーバーはCIでスキャンされる成果物でも、マージ前にレビューされる依存関係でもないため、従来のAppSecパイプラインでは検出されません。代わりに、セキュリティチームが把握できるプロセスを通らず、実行時にその場で導入されることがよくあります。許容できるMCPサーバーを定め、エージェントがそれを使おうとする瞬間に適用する方法がなければ、「AIエージェントの導入」と「管理されない攻撃対象領域の拡大」は、同じ意味になってしまいます。

Evo ADSでMCP Governanceが機能する仕組み

MCP Governanceは、このギャップに対するEvo ADSの答えであり、Evo ADSがすでにエージェントのサプライチェーンに提供している可視性を直接拡張するものです。次の3つの機能があります。

1. Snykにリストを登録

セキュリティチームやプラットフォームチームは、既存のインベントリ、手作業で作成したリスト、またはEvo ADSが検出によってすでに明らかにしたサーバーから、承認済みのMCPサーバーを定義します。これが、すべてのエージェントを評価するための基本ポリシーになります。手動で設定することも、チャットでEvoにプロンプトを入力するだけで設定することもできます。

2. ポリシーに反する利用を検出

ポリシーを設定すると、Evo ADSは開発者のマシン全体にわたるMCPのアクティビティを継続的に監視し、承認済みリストにないサーバーにエージェントがアクセスしようとした事例をすべて明らかにします。単発のローカルインストールでも、組織全体で見られるパターンでも検出できます。この可視性を得るために、何かをブロックする必要はありません。多くのチームにとって、エージェントが実際に何に接続しているかを知ることが、初めての実質的なインベントリになります。

3. 実行時に利用を管理

ここで、可視性が制御へと変わります。Evo ADSは、監査のために未承認のMCP利用を記録することも、エンドポイント上で、エージェントが接続しようとする瞬間にその利用を直接ブロックすることもできます。事後対応ではなく、エージェントがポリシーに従うかどうかにも依存しません。

MCP Governanceは、エージェントがすでに動作している場所で利用できます。Claude Code、Cursor、Codex、GitHub Copilotに対応しており、エージェントのそばで動作する軽量なフックを通じて適用されます。別のプロキシやゲートウェイにトラフィックを経由させる必要はありません。これは、Evo ADSがセキュアな初期段階のコードスキャンに採用している方法と同じです。つまり、チームはエージェントがツールに接続する方法を変更したり、新たなインフラを構築したり、エージェントの実行経路に新たな単一障害点を受け入れたりする必要がありません。ポリシーは一元管理され、MCPサーバーを使う判断が実際に行われる場所で、ローカルに適用されます。

エージェントの動作管理の今後

今回の発表を完成形ではなく、最初のユースケースと呼ぶのには理由があります。MCP Governanceが答えるのは、「このエージェントはこのツールにアクセスしてよいか？」という問いです。これは必要な問いですが、それだけではありません。承認済みのMCPサーバー内だけで動作するエージェントでも、破壊的なシェルコマンドを実行したり、機密データを不適切な場所に移動したりする可能性があります。MCP Governanceだけでは、それを検知できません。

ここからEvo ADSは次の段階に進みます。今後数週間で、MCPの許可リストにとどまらず、エージェントが実行する操作の検知とブロックへと適用範囲を広げます。また、MCPポリシーを静的なリストから、Evo MCPを使ってgitリポジトリやConfluenceページから直接取り込める仕組みに移行し、リスクベースの適用へと進めます。固定の許可・拒否ではなく、サーバーの実際のリスクをポリシーに反映できるようにします。

さらに今年中に、ADSの適用範囲を拡大し、機密データへの不正アクセス、エージェントのプロンプトインジェクション対策、シークレットの露出を管理します。また、MCP Governanceで導入した検出・分類・適用モデルをAgent Skillsにも展開します。

エージェントが何を使うかを管理することは不可欠です。エージェントが何を実行するかを、その瞬間に管理することで、ガバナンスが実効性を持ちます。MCP Governanceはその最初の証明であり、今日から利用できます。

MCP Governanceの動作をご覧になりたいですか？デモを予約するか、Evo Agentic Development Securityをご覧いただき、AI主導の開発ライフサイクル全体でEvo ADSがエージェントの利用・実行・生成をどのように保護するかをご確認ください。