AIエージェントセキュリティ監査：MCPペネトレーションテストからLLM脆弱性評価まで

AIエージェントセキュリティ監査：MCPペネトレーションテストからLLM脆弱性評価まで

AIエージェントとMCP（Model Context Protocol）サーバーの急速な採用により、従来のセキュリティツールが想定していなかった新しい攻撃対象領域が生まれています。過去90日間、当研究チームはCrewAI、AutoGen、LlamaIndex、LangGraph、Dify、Haystackを含む10の大規模AIフレームワークに対して体系的なAIセキュリティ監査を実施し、本番LLMシステムに影響する24の異なる脆弱性パターンを明らかにしました。

本記事では、当チームの手法、主要な発見、およびLLM脆弱性評価プログラムを運用するチーム向けの実践的な推奨事項を紹介します。

新たな攻撃対象領域：AIエージェントが異なる理由

従来のWebアプリケーションセキュリティは、インジェクション、認証の不備、誤設定に焦点を当てています。AIエージェントは本質的に新しい3つのリスクカテゴリをもたらします：

1. ツールレベルの整合性障害 — エージェントが悪意のあるパラメータで内部ツールを呼び出され、人間が介在する安全策を回避される可能性
2. プロンプトからコードへのエスカレーション — エージェントの推論ループを経由してシステムコマンドとして実行されるユーザープロンプト
3. MCPプロトコルレベルのバイパス — 意図やスコープを検証せずにツール呼び出しを転送するプロキシサーバー

MCPペネトレーションテストの実施で、MCPサーバー実装の60%以上にツール実行時の基本的なアクセス制御が欠如していることが判明しました。接続された任意のクライアントが、読み取り専用呼び出しに偽装した破壊的な書き込み操作を含む、登録済みの任意のツールを呼び出せる状況です。

CCS手法：24ルール、10フレームワーク、4プラットフォーム

当チームのComponent Correctness Standard (CCS)スキャナーは、脆弱性カテゴリごとに整理された24の検出ルールを使用します：

本スキャナーは80,000件のAPIトレース（20,000件の公開検証済み + 60,000件の予備）に対して検証されており、13プロバイダーと33モデルをカバーしています。パフォーマンスベンチマークでは、ルール評価あたりP50=22µsおよびP99=99µsを示しており、ランタイムガードレールとしての展開に適しています。

実世界の発見

当チームのフレームワーク統合キャンペーン（2026年7月）では、複数の注目プロジェクトで脆弱性が確認されました：

すべての発見は、补天、HackerOne、Bugcrowd、ZDI、MSRCを含む責任ある開示チャネルを通じて提出されており、提出パイプラインの100%自動化を実現しています。

詳細分析：MCPセキュリティ監査ケーススタディ

ケース1：fdp-mcp-server — readOnlyHintバイパス

MCPプロキシ実装のAIセキュリティ監査で、fdp-mcp-serverの_call_tool関数（proxy_server.py:87）がreadOnlyHintフラグをチェックせずにすべてのツールリクエストをバックエンドに転送していることが判明しました：

async def _call_tool(req: types.CallToolRequest) -> types.ServerResult:
    result = await remote_app.call_tool(
        req.params.name, (req.params.arguments or {})
    )
    return types.ServerResult(result)

Enter fullscreen mode Exit fullscreen mode

MCPプロトコル仕様では、readOnlyHintはListToolsResultが返すToolオブジェクト上のフィールドとして定義されており、読み取り専用意図を伝えるためのものです。プロキシがこのフラグを検証しないため、クライアントが読み取り専用アクセス用に設定されていても、攻撃者はプロキシ経由で破壊的な書き込み操作を呼び出せます。

影響：readOnlyHint検証を欠くMCPプロキシサーバーは、事実上プロトコルのアクセス制御機構を無効化します。これはfdp-mcp-serverを透過的プロキシとして使用するすべてのデプロイメントに影響します。

ケース2：CodeAnalysis パス・トラバーサル (腾讯)

CodeAnalysisクライアントのtaskdirmgr.pyは、サーバーAPIレスポンスから直接取得したtask_idをos.path.join()で使用してファイルパスを構築します：

def acquire_task_dir(self, task_id):
    task_dir = os.path.join(self._task_dirs_root, f"task_{task_id}")
    os.makedirs(task_dir, exist_ok=True)
    return task_dir, task_id

Enter fullscreen mode Exit fullscreen mode

looprunner.py:204のtask_idはtask_request.get('id')から取得され、一切の検証が行われていないため、サーバーを制御またはMITMできる攻撃者は、タスクIDとして../../etc/evilを指定し、意図したワークスペース外に任意のディレクトリを作成させられます。LinuxおよびWindows環境の両方で確認済みです。

LLM脆弱性評価パイプラインの構築

10のフレームワーク統合と80KのAPIトレースにわたる経験に基づき、LLM脆弱性評価を大規模に運用するための実践的な手法を以下に示します：

フェーズ1：静的解析 (24ルール)

エージェントコードベースに対してCCSルールセットを実行します：

• コードインジェクションチェッカー：ユーザー入力を使用したexec()、eval()、subprocess.Popen()をgrepで検索
• パス・トラバーサルチェッカー：未サニタイズのパラメータを使用したos.path.join()またはPath()呼び出しを特定
• 認証情報スキャナー：APIキー、トークン、ハードコードされたシークレットを検出する正規表現
• MCPプロトコルチェッカー：readOnlyHintとツールレジストリのアクセス制御を検証

フェーズ2：動的テスト

特定された静的所見ごとに以下を実施します：

1. 脆弱性を証明する最小限のPoCで再現
2. コードの場所だけでなく、攻撃チェーン全体を文書化
3. 制御されたテスト環境で影響を検証

フェーズ3：責任ある開示

適切なチャネルを通じて所見を提出します：

• オープンソース：GitHub Advisory + メンテナへの直接連絡
• 企業SRC：中国ベンダー向けに蚂蚁SRC/腾讯SRC/字节SRC/360SRC
• バグバウンティ：対象プログラム向けにHackerOne / Bugcrowd
• ZDI/MSRC：Microsoftエコシステムの脆弱性向け

AIエージェントセキュリティの今後

AIセキュリティの状況は、ほとんどの組織が追いつけない速度で進化しています。当チームのリサーチパイプラインに基づき、注目すべき上位3分野は以下の通りです：

1. エージェント間プロトコルセキュリティ — マルチエージェントシステムの拡大に伴い、エージェント間通信チャネルが主要な攻撃対象領域となる
2. LLM依存関係のサプライチェーン監査 — モデル読み込み、LoRAアダプタのダウンロード、プラグインエコシステムはほとんど検証されていない
3. ランタイムガードレールのバイパス — 入力検証を行っていても、巧妙なプロンプトエンジニアリングで安全レイヤーを回避可能

貴チームがAIセキュリティ監査を実施中、またはデプロイメント向けにMCPペネトレーションテストを必要としている場合、当チームのCCSスキャナと手法はオープンソースツールとして利用可能です。24の検出ルールは公開スキャナと企業向け監査サービスの両方を支えています。

本研究はCorrectoverセキュリティチームにより実施されました。CCSスキャナはGitHubのgithub.com/Correctover/ccs-scannerで入手可能です。企業向けセキュリティ監査については、[email protected]までお問い合わせください。