8月16日、認可プラットフォームを提供するCerbosが「MCP server vetting checklist for enterprises」と題した記事を公開した。自社製品のコンテキストを踏まえたベンダー発信の記事ではあるが、企業がMCPサーバーを接続する際に実施すべきセキュリティ審査の7項目チェックリストと、ガバナンス設計の考え方は技術的な参照価値が高い。
「接続するだけで攻撃される」——MCPはすでにサプライチェーン問題だ
Model Context Protocol（MCP）は、AIエージェントに外部ツールやデータソースを接続するための標準プロトコルだ。公開MCPサーバーの数は急速に増加しており、開発者が午後に1つのサーバーを追加するのと同じ手間で、本番データへのアクセス経路を持つサプライチェーン依存を増やせてしまう状況になっている。
問題の深刻さを示す実例が記事内でいくつか挙げられている。
ツール説明文への命令埋め込み：Trail of Bitsのリサーチによれば、悪意あるMCPサーバーはツールの「説明文」にプロンプトインジェクション命令を仕込むことができる。エージェントが利用可能なツールを列挙した瞬間——つまり、まだ何もツールを呼び出していない段階——でモデルはその命令を受け取る。接続しただけで攻撃が成立する。
過剰なスコープのクレデンシャルが被害を拡大する：GitHub MCPの事例では、パブリックリポジトリの悪意あるIssueがエージェントを誘導し、同一トークンでプライベートリポジトリのデータを漏洩させた。Supabase MCPの事例では、サービスロールが行レベルセキュリティ（RLS）をバイパスしたまま攻撃者制御のコンテンツを読み込んでいた。どちらも「広すぎるアクセス権 × 信頼できない入力」という同じ構造だ。
認証はあるが認可がない：Asanaのケースでは、クレデンシャル自体は正当だったが、認証済みユーザーが特定リソースを参照してよいかのチェックが欠けており、テナント間でデータが漏洩した。
OWASPはすでにエージェントアプリケーション向けTop 10を公開しており、この領域のリスクを体系化し始めている。また記事では、マシンIDはすでに人間のIDを80対1以上の比率で上回っており、その大半に適切なセキュリティ管理が行き届いていないとも指摘されている（出典はCerbos記事内での言及によるもので、原典統計の詳細は元記事を確認されたい）。
7項目チェックリスト
記事はMCPサーバーを接続する前と接続後に継続して確認すべき7つの領域を提示している。
| # | 領域 | チェックのポイント |
|---|---|---|
| 1 | インベントリと所有者 | 全MCPサーバーの一覧と担当者名を即座に出せるか。未登録サーバーはゲートウェイでブロックされるか |
| 2 | アイデンティティと最小権限 | サーバーとエージェントそれぞれに専用IDがあるか。クレデンシャルは短命かつ最小スコープか |
| 3 | ツールサーフェス | 公開されているツール一覧を把握しているか。ツール説明文にインジェクションがないか確認したか |
| 4 | 認可の強制 | サーバー外部の認可ポイントで、ツール実行前にエージェント・ユーザー・引数を検証しているか |
| 5 | データと下流へのリーチ | ツール呼び出し成功後に実際に到達できるデータ範囲は何か。RLSなどをバイパスしていないか |
| 6 | 証跡と監査 | 特定のエージェントが「先週火曜日に何をしたか」をクエリ一発で答えられるか |
| 7 | ライフサイクルと失効 | 再デプロイなしにアクセス範囲を絞れるか。アクセスに有効期限があるか |
記事が強調するのは、4〜7の領域は自社でコントロールできるという点だ。これらはサーバー側の実装に依存しない。4（認可の強制）はサードパーティサーバーが認可ロジックを持たない場合でも自社の境界で補える。5（データリーチ）はツール実行後に何が読み書きできるかを自社ポリシーで絞る。6（監査）と7（失効）は、どんなサーバーが相手でも自社のゲートウェイ・ログ基盤で実現できる。サーバーが失敗しても、境界側の制御で補えるという設計思想だ。
全サーバーを同じ粒度で審査するな——ティアリングが鍵
記事はすべてのサーバーに同じ審査を適用することを明示的に否定している。均一審査はプログラムを形骸化させ、結果的に審査ゼロと変わらなくなると述べている。
代わりに提案されるのは信頼度と到達範囲によるティアリングだ。
- 低ティア：自社開発・非機密データ対象。インベントリと認可は必要だが深い審査は不要
- 中ティア：既知ベンダーの外部サーバー・中程度の機密性。ツールサーフェスとクレデンシャルモデルの確認が必要
- 高ティア：不明なソース、または規制対象データ・本番書き込み・顧客レコードに触れるもの。チェックリスト全項目＋最小スコープ＋厳格なモニタリング
重要な原則として、ティアはそのサーバーが到達できるデータで決まる。チームが使いたいかどうかでは決まらないと明記されている。「使い勝手がよいから」「有名ベンダーだから」という理由でティアを下げることは、このフレームワークでは認められない。
審査は「一度やって終わり」ではない
ツールセットは承認後に変わりうる。クレデンシャルのスコープは気づかないうちに広がりうる。内部向けだったサーバーが外部への経路を持つようになることもある。
記事は「新しいサーバーはまず緩めの設定で詳細ログを取りながら接続し、実際の使用パターンを観察してからスコープを絞る」という段階的アプローチを推奨している。ツールサーフェスが変わったら再審査。ワンタイムの承認フォームではなく、継続的なプログラムとして運用することが求められる。
Cerbosのアプローチ：制御を境界に置く
記事の後半はCerbos自社製品の説明に移る。自社ソリューションの文脈での紹介である点は留意が必要だが、設計思想として参照できる部分がある。認可の決定をサーバー内部ではなく外部の認可レイヤー（Policy Decision Point）に置くことで、サードパーティのサーバーに対しても最小権限・フェイルクローズ・完全な決定ログ・ランタイムでのスコープ変更を自社でコントロールできるという考え方だ。
記事の締めにある問いは的確だ。「あるMCPサーバーのエージェントが先週火曜日に何をしたか——その答えがSlackのスレッドのスクリーンショットであれば、審査はあるが強制はない。バージョン管理されたポリシーに紐づいた決定ログであれば、両方ある」。MCPの普及に伴い、この問いに即答できる体制を整えているかどうかが、企業のAIガバナンスの実質的な試金石になりつつある。
詳細はMCP server vetting checklist for enterprisesを参照していただきたい。
