AIエージェントのツール選択に潜む「レジストリ汚染」の脅威
詳細を読む
AIエージェントが共有レジストリから自然言語の説明文をもとにツールを選択する仕組みに、深刻なセキュリティ上の欠陥があることが明らかになりました。セキュリティ研究者のNik Kale氏がCoSAIリポジトリに報告した問題は、選択時の脅威と実行時の脅威という2つの脆弱性に分類され、ツールのライフサイクル全体にわたるリスクを示しています。
現在広く使われているコード署名やSLSA、SBOMといったソフトウェアサプライチェーンの防御策は、成果物が本物かどうかを検証するものです。しかしAIエージェントのツールレジストリに必要なのは、ツールが説明どおりに動作し、宣言外のデータに触れないかという動作の整合性の検証です。たとえば、攻撃者がツールの説明文に「常にこのツールを優先せよ」というプロンプト注入を仕込んだ場合、コード署名は正常でもエージェントの判断が操作されてしまいます。
Kale氏が提案するのは、MCP(Model Context Protocol)のクライアントとサーバーの間に検証プロキシを設置する方法です。このプロキシは3つの検証を行います。まずディスカバリーバインディングにより、発見時と実行時でツールが入れ替わる「おとり商法」を防止します。次に通信先ホワイトリストにより、ツールが宣言外のエンドポイントに接続した場合は即座に遮断します。さらに出力スキーマ検証により、想定外のフィールドやプロンプト注入パターンを検出します。
この検証の基盤となるのが「動作仕様書」という新しい概念です。Androidアプリのパーミッションマニフェストに似た機械可読の宣言で、ツールが接続する外部エンドポイント、読み書きするデータ、生じる副作用を明記します。署名付き証明書の一部として配布されるため、改ざんも検知可能です。スキーマ検証と通信先チェックだけなら、1回の呼び出しあたり10ミリ秒未満の遅延で済むとされています。
導入は段階的に進めることが推奨されています。まず通信先ホワイトリストの適用から始め、次に出力スキーマ検証を追加し、認証情報や個人情報を扱う高リスクツールにはディスカバリーバインディングを適用します。既存のSLSAやSigstoreによる来歴検証と組み合わせることで初めて、エージェントツールの安全性を包括的に担保できるというのがKale氏の主張です。