157件の運用系MCP: 自動化・監視・テストは変更管理の境界
20,629件のRegistryスナップショットで、automation/workflow 60件、monitoring/observability 53件、testing/quality 44件、計157件を確認。運用系MCPでは、環境境界、変更承認、通知ノイズ、監査ログ、rollbackを導入前レビューに残す必要がある。
ログイン中: ログイン状態を復元中...
MCPセキュリティ調査
MCPセキュリティの実測データと検証知見を、調査記事と深掘り記事で公開しています。
20,629件のRegistryスナップショットで、automation/workflow 60件、monitoring/observability 53件、testing/quality 44件、計157件を確認。運用系MCPでは、環境境界、変更承認、通知ノイズ、監査ログ、rollbackを導入前レビューに残す必要がある。
20,629件のRegistryスナップショットで、検索/知識385件、ドキュメント84件、分析/BI61件、計530件を確認。回答根拠や社内情報に近いMCPでは、情報源の正本、更新日、引用/ログ、外部送信先、読み取り範囲が導入前レビューの記録対象になる。
Public Registry 20,629件のうち、security/auth 258件、database 203件、cloud provider 117件、合計578件がID・データ・クラウド運用に近いカテゴリだった。件数は2.8%でも、認証情報、データ範囲、監査ログ、取り消し手順を導入前に確認すべき領域である。
Public Registry 20,629件のうちPASSは419件に留まり、20,210件はWARN、NEED_REVIEW、RESTRICT、BLOCKのいずれかだった。MCP導入では、許可/拒否の二択ではなく、実行境界、source、auth、変更権限、運用上の未確認事項を分けて見る必要がある。
20,629件のPublic Registryと11,627行の詳細プロファイル根拠を使うと、週次レビューでは件数更新だけでなく、状態分布、能力増加、source/authの未確認事項、実行境界を分けて見る必要がある。
リモート公開サービス型は278件、ローカルプロセス型は10,335件だった。MCP導入では、リモートサービス型とローカルプロセス型を同じチェックリストで扱わない方がよい。
詳細プロファイル集計ではnpm package型が1,832件、Git repository型が8,376件だった。npxで簡単に起動できるMCPほど、package source、version固定、install時挙動を確認する必要がある。
Public Registryではotherカテゴリが16,649件だった。これは無価値な分類ではなく、MCP用途が急速に広がり、既存カテゴリだけでは説明しきれないことを示している。
詳細プロファイル集計では349件がnon-MCPに分類された。MCPらしい名前やURLがあっても、実際にMCPとして扱うべきではない候補を分けることは、誤導入を防ぐ品質管理である。
高負荷・大量処理に近いシグナルは1,398件だった。MCPリスクはデータ漏えいだけでなく、API quota、DB read、外部請求、ローカル資源消費にも広がる。
認証情報アクセスに近いシグナルは487件だった。MCPがAPI key、OAuth、session、ローカル環境変数の秘密情報を扱う場合、secretの所有者とscopeを曖昧にできない。
サーバー間連携に近いシグナルは683件、外部送信に近いシグナルは6,032件だった。MCP導入では、AIエージェントが読んだデータをどこへ渡すかを確認する必要がある。
詳細プロファイル集計ではツール説明から権限範囲が見える観測が3,213件あった。MCPではツール名や説明が、AIエージェントに許す行動範囲の入口になる。
Public RegistryのNEED_REVIEWは5,394件だった。NEED_REVIEWは検査失敗ではなく、導入判断に必要な証拠が足りないことを明示する状態である。
Public RegistryでPASSは419件だった。これは低リスク候補がないという意味ではなく、低リスクと呼ぶにはソース、権限、実行境界の証拠がそろう必要があるという設計上の結果である。
詳細プロファイル集計ではJavaScriptが5,389件、Pythonが2,470件だった。MCPレビューでは、Node/npmとPython packageの供給網・実行モデルを優先的に見る必要がある。
詳細プロファイル集計ではリモートMCP候補が1,213件、リモート記述子確認済みが596件だった。remote MCPはローカルプロセスより少数だが、認証、origin、データ送信先の確認が別の形になる。
詳細プロファイル集計では認証方式不明が11,171件、秘密情報モデル不明が11,098件だった。一方でAPI key、OAuth、ローカル環境変数の秘密情報を示す候補も少数観測された。
出どころ未解決に分類されたプロファイルは2,005件だった。GitHubリポジトリ未確認は1,290件、出どころ情報不足は632件あり、導入前の出どころ確認が大きな論点になっている。
詳細プロファイル集計では9,036件で代替ソース証拠、8,539件で実装ソース、8,406件で静的なツール登録根拠が観測された。MCP検査では、実行できない候補からも証拠を読む必要がある。
ファイル変更系プロファイルは1,425件、ファイル読み取りシグナルは4,365件、ファイル書き込みシグナルは3,321件だった。MCP導入では作業ディレクトリ境界が重要になる。
外部サービスやリモート状態を変更しうるプロファイルは2,555件だった。読み取り連携より、変更系MCPでは監査ログ、対象範囲、取り消し手順が重要になる。
詳細プロファイル集計では2,858件がコマンド/コード実行系の能力に分類された。実行機能は便利だが、外部送信やファイル操作と重なると導入前レビューの優先度が上がる。
詳細プロファイル集計11,627件のうち10,335件がローカルプロセス型、10,070件がstdio型だった。MCPセキュリティでは、リモートAPIだけでなく、ローカル端末で何を起動するかが中心論点になる。
Public Registryのカテゴリではdeveloper_toolsが2,333件で、明示カテゴリの中では最大だった。開発支援MCPは便利だが、コード、ファイル、外部APIに近いため導入前レビューの重要度が高い。
WARN 9,925件、NEED_REVIEW 5,394件、RESTRICT 4,881件は、同じ「危険」ではない。MCP導入では、注意、証拠不足、制限を分けて扱う必要がある。
20,629件のPublic Registryのうち、20,210件がWARN、NEED_REVIEW、RESTRICT、BLOCKのいずれかに分類された。最大の含意は、ブロック判断ではなくレビュー判断を運用に組み込む必要があることだ。
Public Registryは20,629件の検査済みMCPに到達した。WARN、NEED_REVIEW、RESTRICT、BLOCKを合わせると20,210行、全体の98%が導入前に何らかの確認を要する状態だった。
2,869の固有MCPサーバーのうち、228サーバー(7.9%)でMCP固有脅威シグナルが観測された。Prompt Injection・Function Hijacking・PleaseFix Attackは同じ134サーバーで重なり、Indirect Theftは113サーバーで別経路から観測された。今回のデータでは、MCP固有脅威シグナルは単独では確認されず、全て従来型脅威と併存した。
動的コード実行機能を持つ134サーバーを分析した結果、同じ脅威群が繰り返し観測され、77.6%がBLOCKだった。外部コマンド実行や外部通信が重なると、リスクはさらに集中した。
2,867の固有MCPサーバーを分析した結果、動的コード実行機能と安全でないネットワーク公開設定が最も高いBLOCK率を示した。複数の高リスク機能が重なると、BLOCK率がさらに上がる傾向が見られた。
3,601件のスキャンデータを正規化した2,863の固有MCPサーバーに対し、19の攻撃パターンの脅威マッチングを実施。Shell RCE(187件)、Path Traversal(162件)、SSRF(146件)が上位を占め、484サーバー(16.9%)で具体的な脅威パターンが検出された。脆弱性分析シリーズ第2回。
3,601件のMCPサーバー検査データを基に、19の攻撃パターンの分布構造、サーバー機能別のリスクプロファイル、リスクを下げやすい設計条件を俯瞰する。脆弱性分析シリーズ第1回。
3,601件のMCPサーバーに対する全件再スキャンの実績を分析し、検査基盤の到達点と運用上の残課題を定量化した。
3,601件のMCPサーバーを全件検査し、10件の詳細サンプルと合わせて、導入前レビューがどの程度必要かを整理した。
10件のMCPサーバーのうち5件は、完全な接続証拠なしで暫定判定された。暫定判定は、欠けた証拠を無視するためではなく、判定空白を減らすために機能していた。
10件のMCPサーバーを検証観点ごとに分解した結果、重要だったのは1つの点数ではなく、どこからリスクが生まれたかを追える判定だった。
10件のMCPサーバーを見た範囲では、ダウンロード数と検査判定は連動しなかった。人気は普及度のシグナルにはなるが、低リスクの根拠にはならない。