MCP（Model Context Protocol）という言葉、最近かなり見かけるようになりました。ざっくり言うと、AIエージェントが外部のツールやファイル、APIにアクセスするための「通訳」みたいな仕組みです。便利です。めちゃくちゃ便利。でも便利なものは、だいたい強い権限も持ちます。そこが怖い。
今回紹介する記事は、そんなMCP serverをどう監査するか、という話です。DEV Community に掲載された How to Audit Your MCP Servers for Security Risks は、MCP server を「とりあえず動けばOK」で配る危うさをかなり真正面から突いています。正直、かなり大事なテーマだと思います。
mcp-security-scan という OSS の CLI / GitHub Action が紹介されている
記事の主張はシンプルです。MCP server は、LLM と外の世界の“間”に立つので、権限が大きい。ファイルを読めるし、API を叩けるし、外部へ通信もできる。つまり、攻撃者から見るとかなりおいしい場所です。
しかも、AI の世界では「モデルが変なことを言った」だけで済まないのが厄介です。モデルの出力がそのままツール呼び出しに使われると、意図しない URL にアクセスしたり、環境変数を吐いたり、ファイルを触ったりする。人間のコードなら「そんな処理書かないよ」で終わる話が、エージェント経由だと一気に現実になります。
記事では、こうした MCP server を「昔の npm パッケージみたいに、とりあえず入れて信じる」扱いにしているチームが多い、とかなり辛口に書いています。これは言い過ぎに見えて、実はわりと本質的だと思います。便利なツールほど、使う側の警戒心が薄れやすいんですよね。
記事が挙げているリスクは4つです。どれも地味だけど、地味だからこそ厄介です。
まず credential theft。これは、MCP server が環境変数を雑に読んだり、リクエストやレスポンスをログに残したり、ツール呼び出しの引数を外部へ送ったりするケースです。ポイントは、悪意がなくても起きること。たとえば「デバッグのために全部ログに出す」が、そのまま秘密情報の流出になることがあります。
次に data exfiltration。要するに情報の外部持ち出しです。宣言していないドメインに勝手にHTTP通信したり、ツールの引数からURLを組み立てたりすると危ない。LLM が入力をうまく誘導されると、知らないうちに“攻撃者のサーバーへ送信”が成立してしまいます。
unsafe execution も典型的です。eval() や exec()、subprocess、動的な require() / import() など、実行内容が入力に依存するものはかなり危険です。人間が触っているときは平気でも、モデルがその入力を作ると話が変わります。実行コードが可変というだけで、守る難易度が一段上がります。
filesystem access も見逃せません。パスの外に出る path traversal、機密ディレクトリへの書き込み、ファイル名パラメータの悪用などです。これも「ファイルを読むだけだから安全」で終わらない。ファイル名をモデルが操れると、想像以上に壊れます。
mcp-security-scan は何をしてくれるのか記事で紹介される mcp-security-scan は、MCP server のソースコードや動作をスキャンするための CLI と GitHub Action です。MIT License で、JSON レポートと 0〜100 の trust score を出します。
使い方はかなり素直です。ローカルのサーバーディレクトリを指定してスキャンするだけでも、かなりの情報が返ります。たとえば、環境変数をそのまま返しているコードや、非literal な引数で require() しているコードを見つけて、severity 付きで報告します。
この手のツールで良いなと思うのは、いきなり「危険です」とだけ言わず、どのファイルの何行目かまで出すことです。セキュリティ診断って、ふわっと怖がらせるだけだと現場で使われません。結局、直せる情報になっているかどうかが勝負です。その点、このツールはかなり実務寄りです。
記事では GitHub Action の例も載っています。push や pull_request のたびに MCP server をスキャンし、fail-on-severity: HIGH や min-score: 70 を設定すると、一定以上危険な変更をマージ前に止められます。
ここが面白いところで、セキュリティは「運用の気合い」で守るより、CI に埋め込んだほうがずっと強いです。レビュー担当者が毎回細部まで目を通すのは難しいし、人間は疲れる。だったら、最低限の危険パターンは機械に見張らせたほうがいい。かなり現実的な発想だと思います。
しかも、API key を使うと AgentGraph 側の trust profile に結果を送れる設計になっています。単なる CI ログで終わらず、スコアが履歴として残る。公開 MCP server を配る側にとっては、「ちゃんと検査している」ことを示す材料にもなります。
記事の中で印象的だったのは、スキャナが ML ベースではなく、ルールベースで作られている点です。最近は何でも AI に寄せたがる流れがありますが、ここではあえて pattern-based にしています。
理由はわりと筋が通っています。ML を使うと見つけられるものは増えるかもしれない。でも誤検知も増える。誤検知だらけだと、開発者はすぐ無視するようになります。セキュリティツールで一番まずいのは、正しい警告が雑音に埋もれることです。だから、ルールが明確で、説明できて、必要ならコメントで抑制できる設計にしているわけです。
さらに dynamic analysis もあります。Docker 上で MCP server を起動し、サンドボックス内で synthetic な tool call を投げて、外向き通信を監視する仕組みです。これは static analysis では見えないタイプの問題、たとえば実行時に展開される obfuscation や、依存関係が裏で勝手に通信するケースを拾いやすい。
ただし、遅いです。30〜90秒くらい増えることがあるし、Docker も必要。OAuth や API key が必要なサーバーだと、初期化のところでつまずくこともある。万能ではない。でも、低いところにある果実を拾うには十分役立つ、という印象です。
mcp-security-scan は、単に「危険なコードがあった／なかった」だけでなく、0〜100 の trust score を出します。HIGH は 15 点減点、MEDIUM は 5 点、LOW は 1 点。わかりやすい。こういう単純さは、実はかなり強いです。
もちろん、記事自身もこの単純さの限界を認めています。たとえば、重要な認証処理にある HIGH と、ほとんど使われない補助関数にある HIGH を同じ重みで扱うのは雑です。そこは今後、コードパスの到達可能性まで見て重み付けしたい、と書いてあります。
でも私は、この「説明できるスコア」を優先する姿勢は悪くないと思います。複雑で精度が高そうなスコアでも、なぜその点数なのか分からないと、現場では信用されません。セキュリティは、正しさだけでなく納得感も大事です。
記事がちゃんと誠実なのも好感が持てます。何でも検出できるとは言っていません。
依存関係の supply chain attack は対象外です。つまり、node_modules の中に何が入っているかまでは見ない。そこは npm audit や socket.dev のような別ツールが必要です。
ロジックレベルの脆弱性も拾えません。危険な設計を正しく実装してしまっている場合、それはコードパターンだけでは判断しづらい。さらに、dynamic analysis でも、実際の LLM が生み出すような複雑な入力までは再現しきれないことがあります。
このへんは、「スキャンツールに全部任せるのは無理」という当たり前の話なんですが、当たり前だからこそ重要です。セキュリティはツール導入で終わりません。レビュー、運用、権限設計、依存関係の管理、全部セットです。
個人的には、MCP server を“信用の前提”で配る時代はもう終わりつつある、という記事の空気感にかなり同意します。AIエージェントの世界は、便利さが先に立ちやすい。でも、便利さの裏で何が外へ出ているのか、どこまで実行されるのかを見ないと、あとで痛い目を見ると思います。
特に、process.env を雑に返す例や、動的 require() のような話は、どのプロジェクトにも潜みやすいです。大げさな攻撃だけでなく、普通の開発習慣がそのまま事故につながる。この地味さが、むしろリアルでした。
それにしても、MCP server を作る側が「セキュリティは後で」と言いやすい構造なのが一番怖い。AI ツールは“つないで動けば勝ち”になりがちですが、実際にはつないだ瞬間に権限を配っているわけです。そこを軽く見ないための仕組みとして、この手のスキャンはかなり意味があると思います。