そこで、代わりにエージェントに聞いてみました…

Evoは、チームがリポジトリに取り込んだAIアセット、開発者マシン上に存在するMCPサーバーやスキル、それらのうちリスクを伴うもの、そして違反しているポリシーをすでに把握しています。これらの情報にアクセスするには、これまで手間がかかりました。作業中のツールを離れ、UIでフィルタリングし、CSVをエクスポートして、必要になるたびに前四半期に作成したチャートを作り直す必要があったのです。

本日、Evo MCP serverの提供開始を発表します。これにより、これらすべての答えに、普段使っているエージェントハーネス内から、質問ひとつでアクセスできるようになります。そこで、私はエージェントに尋ねてみました。

Play Video: So I asked my agent instead… - video 1

Evo MCP serverは何に接続しますか？

Evo MCP serverを使うと、リポジトリや開発者マシン上のAIアセット、関連するリスクデータ、ポリシー、未解決の違反を検出できます。セットアップするには、ドキュメント

Cursorから接続：

1{
2  "mcpServers": {
3    "Evo MCP": {
4      "url": "https://evo.snyk.io/mcp"
5    }
6  }
7}

Claude Codeから接続：

1claude mcp add --scope user --transport http evo https://evo.snyk.io/mcp/

インストールはこれで完了です。リモートサーバーなので、マシン上に何も保存されず、ファイルシステムへのアクセスもありません。

MCP Serverは以下をサポートしています：

• インベントリ。環境全体で検出されたAIアセットと、評価済みのリスク。

• ポリシーと問題。AIの利用を管理するルールと、アセットがそれらに違反した際に発生する問題。

• 情報。AIセキュリティ態勢が時間とともにどのように変化しているか。

Evo MCP serverでAIアセットレポートを作成する

Evo MCPを使うにあたり、まず対象範囲から確認しました。次のように尋ねたのです。「私たちにはAIアセットがいくつあり、種類別およびソース別に分けるとどうなりますか？」返ってきたのは、モデル、エージェント、MCPサーバー、スキル、リポジトリ、開発者マシンという、環境全体の情報でした。

ソースは特に興味深いものでした。Evoは、リポジトリで参照されているものと、開発者マシンで設定されているものを区別し、どのマシンにあるかも示します。つまり、組織内にどのMCPサーバーやスキルが存在するかだけでなく、それぞれが誰のノートパソコン上にあるのかまで分かるのです。マシン単位のこの視点は、ダッシュボードのエクスポートから得るのは困難です。そして、リスクのあるサーバーを単なる一覧項目から、所有者が明確なマシン上のものへと変えるのが、この視点です。

次に、対象を絞りました。「モデルをベンダー別および原産国別にグループ化し、ライセンスタイプとセルフホスト可能かどうかで分類して、未解決の違反をポリシー別および重大度別にグループ化してください」。

最後に、通常なら午後いっぱい費やしてしまう作業を頼みました。「これをもとに、各セクションに1つずつチャートを含むダッシュボードを作成してください。」セッション内ですでに得られていた4つの結果から組み立てられ、再度クエリを実行する必要はありませんでした。つまり、頼めばいつでも再生成できます。

実際のインベントリに対するEvoポリシーを作成する

MCP serverを使って、インベントリに対するポリシーを作成できます。まずは、確認可能な次の質問から始めました：環境内で、安全でない認証情報の取り扱いについてスコアが500以上のスキルはいくつありますか？

次に、それらのスキルをスコア順に表示するよう依頼しました。ここからEvoに、環境内で安全でない認証情報の取り扱いについてスコアが500以上のスキルを特定するポリシーを、適切な修正方法に関する注記付きで作成するよう頼みました。すると、先ほどクエリしたものと同じ違反が返ってきました。予測と結果が一致したのです。ルールを書く前に環境全体を確認することの意味は、まさにそこにあります。

Evoの違反をチケットに変換する：チームごとに1件

ポリシーに対する未解決の違反を取得しました。それぞれに、影響を受けるアセット、そのアセットの場所、ポリシーの修正方法に関する注記が含まれています。次に、リポジトリごとにグループ化するよう依頼しました。違反ごとに1件のチケットを作るとセキュリティ作業は無視されがちですが、担当チームごとに1件のチケットを作れば作業が実行されるからです。グループ化した後、各チケットの説明にアセット一覧と修正方法に関する注記をあらかじめ含めたうえで、チケットを作成するよう依頼しました。

最後のステップは、Evo MCP Serverと並行してクライアントにすでに設定されていたチケット管理MCPサーバーを通じて実行されました。Snykはこれらのサーバーを提供またはサポートしておらず、このフローで実行できることは、JiraやServiceNowなど、チケット管理MCP Serverに付与した権限によって異なります。Evoが検出した問題は、連携を構築することなく、あなたのシステム上のアクションになりました。

Evo MCP serverのセキュリティ

ここまでのすべては、エージェントがセキュリティデータをクエリし、変更できることを前提としています。まさに、Evoが精査するために存在する種類のアクセスです。インベントリを前にした言語モデルについて私が予想した失敗パターンは、自信満々に間違った数字を出すことでした。それを防ぐのが、次の3つの制約です。

1. あなたとして実行される

OAuthを通じて、あなたのIDと権限で実行されます。サーバー経由で実行できることは、Evo UIで実行できることと完全に同じです。8つのツールのうち、6つは読み取り用、2つは書き込み用です。あなたのロールでポリシー編集が許可されていない場合、2つの書き込み用ツールは表示されません。

2. 書き込みには実際の承認が必要

エージェントがポリシーの作成または更新を試みると、Evoは変更内容をプレビューし、クライアントに承認リクエストを送信します。

3. エージェントはスキーマを推測できない

各クエリツールはクエリスキーマに対して動作し、利用可能な正確なフィールドとその意味を返します。クエリする権限のないフィールドは返されず、ツールの入力スキーマにも含まれません。

尋ねてみましょう

普段使っているクライアント内から見た、自分の環境がどのようなものか気になりませんか？あなたのクライアントを https://evo.snyk.io/mcp に接続して、尋ねてみてください。