攻撃者がシステムがハッシュ比較を行っていることを知っている場合、この検知を回避する方法はありますか？
ハッシュ比較の仕組み自体は暗号学的に直接回避するのが難しい。ツールの説明テキストに1文字でも違いがあれば、計算されるハッシュ値は全く異なるものになる。これはハッシュ関数の基本的な特性であり、攻撃者は悪意ある指示の言い回しを調整することで、変更後の内容が元のバージョンと同じハッシュ値を生成するようにすることはできない。本当の攻撃対象領域はハッシュアルゴリズム自体ではなく、ハッシュ比較の仕組みが正しく、継続的に実行されているかどうかにある。例えば、システムが初回インストール時に一度だけハッシュを記録し、その後一度も比較していない場合。あるいはアクティブプロキシモードが有効化されておらず、一回限りのパッシブスキャンだけに依存している場合。この場合、攻撃者はそのパッシブスキャンの後の空白期間を狙うだけでよく、変更はリアルタイムでは検知されない。
これが、パッシブスキャン（一回限りのチェック）とアクティブプロキシ（継続的な監視）を組み合わせて使う必要がある本当の理由でもある。組織が初回導入前にハッシュを記録しただけで、継続的な再比較の仕組みを確立していなければ、検知ツールを持ってはいても実際には稼働させていないのと同じことになる。この「ツールはあるが継続的に使われていない」という落差こそが、攻撃者が本当に利用できる隙間であり、ハッシュアルゴリズム自体の弱点ではない。
Invariant LabsがSnykに買収されブランドが変わったことは、すでにMCP-Scanを使用しているチームに実際どのような影響がありますか？
技術的な継続性という観点から見れば、より大きなリソースを持つセキュリティ企業に買収されることは、通常より長期的なメンテナンスの保証を意味する。独立した小規模な研究チームが開発したオープンソースツールによくあるリスクは、中核開発者の関心が他に移った後、プロジェクトが更新停止に陥ることだ。SnykによるMCP-Scanのエンタープライズ向けAgent Scan製品ラインへの統合は、むしろこのツールがより明確な商業化への道筋と継続的な投資へのインセンティブを持つようになったことを意味し、これは長期的な保護をこのツールに依存しているチームにとってポジティブなシグナルだ。
注意すべき実務上の詳細は、買収後の製品の位置づけが階層化される可能性がある点だ。オープンソース版は基本機能（ドキュメントに記載されている通り無料、Apache 2.0ライセンス）を維持し続ける一方、エンタープライズ向け機能（より完全な継続的バックグラウンド監視、チーム横断ダッシュボードなど）は有料のSnyk Agent Scan製品ラインに区分けされる可能性がある。あなたのチームが現在オープンソース版を使用しているなら、中核的な検知能力（ツールピン留め、プロンプトインジェクション検知）が依然としてオープンソースライセンスの範囲内で維持されているかを定期的に確認する価値がある。買収前後で機能が全く変わっていないと仮定するのではなく。
ツールピン留めは「最初に記録されたバージョンがクリーンである」という前提に依存していますが、最初から記録されたバージョンがすでに汚染されていた場合はどうなりますか？
これは実際に存在する限界だ。ツールピン留めは本質的に「ある時点の状態を凍結し、その後の変化を追跡する」仕組みであり、「その凍結された初期状態自体がクリーンかどうか」に答える能力を持たない。攻撃者が最初から悪意ある指示を持つツールを公開していた場合（後で変質するラグプルではなく、ツール説明汚染そのもの）、ハッシュ比較の仕組みはその悪意あるバージョンを忠実に「基準」として記録してしまい、その後変更がなければ一切警報は発動しない。
これが、ツールピン留めと意味論レベルの検知（MCP-ScanがInvariant Guardrails APIを呼び出して行う悪意ある指示分析など）が互いを置き換えるのではなく共存する必要がある理由でもある。意味論的検知は、記録される前に「この初期バージョン自体がクリーンかどうか」を判断する役割を担う。ツールピン留めは、「クリーンだと確認された後、ひそかに変質していないか」を確認する役割を担う。両者は攻撃のライフサイクルの異なる段階に対応しており、どちらか一方だけを行うことは、攻撃連鎖全体の中に別の無防備な空白期間を残すことになる。
私のチームがツールピン留めの仕組みを導入すると決めた場合、実務上誰が警報を監視すべきで、どれくらいの頻度でチェックするのが妥当ですか？
実行可能な出発点は、すべてのツールに同じペースで対処するのではなく、まずツールを重要度に応じて階層化することだ。非公開データに直接アクセスしたり外部通信能力を持つ高リスクなツール（致命的三要素の枠組みに照らして判断できる）は、警報をほぼリアルタイムで処理すべきで、固定のセキュリティチームやプラットフォームチームのメンバーが持ち回りで担当する。公開情報の読み取りにのみ使われる相対的に低リスクなツールは、毎日または毎週まとめてバッチでレビューすればよく、変更のたびに通常の業務フローを中断する必要はない。
責任の所在については、ツールピン留めが生成する警報を、セキュリティチームだけに「この変更は妥当に見えるか」を一方的に判断させるべきではない。セキュリティチームは通常、各ツールの業務的な文脈に精通しておらず、ある機能更新が妥当かどうかを単独では判断できない。より現実的なアプローチは、警報をそのツールを実際に使用しているチーム（例えば特定のMCPサーバーを導入した製品チームやエンジニアリングチーム）にも同時に通知し、業務文脈を把握している当事者とセキュリティチームが共同で、変更が想定範囲内かどうかを確認することだ。これが、この仕組みを導入する前に、警報が発動した後誰がどれくらいの時間内に対応すべきか、責任分担をどうするかを明確にしておくことが、ツールをインストールすること自体よりも重要である理由でもある。明確なプロセスのない警報システムは、最終的に誰も本当には見ていない通知箱へと退化してしまうことが多い。
ラグプル攻撃への対処が最も難しいのは、攻撃手法がどれほど巧妙かという点ではなく、攻撃が観察上の構造的な死角を利用している点にある。すでに「安全だと確認されたもの」を、あなたは継続的に注視し続けたりはしない。あるツールが初期審査を通過し、よく使うリストに書き込まれ、複数のプロセスから依存されるようになると、それは「精査が必要な対象」から「背景に当たり前のように存在するインフラ」へと立場を変える。まさにこの瞬間こそが、攻撃者が行動を起こすタイミングとして選ぶものだ。この種の攻撃を防ぐには、人間の警戒心だけに頼ることはできない。「内容が変わったかどうか」を自動化され観察可能なシグナルへと変換する仕組みが必要だ。
この問題に対して業界が現在採用している最も直接的な技術的アプローチは「ツールピン留め（Tool Pinning）」と呼ばれるものだ。ツールが最初に審査を通過し信頼を得たその瞬間、その完全な説明テキストに対してハッシュ値を計算し記録する。その後、システムがそのツールとやり取りするたびに、現在のハッシュ値を再計算し、記録されている元の値と比較する。ツールの説明文の1文字でも改変されていれば、ハッシュ値は全く異なるものになる。この仕組みは「この新しい内容が悪意あるものかどうか」を理解する必要がなく、「内容が変わった」という事実そのものを検知するだけでよく、悪意の有無の判断は後続の人間によるレビューに委ねる。このアプローチの利点は、意味論的理解に依存しないため、「この新しい指示は専門的でもっともらしく見える」といったソーシャルエンジニアリングの手口に騙されない点だ。新しい内容がどれほど巧妙に偽装されていても、ハッシュ値が一致しなければ警報が発動する。
Invariant Labs（チューリッヒ工科大学発のスピンオフ企業で、マーティン・ヴェチェフ教授、フロリアン・トラメール教授ら研究者グループが共同設立）が開発したオープンソースのスキャンツールMCP-Scanには、すでにツールピン留め機能が組み込まれている。このツールは2つの動作モードを提供する。パッシブスキャンモードは一回限りの脆弱性チェック用で、設定ファイルに記載されたすべてのMCPサーバーをスキャンし、ツールの説明を取得し、ローカルチェックとInvariant Guardrails APIの呼び出しによる意味論レベルの悪意ある指示検知の両方を行う。アクティブプロキシモードは、ローカルに一時的なゲートウェイを注入してMCPトラフィックを継続的に監視・傍受し、クロスオリジンの権限昇格（ツールシャドウイング）の検知やポリシーに反するツール呼び出しのブロックなど、リアルタイムで保護ルールを執行する。MCP-ScanはGitHub上ですでに2,000を超えるスターを獲得しており、現時点で最も広く採用されているMCPセキュリティスキャナーだ。2025年6月にセキュリティ企業Snykに買収され、現在はSnykのエンタープライズ向けAgent Scan製品ラインに統合されて継続的にメンテナンス・更新されており、最新版は2026年4月にリリースされている。
ツールピン留めが確実に検知できるのは、ツールの説明テキスト自体へのあらゆる変更だ。その変更が攻撃者による悪意ある指示の植え付けによるものであれ、単なる正当な機能更新によるものであれ、ハッシュの不一致はどちらの場合も警報を発動させる。これは、この仕組み自体が「悪意ある変更」と「通常の更新」を区別できないことを意味し、「変更が発生した」ということしか教えてくれない。その後の判断には依然として人間の関与が必要だ。変更前後の差分を確認し、対応する公開の変更説明があるかを照合し、追加・修正された内容が妥当かを評価する。この限界は欠陥ではなく、意図的な設計上のトレードオフだ。自動化システムに意味論的な悪意の有無を判断させようとする（巧妙に偽装された攻撃には突破されやすい）よりも、その判断を人間に委ね、システムの役割を「あらゆる変更が気づかれずに見逃されないことを保証する」ことに限定する方が、より堅牢な役割分担である。これが、パッシブスキャン（一回限りのチェック）とアクティブプロキシ（継続的な監視）を組み合わせて使う必要がある理由でもある。パッシブスキャンが答えるのは「このツールは今クリーンか」であり、アクティブプロキシが答えるのは「このツールはその後ひそかに変更されていないか」だ。前者だけでは、依然としてラグプル攻撃に完全に晒されたままになる。
あなたのエージェントシステムが何らかのサードパーティのMCPサーバーに依存している場合、ツールピン留めの仕組みを導入することの実質的な効果は、「ラグプル攻撃がいつ発見されるか」を、「被害がすでに発生した後、事後に調査する」から「内容が変更された瞬間にすぐわかる」へと前倒しすることにある。この時間差が、攻撃可能な期間の長さと、フォレンジックにかかるコストの高さを直接左右する。この仕組みがなければ、あなたが頼れるのはツールが正常に動作しなくなる、あるいは明らかな異常を引き起こすまで気づかないことだけであり、その時点では攻撃者はすでに目的を達成している。この仕組みがあれば、たとえ変更が悪意あるものかどうかをすぐには判断できなくても、少なくとも変更が発生したその瞬間にレビュープロセスを起動でき、「何が起きたかわからない」状態と「変更が起きたことを把握し調査中である」状態を明確に区別できる。後者のリスクレベルと必要な対応リソースは、前者よりもはるかに低い。