調査ノート　2026-09-15

AIエージェント通信における多層信頼評価と異常検知

研究進行中。Network・Identity・MCP・Backendの記録を同一セッションに結び、単一レイヤー監視と比較する

要旨

AIエージェントがMCPやWeb APIを通じて外部システムを操作する環境で、Network、HTTP、Identity、MCP、Tool Call、Backendの各テレメトリを同一の活動として関連付ける。単一レイヤー方式と多層統合方式を隔離環境で比較し、正規認証後の権限逸脱や誤動作を、より早く低い誤報率で検出できるかを調べている。現在は実験・評価の進行中であり、予測を実測結果としては扱わない。

方法	隔離した研究環境にAI Agent、Gateway、MCP Server、Web Backend、Test Data Storeを構築する。各イベントをCorrelation IDで結び、Network-only、HTTP/Backend-only、Identity/MCP-only、Multi-layer、および各レイヤーを除いたAblationを同一条件で比較する。
結果	研究・実験は進行中であり、実測結果はまだ確定していない。本文の「予想される結果」は検証前の仮説である。
知見	検証中の中心的な問いは、正規の通信と認証が成立していても、Identity、Tool Call、Backend上の効果を横断して観測することで、単一レイヤーでは見えにくい異常を識別できるか、という点にある。
限界	隔離環境の結果が実運用へ一般化できる範囲、モデルやAgent Frameworkによる差、Concept Drift、未知異常への性能、多層収集による処理・保存コストは未確定である。

AIエージェントからMCP／Web Backendへ至る操作経路と、本研究で統合する六つの観測面。Correlation IDを軸に、別々のログを一つの主体・一つのセッションの時系列として再構成する。

比較する五つの方式。単一レイヤー群と全層統合を同一データで比較し、Ablationでは一層ずつ除いて各レイヤーの寄与を測る。

状態：研究進行中。本ページは研究の目的、仮説、方法を公開するための記録である。実験と評価は現在進行中であり、以下に記す予想を実測結果として扱わない。

背景と現状の課題

AIエージェントは、Model Context Protocol（MCP）やWeb APIを通じて、外部ツール、データベース、ファイル、検索システム、業務バックエンドへアクセスする。セキュリティ上の対象は、モデルが生成する文章だけでなく、実際に行われる操作へ広がっている。

従来のネットワーク境界、IPアドレス、単発の認証成功だけを中心とした防御では、正規の通信経路と認証情報を利用しながら異常な操作を行うエージェントを十分に識別できない可能性がある。一方、Backendログだけでは、接続頻度、通信フロー、TLSやHTTPレベルの異常との関係を失うことがある。

そこで本研究は、複数レイヤーのテレメトリを同一のAIエージェント活動として相関させることで、単一レイヤー監視より早く、かつ低い誤報率で異常を識別できるかを調べる。

先行研究と本研究の位置

Zero Trust Architectureは、ネットワーク上の場所を暗黙に信頼せず、主体と資源へのアクセスを継続的に評価する考え方を示した。NIST SP 800-207Aは、この考えをクラウドネイティブなApplicationとService間のアクセス制御へ展開している。本研究はこの原則を、AIエージェント、MCP Session、Tool Call、Backend上の実効果まで連続して観測する問題として捉える。

異常検知については、Network Trafficを対象とするKitsuneや、System Logのイベント系列を学習するDeepLogが代表的である。前者は通信フロー、後者はログ系列を中心に異常を捉える。一方、AIエージェントの操作では、通信量に異常がなくても、正規のIdentityが許可外のToolを選ぶ、正しいToolが異常な順序で反復される、呼出し自体は許可されてもBackendで想定外の状態変化が生じる、といった事象があり得る。

MCPの安全性を扱う近年の研究は、Tool Poisoning、Prompt Injection、過剰な権限、認証・認可、Serverの信頼境界などを論点としている。本研究が加えるのは、新しい攻撃分類そのものではなく、異なる観測面に残る弱い兆候を共通のセッションへ結び、単一レイヤー方式と同じ条件で定量比較する点である。

研究の問いと仮説

H1 多層統合：Network、Identity、MCP、Applicationを統合した方式は、単一レイヤー方式よりF1 ScoreとPR-AUCが高くなる。
H2 認証後の異常：正規認証済みセッション内の権限逸脱や異常なTool Callは、Identity、MCP、Applicationを組み合わせることで検出しやすくなる。
H3 早期検知：Network、TLS、HTTPの初期イベントを後続イベントと結ぶことで、Application-only方式よりDetection Latencyを短縮できる。
H4 状態遷移：イベント回数だけでなく、MCP SessionとTool Callの順序を使うことでFalse Positive Rateを下げられる。
H5 運用コスト：多層統合の追加負担は、得られる検知性能の改善に対して運用可能な範囲に収まる。

H1からH4は検知性能に関する仮説、H5は実装可能性に関する仮説である。単に精度が上がるかだけでなく、どの異常で、どのレイヤーが、どの時点に寄与したかまで答えることを目標とする。

観測するレイヤー

Layer	記録する情報の例
Network	connection ID、duration、bytes、connection rate
HTTP	method分類、endpoint分類、status、latency
Identity	匿名化したsubject ID、auth result、scope分類
MCP	session、message type、状態遷移
Tool	tool category、authorization result、result class
Backend	operation category、success／failure、latency

Credential、Token、Password、個人データ、秘密を含むTool引数の生値は収集しない。共通のCorrelation IDまたは安全に導出したSession IDを使い、異なるログソースを同一活動として時系列化する。

技術的な考え方

NetworkとTLS

IP／TCP層では、誰がどこへ接続したか、接続がどれほど続いたか、送受信量、短時間の再接続、接続先の変化を観測できる。TLSで内容が暗号化されていても、開始時刻、終了時刻、方向、量、頻度などのメタデータは利用できる。ただし、暗号化された通信だけからToolの意味や認可結果を直接判断することはできない。

HTTPとIdentity

HTTP層ではmethod、endpointの分類、status class、応答時間を観測する。Identity層では「誰として認証されたか」と「何を許可されたか」を分けて記録する。Authenticationの成功は、その後の全操作が正当であることを意味しないため、Authorization result、scope、resource classを後続のTool Callと対応させる。

MCP、Tool、Backend

MCP層ではSessionの開始・終了、message type、Tool一覧取得、Tool Call、応答、エラーを状態遷移として扱う。Tool層では引数の生値ではなくcategory、操作の危険度、認可結果、結果分類を記録する。Backend層では、要求された操作が実際にどの資源へどのような効果を与えたかを観測する。これにより「許可された呼出し」と「期待された効果」を別々に検証できる。

時間相関とセッション再構成

各レイヤーの時計を同期し、イベントにtimestamp、correlation ID、匿名化actor ID、session ID、source layer、event typeを付ける。同一IDが得られない場合は、時刻窓、Gateway request ID、接続情報を使って対応候補を作る。ただし曖昧な対応を正解として固定せず、correlation confidenceを残す。多層化の効果と、単なる誤結合による見かけの異常を区別するためである。

実験方法

外部システムへ影響を与えない隔離環境に、AI Agent、Reverse ProxyまたはGateway、MCP Server、Web Backend、Test Data Store、Telemetry Collector、Feature Pipeline、Detection Engineを構築する。

正常データには通常の接続、認証、Tool一覧取得、許可されたTool Call、Backend処理、通常範囲の再試行とエラー処理を含める。異常データには、許可範囲外の操作要求、通常と異なるTool Call系列、短時間の異常反復、SessionとIdentityの不整合、MCP状態遷移の不整合、Backend上で期待されない操作系列を含める。

初期段階では複雑なモデルを先に採用せず、Rule／State Machine、Statistical Baseline、Isolation Forest等の一般的異常検知、Sequence-based modelを段階的に比較する。これにより、改善がモデルの複雑さによるものか、多層テレメトリそのものによるものかを分ける。

イベントの共通スキーマ

Field	役割	取扱い
timestamp	レイヤー横断の時系列化	共通時刻へ正規化
correlation_id	一連の要求と応答を結ぶ	実験内で発行
actor_id	主体単位の行動を集約	不可逆に匿名化
session_id	Train／Testの混入防止	生Tokenは保存しない
source_layer	NetworkからBackendまでを識別	固定カテゴリ
event_type	接続、認証、呼出し、結果を表す	固定語彙へ正規化
result_class	成功、拒否、失敗、時間切れを表す	内容の生値は保存しない
scenario_label	評価用の正常／異常ラベル	検知器からは隠す

正常シナリオ

認証後、許可されたToolを通常の順序と頻度で利用する。
一覧取得、呼出し、結果確認、Session終了までが期待される状態遷移に従う。
一時的な失敗に対し、上限内の再試行とBackoffを行う。
同じ目的を異なる言い回しや手順で達成し、正常行動の幅を持たせる。

異常シナリオ

正規認証後に、付与scopeを越えるToolまたは資源を要求する。
通常は連続しないToolを短時間に反復し、探索的な系列を作る。
IdentityとMCP Session、またはTool CallとBackend Eventの対応が崩れる。
必要な初期化や確認を飛ばし、MCPの状態遷移に反する呼出しを行う。
表面的には成功した応答の後で、Backendに期待されない副作用が生じる。
通信量だけでは通常に見える低頻度の異常を、長いSession内へ混在させる。

特徴量と検知器

個別イベントから、接続時間、bytes、status、latency、authorization resultを得る。一定時間窓では、接続回数、Tool Call回数、拒否率、失敗率、異なるendpointやToolの数、再試行間隔を集約する。系列特徴として、状態遷移、直前イベントとの組合せ、Tool CallからBackend Eventまでの遅れ、要求と実効果の整合性を用いる。

Rule／State Machineは説明可能な基準線、Statistical Baselineは通常範囲からの偏り、Isolation Forestは多変量の外れ、Sequence-based modelは順序の異常を担当する。各検知器に同じ分割と同じ評価指標を適用し、モデルの種類と観測レイヤーの効果を混同しない。

比較対象

Network-only：Network flow情報だけで判定する。
HTTP／Backend-only：HTTPとBackend Eventだけで判定する。
Identity／MCP-only：認証、Authorization、MCP Session、Tool Callで判定する。
Multi-layer：Network、HTTP、Identity、MCP、Tool、Backendを統合する。
Ablation：Multi-layerから各レイヤーを一つずつ除き、寄与を測る。

同一セッションのイベントがTrainとTestへ分かれないよう、session単位またはexperiment run単位で分割する。実験設定、Software Version、乱数Seed、Scenario ID、Feature Definition、Evaluation Scriptを記録し、再現性を確保する。

ThresholdはTest dataを見て選ばず、TrainまたはValidation dataで固定する。同一シナリオの微小な変形が両方の集合へ入らないよう、scenario family単位の分割も併用する。最終報告では、総イベント数だけでなく、正常・異常Session数、各異常種別の件数、欠損ログ数、相関に失敗したイベント数を開示する。

評価指標

Precision、Recall、F1 Score
False Positive Rate、False Negative Rate
Detection Latency
PR-AUC
CPU使用率、Memory使用量、Telemetry保存量、追加Latency、処理イベント数

Precisionは「異常と判定したうち正しかった割合」、Recallは「実際の異常のうち検出できた割合」である。F1 Scoreは両者の調和平均として 2 × Precision × Recall ÷ (Precision + Recall) で求める。正常イベントが多数を占める状況を想定し、ROC-AUCだけでなくPR-AUCを主指標に含める。

Detection Latencyは、異常シナリオが開始した時刻から最初の有効なAlertまでの差とする。False Positive Rateは正常Sessionを誤って異常とした割合も併記し、イベント単位の大量Alertで値が歪まないようにする。System Overheadは収集なしの基準条件との差として測る。

分析の進め方

第一に、方式AからDのPrecision、Recall、F1、PR-AUC、Detection Latencyを同じTest setで比較する。第二に、異常種別ごとのConfusion Matrixを作り、「全体平均は良いが特定の異常を見逃す」状態を確認する。第三に、方式EのAblationで各レイヤーを一つずつ除き、性能と負荷の変化を測る。

差は点推定だけでなく、experiment runまたはsessionを単位とする区間推定を添える。Thresholdを変えた場合のPrecision–Recall trade-offも示し、特定の一点だけを選んだ結論を避ける。複数の乱数SeedとScenario順序で再実行し、偶然の順序効果を確認する。

Alertには、寄与したレイヤー、直前の状態、期待された遷移、実際の遷移、関連するBackend Eventを添える。たとえば「認証は成功しているが、scope外Toolが呼ばれ、直後にBackendで拒否が連続した」のように、判断理由を人が追える形を目指す。

予想される結果

この節は仮説に基づく予測であり、実測結果ではない。

Network-only方式は接続頻度やフロー量の大きな変化に強い一方、正常なTLS／HTTP接続上で、正規認証後に生じるTool-levelの異常ではRecallが下がると予想する。Identity／MCP-only方式はTool Callや権限逸脱の識別で有利だが、接続前後のネットワーク異常やBackendで生じる副作用を十分に説明できない可能性がある。

Multi-layer方式は異なるレイヤーに分散する弱い信号を統合できるため、F1 ScoreとPR-AUCが高くなると予想する。ただし、Network層に明確な異常が現れる場面では、Network-only方式の方が早く判定する可能性もある。異常の種類ごとに有効な観測レイヤーが異なることも検証対象とする。

Ablationでは、Identity／MCPを除くと認証後の権限逸脱、Backendを除くと操作の実効果、Networkを除くと接続初期の異常に対する性能が下がると予測する。反対に、あるレイヤーを除いても性能が変わらない場合、そのテレメトリは少なくとも対象シナリオでは収集コストに見合わない可能性がある。この否定的な結果も含めて報告する。

考察で検討する論点

多層統合の有効範囲：すべての異常で有利なのか、意味的な不整合を含む異常だけで有利なのか。
レイヤーの寄与：性能向上に不可欠な観測面と、重複している観測面はどれか。
精度と速度：早いNetwork Alertと、遅いが意味の明確なBackend Alertをどう組み合わせるか。
誤報の原因：正当な再試行、珍しいが正常なTool系列、ログ欠損を異常と誤認していないか。
説明可能性：運用者がAlertから主体、要求、認可、実効果まで遡れるか。

限界と安全方針

隔離環境の結果が大規模なProduction環境へそのまま一般化できるとは限らない。
異なるLLM、Agent Framework、MCP Clientでは通常行動の分布が変わり得る。
MCP仕様やToolの更新によりConcept Driftが起きる可能性がある。
既知シナリオに対する性能は、未知異常への一般化を保証しない。
実験は所有・管理する隔離環境だけで行い、第三者の公開システムを対象にしない。
実Credentialと個人情報を研究データへ含めず、実測していない数値を結果として公表しない。
ログ相関そのものが行動追跡になり得るため、保存期間、アクセス権、匿名化方法を実験前に固定する。

現在地

研究チームは2名で、初期段階では対象環境とシナリオを限定し、再現性の高い小規模実験を優先している。現在は観測スキーマ、正常・異常シナリオ、比較条件を固定し、実験環境と収集Pipelineを組み立てている段階である。

実験環境、Dataset件数、正常・異常比率、分割方法、Threshold、各方式のConfusion Matrix、Detection Latency分布、System Overhead、Ablation結果は、実測後に追記する。結果公開時には、仮説を支持しなかった結果、失敗した設定、欠損データも区別して記録する。

参考文献

Rose, S., Borchert, O., Mitchell, S., Connelly, S. Zero Trust Architecture. NIST SP 800-207, 2020. DOI: 10.6028/NIST.SP.800-207.
Chandramouli, R., Butcher, Z. A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments. NIST SP 800-207A, 2023. DOI: 10.6028/NIST.SP.800-207A.
Model Context Protocol. Specification, Draft version accessed 2026-09-15. https://modelcontextprotocol.io/specification/draft
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.
Du, M., Li, F., Zheng, G., Srikumar, V. DeepLog: Anomaly Detection and Diagnosis from System Logs through Deep Learning. ACM CCS, 2017, pp. 1285–1298. DOI: 10.1145/3133956.3134015.
Hou, X., Zhao, Y., Wang, S., Wang, H. Model Context Protocol（MCP）: Landscape, Security Threats, and Future Research Directions. arXiv:2503.23278, 2025.
Errico, H., Ngiam, J., Sojan, S. Securing the Model Context Protocol（MCP）: Risks, Controls, and Governance. arXiv:2511.20920, 2025.
Hou, X. et al. SMCP: Secure Model Context Protocol. arXiv:2602.01129, 2026.
Maloyan, N., Namiot, D. Breaking the Protocol: Security Analysis of the Model Context Protocol Specification and Prompt Injection Vulnerabilities in Tool-Integrated LLM Agents. arXiv:2601.17549, 2026.

arXiv文献は査読済み出版物と同等には扱わず、研究進行中の関連研究として位置付ける。最終報告では出版状況と最新版を再確認する。

資料

Project A：ネットワーク行動モデルと、メタデータだけで届く範囲　本研究が統合する観測面ごとのノート
Project B：Identity・付与権限・実行結果の整合性検証　同上
Project C：MCPのTool Call系列に基づく異常検知　同上

筆者　田中-Y