MCPサーバーに潜む危険をOSS「MCP Scanner」はどう見つけるのか

「社内の開発者が、公開されているMCPサーバーを次々にAIエージェントへつないでいる。中身を誰も確かめていない」「検査の道具があると聞いたが、何をどこまで見てくれるのか、外へ何が送られるのかが分からない」——AIエージェントの利用が広がった企業の、情報システムとセキュリティの担当者が口にする悩みです。検査の道具を一つ入れれば片づく話に見えますが、そうではありません。本当に問われているのは、どの検査を、どこで、誰の判断で通したら「つないでよい」とするのかという線の引き方です。この記事では、Ciscoが公開しているOSS「MCP Scanner」を取り上げ、MCPサーバーのどこに潜む危険を、どの仕組みで見つけようとしているのかを、外部のサービスを使う部分と手元で完結する部分に分けて整理します。導入や操作の手順は扱いません。

MCP Scannerとは何か。2026年10月時点で確かめられる事実

MCP Scannerは、MCP（AIエージェントが外部の道具やデータを呼び出すための共通の取り決め）のサーバーと、その道具を検査するためのPythonで書かれたオープンソースのソフトウェアです。READMEは、Ciscoの検査サービス、YARA（ヤーラ。文字列などの特徴で不審なものを見つける規則の書式）の規則、そして大規模言語モデルによる解析を組み合わせて、悪意のあるMCPの道具を見つけるもの、と説明しています。ライセンスはApache-2.0です。

公開元は、Ciscoのブランドを掲げる組織アカウントです。アカウントは2025年7月に作られ、公開しているリポジトリは17件あります。MCP Scannerのリポジトリは2025年9月24日に作られ、2026年10月20日時点でスターは約1,100、派生は148、最後の更新は10月19日でした。スターの伸びは1日あたり3件ほどで、話題に乗って急に膨らんだ形ではなく、着実に使われてきた道具と読めます。

配布の面では、Pythonのパッケージ置き場であるPyPIに、最初の版の1.0.1が2025年9月25日に登録されています。2026年10月7日には4.8.6が出ており、約1年で大きな版を何度も重ねてきたことが分かります。作者の欄はCiscoとされています。動かすにはPython 3.11以上が必要です。

なぜ今、MCPサーバーの検査が求められているのか

Ciscoが2025年10月23日に公開したブログは、問題の出発点を「AIエージェントのサプライチェーン」と表現しています。MCPは、個別の連携の作り込みなしに、AIエージェントが外部の道具を使えるようにする取り決めです。便利な反面、公開の登録所には第三者が作ったコードを動かすMCPサーバーが数千単位で並んでいるとブログは指摘しています。

ブログが挙げる主な危険は三つです。一つ目は、道具の説明文や付随する情報、コードの中に悪意のある指示を隠しておく「道具への毒の仕込み（ツールポイズニング）」。二つ目は、いったん信頼された道具が、後の更新で悪意のある振る舞いに差し替わる「ラグプル（信頼を得たあとの裏切り）」。三つ目は、ファイルやネットワーク、システムの呼び出しなど、必要以上に広い権限を持つ道具が、許可されていない操作をしてしまうことです。

これらに共通するのは、AIエージェントは、道具の説明文を指示として読んでしまうという点です。ふつうのソフトウェアなら、説明書きに何が書かれていても動作は変わりません。しかしAIエージェントは、道具の説明を読んで次の操作を選びます。そのため、コードの欠陥だけでなく、説明文そのものが攻撃の入口になる。従来のコード検査だけでは足りない理由がここにあります。

三つの検査の仕組みを、手元か外部かで分けて見る

READMEとブログによれば、MCP Scannerの中心には三つの検査の仕組みがあり、組み合わせても、一つずつでも使えます。一つ目はYARAの規則による照合で、これは手元で動き、外部への通信を必要としません。利用者が自分の規則を足すこともできます。

二つ目は、大規模言語モデルによる解析です。道具の説明、プロンプト、資源（MCPサーバーが提供するデータ）、サーバーからの指示文の意味を読み取り、怪しさを判定します。READMEは複数のAIの提供元を例に挙げ、自社の環境で動かすモデルにつなぐこともできるとしています。三つ目は、Ciscoの検査サービスへ内容を送って判定する仕組みで、利用には同社のサービスの鍵と契約が必要です。

ここで押さえたいのは、「MCP Scannerで検査した」だけでは、データが外へ出たかどうかが分からないという点です。規則による照合だけなら情報は手元にとどまります。AIによる解析やCiscoの検査サービスを使えば、検査対象の説明文や指示文が外部の事業者へ送られます。どの仕組みを使ったかを、結果と一緒に記録しておくことが、社内での説明の前提になります。

道具の説明文と指示文から、隠された命令を探す

MCP Scannerが検査の対象にするのは、MCPサーバーが公開している道具の一覧だけではありません。READMEによれば、プロンプト、資源、そしてサーバーが接続のときに渡す指示文までを対象にしています。動いているサーバーに接続して検査することもできれば、AIの開発環境や対話アプリが使うMCPの設定ファイルを読み、登録されているサーバーをまとめて調べることもできるとされています。

検出した結果は、Ciscoが整理した脅威の分類に結びつけられます。分類の文書では、直接のプロンプトインジェクション（入力に紛れ込ませた命令でAIを操る攻撃）、データの持ち出し、エージェントの仕組みの不正な操作、サプライチェーンの侵害、道具の悪用、有害な内容の六つの区分が示されています。道具の悪用の中には、道具への毒の仕込みと、正規の道具になりすます「シャドーイング」が含まれます。

区分ごとに、どの検査の仕組みが担当するかも書かれています。たとえば、道具への毒の仕込みやなりすましはAIによる解析が、認証情報の窃取やコードの実行につながる記述は規則による照合が受け持つ、という分担です。裏を返せば、規則による照合だけでは、道具への毒の仕込みのような意味の読み取りを要する危険は拾いにくい。手元で完結させたい組織ほど、この取りこぼしを意識しておく必要があります。

説明と実装の食い違いを追う振る舞いの解析

説明文だけを見ても、コードが実際に何をするかは分かりません。そこでMCP Scannerは、MCPサーバーのソースコードそのものを調べる振る舞いの解析を備えています。文書によれば、この解析はまずコードを構文として読み解き、道具として公開されている関数を見つけ、関数ごとの処理の流れを組み立てます。

次に、道具に渡される引数を信頼できない入力とみなし、それが代入や呼び出しを通じてどこへ流れていくかを追います。ファイルをまたぐ呼び出しも、一定の深さまで追うとされています。最後に、関数の説明書き（何をする関数かを書いた注釈）と、実装が実際に行う操作を大規模言語モデルに比べさせ、説明にない操作が隠れていないか、説明と実装が一致しているかを判定させます。モデルの答えは決まった形式かどうかを確かめたうえで、脅威の分類に結びつけます。

この仕組みの狙いは、「天気を調べる」と説明しながら裏で手元の鍵を外へ送る、といった食い違いを捕まえることです。文書は、データの持ち出しの可能性、注入の弱点、説明にない操作などを見つける対象に挙げ、結果には高・中・低の深刻度が付くとしています。ただし、この解析は大規模言語モデルの利用が前提で、コードの情報が設定したAIの提供元へ送られます。

部品・ファイル・運用面まで広がる検査の範囲

MCP Scannerは、MCPサーバーの周辺にある部品にも検査の範囲を広げています。READMEによれば、Pythonの依存関係に既知の弱点（CVEなどの番号が付いたもの）がないかを、公開の弱点の情報と照らして調べる機能があります。PyPIや別の言語の部品置き場の部品を取り寄せ、隔離したDockerの環境の中で調べる機能もあり、部品のコードは実行しないと明記されています。

サーバーに同梱された画像や文書、実行ファイル、圧縮ファイルについては、VirusTotal（複数のウイルス対策製品の判定を集めた外部サービス）にファイルの指紋（ハッシュ値）を照会する機能があります。既定では指紋の照会だけで、未知のファイルそのものを送る動きは既定で切られているとREADMEは書いています。

もう一つ特徴的なのが、運用面の点検です。文書によれば、時間切れの設定がない、再試行の上限がない、エラーの返し方が決まっていない、説明があいまい、一つの道具に役割を詰め込みすぎている、削除や実行といった危険な操作を表す語が含まれる、などの20の規則で道具を点検し、0から100の点数を付けます。これは安全かどうかではなく、本番で使い続けられる作りになっているかを見るもので、外部の鍵を必要としません。

つながずに検査する。保存した記録を調べる使い方

動いているMCPサーバーに接続すること自体を避けたい場面もあります。MCP Scannerは、あらかじめ書き出した道具やプロンプトの一覧の記録を読み込み、サーバーにつながずに検査する使い方を用意しています。文書は、規則による照合と組み合わせれば外部への通信なしに検査でき、インターネットから切り離された環境でも使えると説明しています。

文書が挙げる用途は、開発の流れに組み込んで配備の前に検査する、問題が見つかったら取り込みを止める、基準となる記録を版で管理して新しく増えた問題だけを指摘する、監査の証跡として残す、といったものです。検査を一度きりの儀式にせず、変更のたびに繰り返す仕組みにするという考え方で、ブログが挙げた「信頼を得たあとの裏切り」への備えにもつながります。

一方で、文書自身が限界も書いています。調べるのは渡された記録だけで、道具が実際に動いたときの振る舞いは見えません。文脈によって初めて表れる弱点も見落としうる、とされています。記録を書き出す作業も手作業になるため、記録と実物が食い違っていないかは、別の手段で確かめる必要があります。

結果の受け取り方と、社内の仕組みへのつなぎ方

READMEによれば、MCP Scannerは、手元で使う命令の形の道具としても、社内の別の仕組みから呼び出す常駐型のサービスとしても動かせます。Pythonのプログラムから部品として呼び出す使い方も用意されています。常駐型のサービスとして動かせば、社内の検査の窓口として、道具一つずつ、あるいはサーバー全体の検査を受け付ける形にできます。

結果は、要約、詳細、表、深刻度ごとの一覧、機械で読める形式などで出力でき、道具ごとに安全か危険かの判定と、検査の仕組みごとの内訳が示されます。深刻度は高・中・低の段階で表されます。検査対象のサーバーに接続するための認証の方式も複数用意されています。

ここで大事なのは、結果を誰が受け取り、どう判断するかを先に決めておくことです。「危険」と出た道具をどうするかは、道具ではなく社内の規則が決めるものです。深刻度が低い指摘を放置してよいのか、どの区分の指摘なら即座につなぐのを止めるのか。判定の基準を人が文書にしておかないと、結果は読まれないまま積み上がります。

他の検査手段との違い

MCPサーバーを確かめる手段は、MCP Scannerだけではありません。人が説明文とコードを読む方法、従来のコード検査や部品の弱点の照合、そして同じくMCPやエージェントの部品を検査する別の道具があります。後者の例として、Snykが公開しているSnyk Agent Scanがあります。リポジトリの説明によれば、手元の環境にあるMCPサーバーや道具、エージェント向けの手順書を見つけて検査し、判定には提供元の解析サービスを使います。ライセンスはApache-2.0です。

見る点	MCP Scannerの場合	Snyk Agent Scanの場合	従来のコード検査・部品の照合
主に見るもの	道具の説明文・指示文、ソースコードの振る舞い、部品、同梱ファイル、運用面の作り	手元の環境にあるMCPサーバー・道具・手順書	コードの欠陥、部品の既知の弱点
判定の場所	規則と運用面の点検は手元。AIの解析・Ciscoの検査サービス・ファイル照会は外部	提供元の解析サービス	製品による（手元か外部か）
説明文の悪意を読めるか	AIの解析を使えば対象になる	対象になる	ほぼ対象外
つながずに検査	保存した記録の検査に対応	公開情報からは未確認	対応するものが多い
ライセンス	Apache-2.0	Apache-2.0	製品による

表から読み取れるのは、MCP Scannerは、手元で完結する検査と外部に頼る検査を、利用者が選んで組み合わせられる点が特徴だということです。逆に言えば、組み合わせ方を誤ると、手元で完結していると思い込んだまま外部へ送っている、あるいは手元だけで済ませて大事な危険を見落とす、という両方の失敗がありえます。どの道具が上かではなく、自社の情報の扱いの決まりに合う組み合わせを選ぶのが順序です。

安全性の評価：紹介可とした根拠

このラインでは、紹介するOSSを、公開されている事実だけを基に精査しています。OSSをダウンロードしたり動かしたりはしていません。MCP Scannerの判定は「紹介可」です。

根拠にした事実は次のとおりです。公開元はCiscoのAIセキュリティの製品名を掲げた組織アカウントで、同社のブログが公開を告知しており、PyPIの作者の欄もCiscoです。ライセンスはApache-2.0で、商用利用を妨げる条件は見当たりません。GitHub上にこのリポジトリのセキュリティ勧告は登録されておらず、導入の途中で自動的に動く処理を置くファイルも、リポジトリの直下には見当たりませんでした。スターの伸び方にも不自然な点はありません。

弱点の報告の窓口も整っています。セキュリティの方針の文書は、非公開の報告の仕組みを使うよう求め、3営業日以内に受領を伝え、さらに3営業日以内に詳しい返答をすると約束しています。一方で、どの版を保守の対象にするかは文書に書かれていません。

なお、ここで問題が見つからなかったことは、安全の保証ではありません。この精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。導入の可否は、自社の確認の手順に沿って判断してください。

導入前に知っておきたい注意点

紹介可とはいえ、一次情報を読むと気になる点があります。一つ目は、外部へ送られる情報です。Ciscoの検査サービスと、AIによる解析、振る舞いの解析は、検査対象の説明文やコードの情報を外部の事業者へ送ります。Ciscoの検査サービスの利用には同社との契約が必要で、送った内容の扱いはOSSのライセンスとは別の契約の条件で決まると考えるべきです。この契約の中身は、この記事の調べの範囲では確認していません。

二つ目は、文書の食い違いです。振る舞いの解析の文書は、対応する言語として十を挙げる一方で、限界の節ではPythonのみに対応すると書いています。どちらが現状に合うのか、公開情報からは判断できません。対応範囲は、自社のMCPサーバーの言語で実際に確かめる必要があります。

三つ目は、版の進みの速さです。約1年で版の番号が1から4まで上がっており、機能の追加が続いています。検査の結果を監査の証跡に使うなら、どの版の、どの規則で検査したかを結果と一緒に残すことが欠かせません。四つ目に、READMEが動作を確かめたAIのモデルとして挙げているのは一部の提供元のものに限られます。それ以外のモデルを使った場合の判定の質は、公開情報からは分かりません。

悪用されうるリスク

ここからは、一次情報で確認した事実ではなく、構成から導かれる推測を含みます。MCP Scannerは守りのための道具で、攻撃のために作られたものではありません。それでも、使い方によって生まれうる危険はあります。最も大きいのは、「検査済み」という印が、かえって確認を弱めることです。

推測として挙げます。まず、検査の規則や判定の基準が公開されている以上、攻撃する側も、規則に引っかからない書き方を試せる可能性があります。規則による照合はとくに、知られた型から外れた書き方に弱いと考えられます。次に、AIによる解析は、検査対象の説明文そのものを読むため、説明文に検査役のAIを惑わせる文言が仕込まれる可能性も否定できません。文書も、強く難読化されたコードは見落としうると認めています。

さらに、検査が見るのは検査した時点の姿です。ブログが挙げた「信頼を得たあとの裏切り」のように、検査の後で中身が差し替わる危険には、一度の検査では対応できません。なお、MCP Scannerそのものが悪用された事例は、2026年10月20日時点で一次情報からは確認できませんでした。

導入を検討するときに確かめること

MCP Scannerのような検査の道具を検討するとき、機能の一覧より先に確かめたい点があります。下の手順は、OSSを動かす前の段階で、資料と社内の取り決めによって確かめられることに絞っています。

この手順の要は、道具を入れる前に、検査結果を何の判断に使うのかを決めておくことです。目的が決まっていない検査は、結果の数だけが増え、誰も読まない報告書になりがちです。

企業が取るべき対策

MCP Scannerを入れるかどうかにかかわらず、MCPサーバーの利用について企業として決めておきたい対策を挙げます。一つ目は、社内で使ってよいMCPサーバーの一覧を作り、一覧にないものはつながないことです。検査は、この一覧に載せる前の関門として位置づけると役割がはっきりします。

二つ目は、MCPサーバーに渡す権限を最小にすることです。検査で問題が見つからなくても、ファイルやネットワークへの広い権限を与えれば、見落としがそのまま被害の大きさになります。三つ目は、版を固定することです。更新は自動で取り込まず、新しい版を検査してから切り替えます。ブログが挙げた「信頼を得たあとの裏切り」への最も素直な備えです。

四つ目は、検査の結果と、外部へ送った情報の記録を残すことです。どの検査の仕組みを使い、どの事業者に何を送ったかを、監査の際に説明できるようにします。五つ目は、調達の段階での確認です。Ciscoの検査サービスを使うなら、送った内容の扱い、保管の期間、学習への利用の有無を契約の条件で確かめます。検査の道具も、それ自体がサプライチェーンの一部として扱います。

AIに任せる範囲と、人が決める範囲

MCP Scannerの検査の一部は、大規模言語モデルの判定に頼っています。説明文の意味を読む、説明と実装の食い違いを見つける、といった仕事は、規則だけでは難しいからです。しかし、AIの判定はあくまで手がかりです。AIに最終的な可否を判断させず、判定の根拠を書かせ、人が確かめる範囲を先に決めることが前提になります。

振る舞いの解析の文書も、モデルの答えを決まった形式に照らして確かめる仕組みを持ち、実行時にしか表れない振る舞いは見えないと限界を書いています。道具の作り手自身が、AIの判定を万能とは扱っていないわけです。やってはいけない向き合い方を挙げておきます。

• 検査で「安全」と出たことだけを理由に、権限の広いMCPサーバーを本番のAIエージェントにつなぐ
• どの検査の仕組みを使ったかを確かめずに、機密を含むコードの情報を外部の解析へ送る
• AIの判定が「危険」と出た理由を読まずに、指摘をまとめて無視する
• 一度検査したMCPサーバーを、版を固定せずに自動で更新し続ける
• 検査に使った版と規則を記録せず、結果だけを監査の証跡として保管する

人が決める範囲ははっきりしています。どのMCPサーバーをつなぐか、外部へ何を送ってよいか、どの指摘で止めるか、いつ検査し直すか。この四つは道具にもAIにも委ねず、人が決めます。道具に任せてよいのは、人が決めた基準に沿って、決まった形の危険を速く広く拾い上げる部分です。

よくある質問：検査を通ればMCPサーバーは安全なのか

答えは「それだけでは決まらない」です。MCP Scannerの文書自身が、保存した記録の検査は実際の振る舞いを見ないこと、振る舞いの解析は実行時にしか表れない動きや強く難読化されたコードを見落としうることを書いています。検査は、見つかった危険を減らす手段であって、見つからなかった危険がないことの証明ではありません。

では、外部のサービスを使わない検査だけで足りるのか、という問いもありそうです。規則による照合と運用面の点検だけなら情報は手元にとどまりますが、道具への毒の仕込みのように意味の読み取りを要する危険は拾いにくくなります。現実的なのは、機密度の低い公開のMCPサーバーにはAIによる解析も使い、社内のコードには自社の環境で動かすモデルか手元の検査に限る、という使い分けです。

最後に、「Ciscoの検査サービスを契約しないと使えないのか」という問いです。READMEでは、Ciscoの検査サービスの鍵は必須ではなく任意とされ、規則による照合などはそれなしで使えます。中心の部分はOSSとして単独で使え、Ciscoの検査サービスは追加の選択肢という位置づけです。

• MCP Scannerの機能・版・文書の内容は、GitHubのリポジトリとその中の文書、Ciscoのブログ、PyPIの記録を2026年10月20日に確かめた範囲に基づきます。内容は変わる可能性があります
• Snyk Agent Scanに関する記述は、同リポジトリの説明の範囲です。比較は、それぞれの一次情報で確認できる範囲に限っています
• この記事は防御と評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

MCP Scannerは、Ciscoが公開した、MCPサーバーとその周辺を検査するOSSです。道具の説明文や指示文に隠された命令、説明と実装の食い違い、部品の既知の弱点、同梱ファイル、運用面の作りまでを、性格の違う複数の仕組みで調べます。その中には、手元で完結する仕組みと、AIの提供元やCiscoの検査サービスへ情報を送る仕組みが混在しています。

だからこそ、結果を読む前に、どの仕組みで検査したのか、外へ何を送ったのかを確かめる必要があります。検査を通ったことは安全の保証ではなく、検査の後に中身が差し替わる危険も残ります。検査の道具を選ぶ基準は、検出できる危険の数ではなく、自社が何を外へ出せて、誰がどこで止めるかに置く。MCPサーバーをAIエージェントにつなぐ判断は、その線を人が引いたうえで下すのが確かです。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。