AIの提案を使う前に検査するOSS「agent-security-scanner-mcp」を解説

「AIが勧めてきた部品の名前を、そのまま取り込んでいいのか分からない」「エージェントに読ませる資料や外部の道具に、変な指示が紛れていないか確かめる手段がない」——AIによる開発支援を全社に広げようとしている情報システム部門やセキュリティ部門で、よく話題にのぼる悩みです。どちらも、検査の道具を一つ入れれば解決する問題に見えます。しかし本当の課題は、道具の有無ではありません。AIの提案を「使う前」に、誰が・何を根拠に・どこまで確かめるのかが決まっていないことです。この記事では、AIが提案したパッケージ名や指示文、MCPサーバー（AIエージェントに外部の道具をつなぐための接続先）を使う前に調べるOSS「agent-security-scanner-mcp」を取り上げ、確かめられる事実、手元で完結する機能と外部につながる機能の違い、導入前に確かめるべき点を整理します。導入や操作の手順は扱いません。

agent-security-scanner-mcpとは何か。2026年10月時点で確かめられる事実

agent-security-scanner-mcpは、GitHubで公開されているOSSです。リポジトリの説明は「AIによるコード作成を支えるエージェントのための、MCPサーバー形式のセキュリティ検査の道具」で、READMEの冒頭ではAIのコード作成支援、MCPサーバー、指示文、AIが提案したパッケージのための検査の道具と紹介されています。Claude Code、Cursor、Windsurf、Cline、OpenCodeなどのエージェントが、新しいコードや道具、指示文、依存部品を信用する前に動かすもの、という位置づけです。

配布の形を確かめます。リポジトリは個人のアカウントにあり、2026年2月4日に作られました。ライセンスはMITです。2026年10月20日時点でスターは124、派生は12、最後の更新は10月18日でした。アカウントの表示名は「ProofLayer」で、配布用の設定ファイルには作者として「Sinewave AI」の名前があります。パッケージは開発者向けの配布サイトであるnpmで配られ、最新の版は2026年9月2日の4.5.10、これまでに出た版は82に上ります。npmの集計では、10月12日から18日までの1週間の取得数は203件でした。話題性はあるものの、利用の広がりはまだ限られた段階と読むのが妥当です。

使い方の形は複数あります。READMEによると、端末で直接動かす使い方、MCPサーバーとしてエージェントから呼び出す使い方、GitHubの自動処理に組み込む使い方、外部のクラウドの実行基盤で動かす使い方、そして同梱の「意味を読むコード確認」の機能です。一つのパッケージに性格の違う機能がまとめて入っていることが、この道具を理解するうえでの出発点になります。

なぜ今、AIの提案を「使う前」に調べる必要があるのか

AIにコードを書かせると、AIは必要な部品の名前も一緒に提案してきます。READMEは、AIはしばしば実在しない依存部品の名前をでっち上げ、攻撃者はその名前を後から乗っ取りうると説明しています。AIがもっともらしい名前を挙げ、開発者がそれを信じて取り込もうとしたとき、その名前で攻撃者が先に部品を公開していれば、不正な処理が社内に入り込むという筋道です。

もう一つは、エージェントが読む文章です。READMEは、エージェントは問い合わせの記録、ウェブページ、資料、道具の出力など、信頼できない文章を日常的に読んでいると指摘しています。その中に紛れ込ませた命令は、プロンプトインジェクション（AIへの不正な指示の紛れ込み）と呼ばれます。さらにMCPサーバーについては、道具の説明文に毒を仕込む、名前を有名な道具に似せる、環境に設定された秘密の値を持ち出す、命令を実行する、といった危険を挙げています。

どれも、AIが出したものを人がよく確かめずに使うところに入り口があります。AIの提案は便利だが、提案の出所や中身を確かめる工程が抜けやすいという構造的な弱点に対して、使う前の関門を置こうというのがこのOSSの考え方です。従来のコード検査の道具は、人が書いたコードの典型的な誤りを見つけることが中心でした。AI特有の入り口に絞った検査を用意している点に、この道具の特徴があります。

何を検査するのか。READMEが挙げる七つの危険

READMEの「何を見つけるか」の表には、七つの危険が並んでいます。一つ目は、AIが書いたコードの弱点です。データベースへの不正な命令の注入、画面への不正な処理の埋め込み、命令の注入、危ない暗号の使い方、秘密の値の書き込みが例に挙がっています。二つ目はMCPサーバーへの攻撃、三つ目はプロンプトインジェクション、四つ目は実行前のエージェントの危ない操作です。

五つ目が、AIがでっち上げたパッケージ名です。六つ目はSBOM（ソフトウェアの部品表）の作成と、依存部品の既知の脆弱性の照会、七つ目はプロジェクトの意図を読んで文脈に沿った問題を探す、AIを使った意味の確認です。検査の規則は1000件以上あり、構文の解析と、外から入った値がどこへ流れるかを追う解析を組み合わせているとリポジトリの説明にあります。

このほか、検査の結果をOWASPのAI向けの脆弱性の採点方式に当てはめて点数を付ける機能や、SOC2などの枠組みに照らした技術的な証跡をまとめる機能も説明されています。ただし、点数付けの説明文書は、検査結果を採点の項目に当てはめる部分は推定であり、権威あるものではないと自ら書いています。全体の点数も標準の方式ではなく、独自のものだと明記されています。点数は判断の材料にとどめるべきものです。

存在しないパッケージ名を見分ける仕組みと、その限界

この道具の看板の機能が、AIがでっち上げたパッケージ名の検出です。READMEによると、npmやパイソン向けの配布サイトを含む7つの言語の配布サイトにある、430万件以上のパッケージ名と照らし合わせます。ソースコードを見ると、名簿は配布物の中に同梱されており、大きな配布サイトの名簿にはブルームフィルター（大量の名前を小さなデータで照合する、確率的な仕組み）が使われています。照合は手元に持った名簿との突き合わせで行われる作りです。

ここには限界があります。一つは、確率的な仕組みの性質です。ソースコードでは、ブルームフィルターで一致したものは「おそらく存在する」と扱われ、確からしさは「中」とされています。存在しない名前が存在すると判定される可能性は、仕組み上ゼロにはなりません。もう一つは名簿の鮮度です。名簿は配布物に同梱された時点のものなので、その後に配布サイトへ登録された名前や消された名前は反映されません。

そして最も大事な点は、「名簿に存在する」ことは「安全である」ことを意味しないという点です。AIがでっち上げた名前を攻撃者が先に登録してしまえば、その名前は名簿上「存在する」ことになります。ソースコードには、存在が確認されたときに「使っても安全」という趣旨の文言を返す箇所がありますが、この道具が確かめているのは名前の存在であって、中身の安全性ではありません。存在の確認は第一の関門にすぎず、作者や公開時期、取得数などを人が確かめる工程は別に要ります。

指示文と操作の検査。許可・記録・警告・遮断の四段階

指示文の検査は、エージェントに渡す文章にプロンプトインジェクションや、AIの安全装置を外そうとする試みが含まれていないかを調べる機能です。ソースコードを見ると、文章を規則に照らして危険の点数を出し、「許可」「記録」「警告」「遮断」の四段階のどれかを返す作りになっています。扱う情報の重要度の設定に応じて、遮断や警告に切り替わる点数の基準を厳しくしたり緩めたりできます。

操作の検査は、エージェントが命令の実行、ファイルの操作、通信を行う前に、その中身を調べる機能です。ソースコードでは、ファイルをまとめて消す操作、外から取ってきた処理をそのまま実行する操作、データベースを壊す命令、記憶装置を直接扱う操作などが「遮断」の対象として定められています。エージェントが取り返しのつかない操作をする直前に、規則に当たるものだけでも止める仕組みを挟めるという意味があります。

一方で、どちらも規則に照らす方式です。規則は書き方の型を見るものなので、言い回しを変えた指示や、規則が想定していない操作は素通りする可能性があります。これは推測ですが、規則の型の検査をすり抜けるように書かれた文章が出てくることは十分に考えられます。READMEの安全の心得にも、指示文の検査は助けになるが、重要な操作に関わる指示は人の目でも確かめるべきという趣旨の一文があります。この道具は関門の一つであり、最後の判断ではありません。

MCPサーバーとスキルを入れる前の点検

MCPサーバーを社内のエージェントに追加する前に、その中身を調べる機能もあります。READMEの例では、道具の説明文にAIへの命令口調の文が含まれていること、道具の名前が有名な道具の名前に近いことが、重大な問題として示されています。ソースコードを見ると、説明文に隠された目に見えない文字の検出、命令を無条件に実行する書き方、ファイルの書き込みで場所を確かめていない書き方、外部への送信や環境に設定された秘密の値の露出に当たる書き方なども、規則として並んでいます。

確認したソースコードの範囲では、この点検は対象のフォルダーにあるファイルを読み、規則に照らす作りでした。MCPサーバーを実際に起動したり、接続したりする処理は、点検の本体には見当たりませんでした。同じ分野のほかの道具には、説明文を取り出すために接続先を実際に動かすものもあるため、この違いは導入時の安全面に関わります。ただし、すべての機能の動きを確かめたわけではありません。

エージェントに作業のやり方を教える手順書であるスキルについても、点検の機能があると説明されています。手順書の中に紛れた不正な指示は、従来の検査では拾いにくい種類の危険です。文章の形をした部品も、取り込む前に検査の対象にするという考え方そのものは、社内の決まりに取り入れる価値があります。

手元で完結する機能と、外部につながる機能

防御担当者にとって、どの情報が社外へ出るのかは最も大事な点です。READMEのよくある質問では、規則による検査は端末でもMCPサーバーでも手元で行われ、意味を読むコード確認は利用者が選んだAIの提供元を使うと説明されています。パッケージ名の照合も、前の章のとおり同梱の名簿で行う作りです。

一方、外部につながる機能もはっきりあります。依存部品の既知の脆弱性の照会は、公開の脆弱性データベースであるOSVに問い合わせます。意味を読むコード確認は、選んだAIの提供元にコードを渡して解析させるものです。さらに、検査の証跡をProofLayerのVanta連携へ書き出す機能や、外部のクラウドの実行基盤Apify上で、リポジトリの所在を渡して検査させる使い方も案内されています。「OSSだから全部手元で動く」とは限らないということです。

このため、導入を検討するときは機能ごとに分けて考える必要があります。規則による検査とパッケージ名の照合だけなら、手元で完結するとされています。脆弱性の照会では部品の名前と版が外部へ出ます。意味を読むコード確認や外部の実行基盤では、コードそのものが社外のサービスに渡ります。どの機能を使ってよいかを、情報の区分に照らして決めることが前提です。なお、外部のサービスが受け取った情報をどう扱うかは、それぞれのサービスの規約によります。

似た手段と何が違うのか

AIの提案を使う前に確かめる方法は、この道具だけではありません。一次情報で確認できた範囲をもとに、代表的なやり方と比べます。いずれも優劣ではなく、何を守りたいかで選ぶ話です。

見る点	人が目で確かめる	従来のコード検査・依存部品の監査	agent-security-scanner-mcp
でっち上げのパッケージ名	配布サイトで一つずつ調べれば分かる	多くは対象外	同梱の名簿と照合して、存在しない名前を示す
指示文に紛れた命令	読めば気づける場合がある	対象外のことが多い	規則に照らし、四段階で判定する
エージェントの危ない操作	その場で止めるのは難しい	対象外	実行の前に規則に当たるものを遮断できる
MCPサーバーの中身	コードを読める人に限られる	一般的な弱点は拾える	説明文の命令口調や名前の偽装も規則で見る
社外への送信	なし	製品による	規則の検査は手元。照会や意味の確認は外部とつながる
判定の根拠	確かめた人の記録	検出名	規則の名前・重大度・点数

表のとおり、この道具の特徴は、AI特有の入り口に絞った規則を一つの道具にまとめている点です。従来の検査や依存部品の監査を置き換えるものではなく、その隙間を埋めるものと読むのが妥当でしょう。READMEも、依存部品の監査の道具の代わりではなく、それを補うものだと明記しています。

安全性の評価：注意付きとした根拠

このラインでは、紹介する題材を公開されている事実だけを基に精査しています。題材を入手したり動かしたりはしていません。agent-security-scanner-mcpの判定は「注意付き」です。悪意を示す報告は見当たりませんでしたが、導入前に確かめるべき点が三つあるためです。

まず、問題が見つからなかった事実です。ライセンスはMITで、GitHub上にこのリポジトリのセキュリティ勧告は登録されていませんでした。弱点の報告の窓口として、公開の場ではなく電子メールで知らせるよう求める方針の文書があり、受け付けから48時間以内に返答すると書かれています。変更の記録を見ると、依存部品の脆弱性への対応や、検査の見落としの修正が継続して行われています。放置されたリポジトリではないことは確かめられます。

そのうえで注意付きとした根拠は次の三点です。一つ目は、パッケージを入れるときに自動で動く処理があることです。二つ目は、作者の実績が乏しいことです。アカウントは2024年1月に作られていますが、公開リポジトリは3件、フォロワーは6人で、運営体制を外から確かめられる材料は限られます。三つ目は、記録の食い違いです。詳しくは次の二つの章で説明します。

なお、この判定は安全の保証ではありません。精査は公開情報の範囲に限られ、コードの全体を検証したものではないからです。注意付きは「使ってはいけない」という意味ではなく、入れるときに何が起きるかと、どの機能を使うかを先に決めてから使うべき道具という意味です。

インストール時に自動で動く処理という注意点

配布用の設定ファイルには、パッケージを入れたときに自動で動く処理が登録されています。その処理の中身を記したファイルを読むと、パイソンが見つかれば、構文解析のための部品を利用者のパイソン環境に追加しようとする作りでした。部品の追加は、その利用者のアカウント全体に効く場所に対して行われます。プロジェクトの中だけで完結する変更ではありません。

さらに、同梱の「意味を読むコード確認」の機能について、必要な部品がそろっていなければ、追加の部品を取り込んで組み立てる処理も続けて動きます。処理のファイルの注記には、この機能の依存先として、AIの提供元とやり取りするための部品が挙がっています。つまり、使うつもりのない機能の部品まで、入れた時点で取り込まれうるということです。処理の内容は公開されており、不審な送信などは確認した範囲で見当たりませんでした。

それでも、入れた時点で外部から部品が追加で取り込まれ、利用者の環境が書き換わることは、企業の端末の管理では見過ごせない点です。自動で動く処理は、正規の道具でも乗っ取られた場合の被害の入り口になりえます。自動で動く処理を止めた状態で入れられるか、止めた場合に何の機能が使えなくなるかを、導入前に確かめておく必要があります。

運営体制と版の記録から読み取れること

版の記録には、いくつか食い違いがあります。変更の記録では1.0.0が2025年12月1日とされていますが、npmで最初の版が公開されたのは2026年2月1日、GitHubのリポジトリが作られたのは2月4日です。また、npmの最新は4.5.10ですが、変更の記録は4.5.8までで止まっており、GitHubのリリースの一覧の最新は6月の4.4.5です。どの記録を見るかで「最新」が違う状態です。

弱点の報告の方針の文書では、支援の対象の版が2系と書かれたままで、現在の4系への言及がありません。過去の問題として、2.0.0より前の版でファイルの場所の扱いに命令の注入の弱点があり、修正されたことが記されています。また、リポジトリの直下には、競合との比較をまとめた表計算のファイルや、パソコンが自動で作る隠しファイルが置かれたままになっています。小さな体制で速く更新している様子がうかがえますが、文書の手入れが追いついていない点は、企業が導入するうえで確認の材料になります。

変更の記録には、守りの道具として示唆の多い修正も載っています。2026年5月の4.3.0では、GitHubの自動処理に組み込んだ検査で、出力が壊れたときに「問題0件」と扱われ、関門を通ってしまう不具合が直されました。4.4.1では、名前が点で始まるフォルダーを丸ごと飛ばしていた見落としが直されています。どちらも、検査の道具にも見落としや誤った合格がありうることを示す実例です。

悪用されうるリスク

agent-security-scanner-mcpは守りのための道具で、攻撃に使うための道具ではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、「検査で何も出なかった」「名簿に存在した」という結果が、安全の証明として独り歩きすることです。前の章で見たように、検査の道具自体にも見落としがありえます。

次に挙げるのは推測ですが、検討の材料として無視できません。この種の道具が広まれば、攻撃者は規則の型をすり抜ける書き方を工夫したり、AIがでっち上げそうな名前を先回りして配布サイトに登録したりする可能性があります。後者の場合、名前の存在の確認はかえって「存在するから安心」という誤った裏付けを与えかねません。検査の道具がある以上、それをすり抜けようとする工夫も生まれると考えておくのが自然です。

もう一つは、道具そのものの供給の経路です。パッケージを入れるときに自動で動く処理があり、版の公開の頻度も高い道具では、配布の経路が乗っ取られた場合の影響が大きくなります。これも一般論としての推測です。なお、この道具が実際に悪用された事例は、2026年10月20日時点で確認した一次情報からは見つけられませんでした。

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

実際に検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、ツールを動かす前の段階で終えられるものに絞っています。

この手順の要は、動かす前に「何が自動で起きるか」と「誰が結果を判断するか」を決めておくことです。検査の道具は、入れた瞬間から「調べている」という安心を生みます。その安心の中身を先に決めておかないと、検査の結果が誰にも読まれない状態や、検査を通ったことだけを根拠に部品が取り込まれる状態が続きます。

企業が取るべき対策

一つ目は、AIが提案した部品を取り込むときの決まりを作ることです。新しい依存部品は、名前の存在だけでなく、作者、公開の時期、取得数、変更の履歴を確かめてから取り込む、と文書にします。検査の道具は、この確認の最初の関門として位置づけます。

二つ目は、エージェントに足してよいMCPサーバーとスキルの一覧を作ることです。許可したもの、確認中のもの、使わないものに分け、検査の道具は一覧に載せる前の確認の手段として使います。把握していない部品は、検査の対象にもならないからです。三つ目は、エージェントの危ない操作に対する関門です。規則による遮断に加えて、取り返しのつかない操作は人の承認を挟む設計にします。

四つ目は、検査の道具そのものの管理です。自動で動く処理のある道具は、入れる端末と入れ方を限定し、版を固定して更新を管理します。五つ目は、社外へ出る情報の決まりです。脆弱性の照会やAIを使ったコード確認のように、外部につながる機能を使うときの条件を、ほかの開発支援の道具と同じ基準で決めます。

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

この道具は、人が見落としがちなAI特有の入り口を規則で見張り、怪しい箇所を示してくれます。同梱の意味を読むコード確認ではAIそのものが解析に使われます。だからこそ、検査の結果をAIや道具の判断のまま受け入れず、根拠を人が読むことが欠かせません。道具に任せてよいのは、決めた範囲の中で、人が読み切れない量のコードや文章を規則に照らす部分です。

具体的には、どの機能を使ってよいか、どの結果で使用を止めるか、名簿に存在した部品の中身を誰が確かめるか、例外を誰が認めるか。この四つは道具にもAIにも委ねず、人が決めて記録に残します。やってはいけない向き合い方を挙げます。

• 「名簿に存在する」という結果だけを理由に、AIが提案した部品をそのまま取り込む
• 「検査で何も出なかった」ことを、指示文や外部の道具が安全な証明として扱う
• 外部につながる機能があることを確かめずに、社内のコードを検査にかける
• 入れたときに自動で動く処理の中身を確かめずに、業務の端末へ一斉に配る
• 点数だけを見て、規則の名前や根拠を読まずに使用の可否を決める
• エージェントの危ない操作の判断を、規則による遮断だけに任せて人の承認を外す

裏を返せば、人が決める範囲ははっきりしています。どの機能を使うか、どの結果で止めるか、誰が中身を確かめるか、誰が例外を認めるか。この四つが決まっていないまま検査の道具を入れても、守りの厚みは増えません。AIに判断させず、根拠を示させ、人が確認する範囲を先に決めることが基本です。

よくある質問：社外に送らずに使えるのか

READMEの説明では、規則による検査は手元で行われ、パッケージ名の照合も同梱の名簿で行う作りです。この範囲の機能に絞れば、コードを社外に出さずに使える設計とされています。ただし、脆弱性の照会、意味を読むコード確認、外部への書き出し、外部の実行基盤での検査は、それぞれ外部のサービスとつながります。どの機能を使うかで答えが変わる、というのが正確な答えです。

もう一つ、「無料で公開されているOSSなら、全社の端末で使ってよいのか」という問いもありそうです。ライセンスはMITで、利用の条件は緩やかです。ただし、入れたときに自動で動く処理があり、作者の実績が乏しく、記録にも食い違いがある以上、ライセンスの自由さと、企業の端末に入れてよいかは別の判断です。まず限られた環境で、使う機能と入れ方を決めてから広げるのが現実的です。

• agent-security-scanner-mcpの機能・版・配布の形・自動で動く処理の中身は、GitHubのリポジトリとその中の文書・ソースコード、npmの登録情報を2026年10月20日に確かめた範囲に基づきます。内容は変わる可能性があります
• すべての機能の動きや、外部のサービスが受け取った情報の扱いは、確認した一次情報の範囲では十分に確かめられませんでした。導入の判断では提供元の最新の資料を確認してください
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

agent-security-scanner-mcpは、AIが書いたコード、AIが提案したパッケージ名、指示文、エージェントの操作、MCPサーバーやスキルを、使う前に規則や名簿に照らして調べるOSSです。MITで公開され、存在しないパッケージ名の検出や、指示文と操作の四段階の判定など、AI特有の入り口に絞った検査をまとめています。規則による検査とパッケージ名の照合は手元で完結するとされる一方、脆弱性の照会や意味を読むコード確認などは外部とつながります。

一方で、入れたときに自動で動く処理があり、作者の実績が乏しく、版の記録にも食い違いがあるため、判定は注意付きとしました。名簿に存在することは安全を意味せず、検査で何も出ないことも安全の証明ではありません。どの機能を使うか、どの結果で止めるか、誰が中身を確かめるか、誰が例外を認めるかは、道具ではなく人が決める範囲です。この四つを先に決めたうえで使うことが、AIの提案を受け入れる前の関門として、この道具を生かす方法です。

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