【要約】MCPのツールポイズニングを実演し、クライアント側で防ぐ [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
MCPを導入する開発者が、サードパーティ製サーバーのメタデータに潜む攻撃リスクに直面している。LLMはツールの説明文とユーザーの指示を区別できないため、以下の問題が発生する。
- ・説明文に隠された悪意ある指示が、LLMによって実行される。
- ・ユーザーには正常な出力に見えるため、攻撃の検知が困難である。
- ・自動承認設定下では、攻撃成功率が84.2%に達するリスクがある。
// Approach
開発者は、サーバーを検証されるまで信頼しないという設計思想に基づき、多層防御を実装する。具体的には、以下の5つの防御層を組み合わせる。
- ・静的メタデータ検証：説明文やスキーマ内の不審なパターンを検知する。
- ・allowlistとソース検証：許可されたサーバーとURLのみを接続対象とする。
- ・ツール定義のピン留め：ハッシュ値を用いて、承認後の定義変更を検知する。
- ・ポリシーベースのアクセス制御：実行層でスコープや送信先を強制的に制限する。
- ・人間の承認ゲート：機微な操作に対し、パラメータ全文を提示して最終確認を行う。
// Result
この多層防御の実装により、エージェントの自律性を維持しつつ、セキュリティリスクを大幅に低減できる。具体的には以下の効果が得られる。
- ・汚染されたツールをプロンプト投入前に排除できる。
- ・承認後の定義改ざん（rug pull）を即座に検知できる。
- ・LLMの誤判断があっても、実行層のポリシーで不正な操作を遮断できる。
Senior Engineer Insight
> MCPの利便性とセキュリティのトレードオフを正しく理解すべきだ。サーバーを「信頼できない第三者」と定義する非対称な設計は、サプライチェーン攻撃を防ぐ上で不可欠である。ただし、多層防御の実装はクライアント側の複雑性を増し、検証プロセスがレイテンシに与える影響も考慮が必要だ。特に「人間の承認ゲート」はUXを損なうため、ポリシーに基づいた適切な粒度での適用が運用の鍵となる。