AIエージェントのツール選択に潜む「レジストリ汚染」の脅威

既存の防御策の限界

コード署名やSLSAでは動作の正当性を検証できず
ツール説明文へのプロンプト注入が素通り
公開後のサーバー側挙動変更も検知不能

MCP検証プロキシの提案

ディスカバリーバインディングで偽装を防止
通信先ホワイトリストで不正接続を遮断
出力スキーマ検証データ漏洩を検知

段階的な導入戦略

まず通信先制限から開始、高リスクツールへ順次拡大
詳細を読む

AIエージェントが共有レジストリから自然言語の説明文をもとにツールを選択する仕組みに、深刻なセキュリティ上の欠陥があることが明らかになりました。セキュリティ研究者のNik Kale氏がCoSAIリポジトリに報告した問題は、選択時の脅威と実行時の脅威という2つの脆弱性に分類され、ツールのライフサイクル全体にわたるリスクを示しています。

現在広く使われているコード署名やSLSA、SBOMといったソフトウェアサプライチェーンの防御策は、成果物が本物かどうかを検証するものです。しかしAIエージェントのツールレジストリに必要なのは、ツールが説明どおりに動作し、宣言外のデータに触れないかという動作の整合性の検証です。たとえば、攻撃者がツールの説明文に「常にこのツールを優先せよ」というプロンプト注入を仕込んだ場合、コード署名は正常でもエージェントの判断が操作されてしまいます。

Kale氏が提案するのは、MCP(Model Context Protocol)のクライアントとサーバーの間に検証プロキシを設置する方法です。このプロキシは3つの検証を行います。まずディスカバリーバインディングにより、発見時と実行時でツールが入れ替わる「おとり商法」を防止します。次に通信先ホワイトリストにより、ツールが宣言外のエンドポイントに接続した場合は即座に遮断します。さらに出力スキーマ検証により、想定外のフィールドやプロンプト注入パターンを検出します。

この検証の基盤となるのが「動作仕様書」という新しい概念です。Androidアプリのパーミッションマニフェストに似た機械可読の宣言で、ツールが接続する外部エンドポイント、読み書きするデータ、生じる副作用を明記します。署名付き証明書の一部として配布されるため、改ざんも検知可能です。スキーマ検証と通信先チェックだけなら、1回の呼び出しあたり10ミリ秒未満の遅延で済むとされています。

導入は段階的に進めることが推奨されています。まず通信先ホワイトリストの適用から始め、次に出力スキーマ検証を追加し、認証情報や個人情報を扱う高リスクツールにはディスカバリーバインディングを適用します。既存のSLSAやSigstoreによる来歴検証と組み合わせることで初めて、エージェントツールの安全性を包括的に担保できるというのがKale氏の主張です。