AIエージェント通信のネットワーク行動モデルと、暗号化された通信のメタデータだけで届く範囲
実験前。通信の中身を復号せず、接続の回数・量・間隔だけでどの異常まで見分けられるかを測る
MCPやWeb APIを使うAIエージェントについて、通信の中身ではなく、接続頻度、通信量、接続時間、要求の間隔、HTTPメタデータから正常な通信行動をモデル化する。TLSで内容が暗号化された条件を前提に、ネットワークの記録だけでどの異常まで届き、どこから先は届かないかを隔離環境で測る。本ページは実験前の研究計画であり、「予想される結果」は予測であって実測値ではない。
| 方法 | 隔離した研究環境にAI Agent、Gateway、MCP Server、Test Backendを置き、正常シナリオを反復して基準線を作る。同じ環境で研究用に定義した異常シナリオを実行し、Rule、統計、Isolation Forest、時系列モデルの順に検知器を上げながら、Flow情報のみとHTTPメタデータを足した場合を同一条件で比較する。 |
|---|---|
| 結果 | 実験は未実施であり、実測結果はまだ無い。本文の「予想される結果」は検証前の仮説である。 |
| 知見 | 本研究が確定させようとしているのは、Network-only方式が届く範囲そのものよりも、届かない範囲の輪郭である。正規の接続と認証を使い、通信量も通常の範囲に収まる異常が残るなら、上位レイヤーの記録を足す根拠になる。 |
| 限界 | 実験環境と実運用環境の差、Agent実装による通信パターンの違い、TLSの内側にある意味情報を使えないこと、ネットワークの揺らぎによる誤報、Dataset規模は未確定である。 |
状態：実験前。本ページは研究の目的、仮説、方法を公開するための記録である。以下に記す「予想される結果」は検証前の予測であり、実測値として扱わない。
背景と現状の課題
AIエージェントは、人の操作より高い頻度で、自律的に外部サービスへ接続する。接続先はMCP Server、Web API、検索、ファイル、業務Backendへ広がり、一つの目的のために短時間で多数の要求が発生する。
従来のNetwork Intrusion Detection Systemは、この通信を観測できる位置にある。しかしTLSで内容が暗号化されていると、どのToolが呼ばれ、どの資源へどの操作が要求されたかという意味情報を直接読むことはできない。復号を前提とする監視は、鍵の管理と利用者の通信内容へのアクセスという別の問題を生む。
そこで本研究は、通信の中身を復号せず、接続の回数、継続時間、送受信量、要求の間隔、HTTPレベルのメタデータだけを使って、AIエージェントの正常な通信行動をモデル化する。目的は「ネットワークの記録だけでどこまで届くか」を示すことよりも、どこから先は届かないかを先に確定させることにある。届かない範囲の輪郭が決まってはじめて、Identity、MCP、Backendの記録を足す意味を量として測れる。
先行研究と本研究の位置
KitsuneはNetwork Trafficを対象に、オンラインで更新する自己符号化器の集合によって侵入検知を行う方式を示した。Anderson と McGrew は、暗号化されたマルウェア通信の分類において、復号せずに得られるメタデータだけでどの程度の識別が可能かを検討している。いずれも本研究が置く前提、すなわち「中身を読まずに外形から判断する」という条件を共有する。
メタデータが運ぶ情報は、量と頻度にとどまらない。Weiss らは、AI Assistantの応答がtoken単位で逐次送信される実装において、暗号化された通信のtoken長の系列から応答の話題を推定できることを報告した。観測側から見れば、これはネットワークメタデータが意味に近い信号を含み得ることを示す。同時に、収集する側にとっては、メタデータの保存そのものが利用者の内容に迫り得るという警告でもある。本研究はこの点を検知能力ではなく収集方針の制約として扱い、特徴量を集約値に限る。
既存研究との差は、新しい検知アルゴリズムの提案ではない。AI AgentとMCPの通信を対象データとし、Identity、Tool Call、Backendを扱う他の三つの研究と同一のTestbed、同一のシナリオ、同一のラベルで比較できる形にそろえる点にある。
研究の問いと仮説
- H1 基準線の存在：AIエージェントの通信には、反復して再現できるNetwork Behavioral Baselineが存在する。
- H2 外形の異常：接続頻度、通信量、要求間隔の変化として現れる異常は、メタデータだけで検出できる。
- H3 意味の異常：正規の接続と認証を使い、通信量も通常範囲に収まるTool-levelの異常では、Network-only方式のRecallが下がる。
- H4 HTTPメタデータの寄与：method分類、endpoint分類、status分布、応答時間を足すと、Flow情報のみより検知性能が上がる。
H3は本研究が否定されることを想定して置いた仮説である。Network-only方式で十分に検出できてしまう場合、多層化の前提そのものを見直す必要がある。
観測する特徴量
| 群 | 特徴量の例 | 想定する異常の現れ方 |
|---|---|---|
| 接続 | connection_count、duration、再接続間隔、宛先分類の数 | 探索的な接続、短時間の再接続 |
| 量 | bytes_in、bytes_out、入出力比、Session内の累積 | 大量取得、想定外の送出 |
| 時間 | request_interval、burst長、無通信区間、時間帯分布 | 自動化された反復、通常と異なる稼働 |
| HTTPメタデータ | method分類、endpoint分類、status class分布、latency | 拒否や失敗の連続、未知endpointへの要求 |
Credential、Token、要求本文、Tool引数の生値は特徴量にしない。endpointはパスそのものではなく分類として保存し、宛先はホスト単位の分類に置き換える。
実験方法
外部へ影響を与えない隔離環境に、AI Agent、GatewayまたはReverse Proxy、MCP Server、Test Backend、Telemetry Collectorを構築する。正常シナリオを反復実行して基準線を作り、同じ環境で研究用に定義した異常シナリオを実行する。異常シナリオは第三者のシステムを対象にしない。
検知器の順序
- Rule-based baseline：閾値と単純な条件で判定する。
- Statistical baseline：通常範囲からの偏りで判定する。
- Isolation Forest等の一般的な多変量異常検知。
- 必要に応じた時系列モデル。
単純な方式から順に上げる。先に複雑なモデルを採用すると、性能の差が特徴量によるものか、モデルの表現力によるものかを分けられなくなるためである。
分割と閾値
Train／Testはsession単位で分け、同一sessionのイベントが両方へ入らないようにする。閾値はTest dataを見て選ばず、TrainまたはValidationで固定する。同じシナリオの微小な変形が両方の集合へ入らないよう、scenario family単位の分割も併用する。乱数Seed、Software Version、Scenario ID、特徴量の定義、評価スクリプトを記録する。
比較対象
- A1：TCP／Flow特徴量のみ。
- A2：A1に時間特徴量を足す。
- A3：A2にHTTPメタデータを足す。
- A4：A3の特徴量に対する統計的検知器。
- A5：A3の特徴量に対する機械学習型検知器。
評価指標
- Precision、Recall、F1 Score、PR-AUC
- False Positive Rate、False Negative Rate
- Detection Latency（異常シナリオ開始から最初の有効なAlertまで）
- Telemetry収集によるCPU、Memory、保存量、追加Latency
正常が多数を占める条件を想定し、ROC-AUCではなくPR-AUCを主指標に含める。誤報はイベント単位に加えてSession単位でも示し、一つの異常に対する大量Alertで値が歪まないようにする。
予想される結果
この節は予測であり、実測結果ではない。
通信量や接続頻度が大きく変化する異常では、Network-only方式でも一定の検知性能が得られると予想する。反対に、正規の接続と認証を用い、要求数も通常範囲に収まるTool-levelの異常では、Recallが下がると予想する。HTTPメタデータの追加は、拒否や失敗が連続する異常に対して効くと考えられるが、正常な再試行との区別がつかない場合には誤報を増やす可能性がある。
この結果は、単独で結論を与えるものではなく、多層方式（Project D）と比較するための基準線として使う。
考察で検討する論点
- どの特徴量が寄与し、どの特徴量が他と重複していたか。
- 暗号化通信に対する可観測性と、メタデータ収集が持つPrivacy上の影響の釣り合い。
- 正当な再試行、珍しいが正常な通信、環境側の揺らぎを異常と誤認していないか。
- Network層のAlertが早い場合、上位レイヤーの確認とどう組み合わせるか。
限界と安全方針
- 隔離環境の結果が実運用環境へそのまま一般化できるとは限らない。
- Agent実装やClient Libraryが変われば通信パターンの分布も変わる。
- TLSの内側にある意味情報を使えないため、検出できない異常が残る。
- 既知シナリオに対する性能は、未知異常への一般化を保証しない。
- 実験は所有・管理する隔離環境だけで行い、第三者の公開システムを対象にしない。
- 実Credentialと個人情報を研究データに含めず、実測していない数値を結果として公表しない。
現在地
研究チームは2名である。現在は観測項目、正常・異常シナリオ、比較条件を固定し、収集Pipelineを組み立てている段階にある。Dataset件数、正常・異常比率、各構成のConfusion Matrix、Detection Latency分布、収集負荷は実測後に追記する。仮説を支持しなかった結果と失敗した設定も、区別して記録する。
参考文献
- Mirsky, Y., Doitshman, T., Elovici, Y., Shabtai, A. Kitsune: An Ensemble of Autoencoders for Online Network Intrusion Detection. NDSS, 2018. DOI: 10.14722/ndss.2018.23204.
- Anderson, B., McGrew, D. Machine Learning for Encrypted Malware Traffic Classification: Accounting for Noisy Labels and Non-Stationarity. ACM SIGKDD, 2017. DOI: 10.1145/3097983.3098163.
- Weiss, R., Ayzenshteyn, D., Amit, G., Mirsky, Y. What Was Your Prompt? A Remote Keylogging Attack on AI Assistants. arXiv:2403.09751, 2024.
- Liu, F. T., Ting, K. M., Zhou, Z.-H. Isolation Forest. IEEE ICDM, 2008. DOI: 10.1109/ICDM.2008.17.
- Rose, S., Borchert, O., Mitchell, S., Connelly, S. Zero Trust Architecture. NIST SP 800-207, 2020. DOI: 10.6028/NIST.SP.800-207.
- Model Context Protocol. Specification, Draft version accessed 2026-09-16. https://modelcontextprotocol.io/specification/draft
arXiv文献は査読済み出版物と同等には扱わず、研究進行中の関連研究として位置付ける。最終報告では出版状況と最新版を再確認する。