DVMCP に対する capgate のテスト
Damn Vulnerable MCP (DVMCP) プロジェクトに含まれる10個の脆弱な MCP サーバーに対して、私のツールである capgate のテストを行いました。
DVMCP は学習用ツールです。各サーバーは、プロンプトインジェクション、トークン窃取、コマンドインジェクションといった特定の攻撃を実演します。
目標はシンプルです。各ツールに対して正直なマニフェストを作成しました。そして、「capgate が作成する境界は、実際に攻撃を阻止できるのか？」と問いかけました。
その結果は、ケイパビリティ・コンパイラ（capability compiler）ができることとできないことを明確に示しています。
阻止できたもの（命中） チャレンジ3では、ツールに過剰な権限が与えられています。あるフォルダの読み取りを主張していますが、実際にはディスク全体を読み取ることができてしまいます。 攻撃は、プライベートフォルダからシステムの認証情報を盗み取ろうとします。 capgate はこれを阻止します。マニフェストを、許可されたフォルダのみをマウントする Docker コンテナへとコンパイルします。サンドボックス内にはプライベートファイルが存在しないため、攻撃は失敗します。
封じ込めたもの（中間領域） チャレンジ7では、ツールが API キーを漏洩させます。capgate はツールがキーを読み取ることを止めることはできませんが、データの持ち出し（exfiltration）は阻止します。特定のホストへの接続のみを許可するエグレスプロキシ（egress proxy）を作成することで、攻撃者が盗んだキーを自身のサーバーに送信することを防ぎます。
チャレンジ8では、ツールが任意のシェルコマンドを許可しています。capgate の文法では「あらゆるシェルを許可する」と表現することはできません。その代わりに、ツールを隔離（box）します。たとえ攻撃者がコマンドを実行したとしても、そのプロセスにはネットワークがなく、追加の権限もなく、ファイルシステムは読み取り専用です。被害は限定的で済みます。
防げなかったもの（限界） チャレンジ1の攻撃はプロンプトインジェクションです。攻撃者はモデルを欺いて、指示を無視させます。 ここでは capgate は何もできません。サンドボックス・コンパイラはツールが触れる範囲を制限しますが、LLM が何を言うかを制御することはできないからです。
サンドボックスがプロンプトインジェクションを阻止すると考えているなら、それは間違いです。サンドボックスは被害を限定することで、プロンプトインジェクションの有用性を下げるだけなのです。
まとめ • 1件の完全な阻止 • 4件の有意義な封じ込め • 3件の正直な失敗
capgate は万能薬ではありません。それは防御の一層に過ぎません。「このサーバーはすべてにアクセスできる」という状態を、「このサーバーは特定のパスにのみアクセスできる」という状態に変えるものなのです。
Optional learning community: https://t.me/GyaanSetuAi