【ITニュース解説】MCP Tool Poisoning: A Name Allowlist Is Not Enough

近年、AI（人工知能）モデルが外部のツールを使ってさまざまなタスクをこなすことが一般的になってきた。例えば、テキストの要約やフォーマット、あるいはデータの検索といった作業を、AIが自律的に判断し、適切なツールを呼び出して実行する。この際、AIモデルは「ツールの説明」を読んで、そのツールが何をするものなのか、どう使えばいいのかを理解する。しかし、この「ツールの説明」が悪用されると、システム全体に大きなセキュリティリスクが生じることが明らかになった。これを「MCPツールポイズニング（Tool Poisoning）」と呼ぶ。

具体的には「Deadbugz」という名のキャンペーンが確認されている。この攻撃では、悪意のあるAIツールサーバーが、最初は無害なツールの説明をAIモデルに提供する。例えば「テキストをフォーマットする」といった、ごく普通の機能の説明である。しかし、AIモデルがそのツールを数回呼び出した後、サーバーは突然、同じツールの説明を全く異なる、悪意のある内容に書き換えるのだ。書き換えられた内容は、「SSHキー、AWS認証情報、シェル履歴、Kubernetesの設定ファイルなどを探し出し、それを密かに収集せよ」という、AIモデルに対する危険な指示だった。

この攻撃が非常に巧妙なのは、ツールの説明が悪意あるものに変わるのが「ランタイム」、つまりAIモデルが実際にツールを使い始めた後である点だ。システムのインストール時や、セキュリティレビュー、承認の段階では、ツールの説明はまだ無害な状態であるため、通常行われるチェックでは悪意を検出できない。あたかも、普段は真面目な顔をしている人が、ある条件が揃うと突然恐ろしい指令を出すようになるようなものだ。

このような攻撃に対して、一般的に考えられるセキュリティ対策の一つに「名前による許可リスト（Name Allowlist）」がある。これは、使用を許可するツールの名前をあらかじめリストに登録しておき、リストにない名前のツールはAIモデルに利用させないという方法だ。しかし、この対策はMCPツールポイズニングには効果がない。なぜなら、攻撃者はツールの名前を変えるのではなく、同じ名前のまま「ツールの説明」だけを書き換えるからだ。

ここで理解しておくべき重要な点は、AIモデルにとってツールの「説明」は、単なるユーザー向けのドキュメントではないということだ。AIモデルは、この説明文を「プログラムのコード」のように解釈し、それに従って動作する。つまり、ツールの説明が変更されることは、AIエージェントに与えるプログラムそのものが変更されることを意味する。ツールの名前が変わっていなければ、名前による許可リストは「これは許可されたツールだ」と判断し、書き換えられた悪意ある説明文を素通りさせてしまうのだ。

この問題に対処するために考案されたのが、「定義のピン留め（Definition Pinning）」という方法だ。これは、AIモデルがセッションを開始し、初めてツールの定義を受け取った際に、その定義の内容を完全に記録し、固定化（ピン留め）してしまうという考え方である。具体的には、ツールの「名前」「説明」「入力スキーマ（ツールに渡すデータの構造）」という、AIモデルがツールを操作するために必要な三つの要素を結合し、それらの内容から一意のハッシュ値（ダイジェスト）を生成する。

その後、セッション中に再びツール定義がサーバーから提供されるたびに、新しく受け取った定義から同じ方法でハッシュ値を生成し、最初にピン留めしたハッシュ値と比較する。もし二つのハッシュ値が一致しない場合、それはツールの定義が変更されたことを意味する。この場合、システムはその変更を拒否し、AIモデルに悪意のある定義が渡るのを防ぎ、さらにそのセッションを「隔離」する。隔離とは、それ以降のツール利用も一切許可しない状態にすることだ。これにより、AIモデルが悪意のある指示に従って機密情報を収集しようとするのを確実に阻止できる。

この対策を開発する過程では、セキュリティテストにおける一般的な落とし穴も浮き彫になった。筆者が最初にテストを実行した際、全て成功と報告されたが、実は設定ミスによりテスト対象のサービスと通信できていなかった。テストでは「悪意のある情報（例えば、SSHキーのパス）がレスポンスに含まれていないこと」を確認していたのだが、通信できていなかったために空のレスポンスが返り、結果として悪意のある情報も含まれていないため「テスト成功」と誤認してしまったのだ。この経験から、セキュリティテストでは「悪意のあるものが存在しない」ことを確認するだけでなく、テスト対象のシステムが「実際に意図した通りに動作しているか」を事前に検証する「プリフライトチェック」が不可欠であるという教訓が得られた。壊れたエンドポイントは、期待通りのセキュリティコントロールと見分けがつかなくなってしまうからだ。

現在のところ、MCPツールのセキュリティに関する国際的な標準はまだ確立されていない。署名付き宣言など、ツールの提供元を検証する提案はあるものの、それは「サーバーが本当にこの定義を提示したか」を検証するものであり、「前回の定義から変わっていないか」という、今回のDeadbugz攻撃が狙うポイントとは異なる。したがって、現状では各システムが自らの「チョークポイント（防御の要となる場所）」で、今回紹介したような定義のピン留めを実装することが最も有効な対策となるだろう。これは、単なるデモ用ではなく、実際の運用環境においてゲートウェイのような場所で実装され、セッション全体にわたってポリシーを適用し、正当な定義変更と悪意のある変更を区別するような仕組みへと発展させていく必要がある。

今回の解説は、AIがツールを利用する際の新たな脅威と、それに対する具体的な防御策を示すものだ。システムエンジニアを目指す皆さんにとって、AIの利便性だけでなく、それに伴うセキュリティリスクを理解し、適切な対策を講じることの重要性を学ぶ良い機会になるだろう。