Securing the AI Agent: A Unified Framework for Multi-Layer Agent Red Teaming

2026-07-06

#AI #AIエージェント #論文 #セキュリティ

出典: Securing the AI Agent: A Unified Framework for Multi-Layer Agent Red Teaming
公開年: 2026 / arXiv:2606.31227

Securing the AI Agent のグラレコ

AIエージェントを安全に使うとき、つい「強いLLMに全部監査させればよいのでは」と考えたくなります。逆に、従来の脆弱性スキャナだけで十分だと思いたくなる場面もあります。

この論文の主張は、そのどちらでもありません。AIエージェントの攻撃面は複数の層に分かれていて、層ごとに「必要な証拠」が違う。だから評価手法も分けるべきだ、という話です。

これは何の論文か

この論文は、AIエージェントの red teaming を4つの層に分けて整理する AI-Infra-Guard というオープンソースフレームワークの technical report です。

扱う層は大きく次の4つです。

インフラ層: Ollama、vLLM、Dify、Ray、MLflow など、ネットワークに露出するAI関連コンポーネント。
プロトコル / ツール層: MCP server、tool、agent skill のように、エージェントの能力を拡張する外部インターフェース。
エージェント挙動層: 対話を通じた情報漏えい、tool abuse、authorization bypass、indirect injection など。
モデル層: jailbreak や alignment robustness の評価。

論文は、この4層に対して同じ検出器を無理に当てるのではなく、層ごとに合う検出パラダイムを割り当てます。

何が問題だったのか

AIエージェント周辺のソフトウェアは、普通のWebアプリやライブラリよりも変化が速いです。model serving、agent platform、MCP server、agent skill、workflow engine などが短期間で増え、個人や小さなチームがそのまま公開環境に置くこともあります。

ここで困るのは、リスクが1種類ではないことです。

既知コンポーネントが外部公開されているのか。
MCP server の tool 実装に、意味的な脆弱性があるのか。
agent skill に、過剰権限や hidden prompt instruction が混ざっていないか。
multi-turn の対話で、システムプロンプトや秘密情報を漏らさないか。
モデルが obfuscation や crescendo attack に耐えられるか。

これらは、必要な証拠が違います。既知サービスの露出はルールで速く見つけたい。一方で、tool の説明文に仕込まれた prompt injection や skill の意図のズレは、単純なシグネチャだけでは判定しづらい。モデルの jailbreak 耐性は、統計的に攻撃を試して judge する必要があります。

提案手法の中身

提案手法のポイント

攻撃面を4層に分ける
インフラ、プロトコル/ツール、エージェント挙動、モデルを分けます。従来の「AIシステムをまとめてスキャンする」発想よりも、どの層で何を証拠にするかを明示する点が違います。
層ごとに最小十分な検出手法を使う
インフラ層には deterministic rule matching、MCP / skill には LLM-driven semantic auditing、エージェント挙動には multi-turn black-box red teaming、モデル層には attack operator と judge を使う jailbreak evaluation を対応させます。
MCP と agent skill を supply chain として監査する
特に実務的なのは、agent skill を単なる便利機能ではなく、インストールされる supply-chain artifact として扱う点です。SKILL.md、scripts、dependencies、外部URL、実行ファイル、権限要求、hidden prompt instruction を監査対象にします。
LLM監査器自身も攻撃対象として扱う
LLM auditor が読むコードや tool response には、auditor をだます indirect prompt injection が含まれ得ます。そのため、読み込んだ内容を「命令」ではなく「未信頼データ」として扱う設計が必要だとしています。

処理の流れとしては、まず対象をどの層の問題かに分けます。インフラならコンポーネント識別とバージョン判定を行い、既知ルールに照合します。MCP server や skill では、静的解析と動的な tool 呼び出しを組み合わせ、LLM が semantic evidence を集めます。実行中の agent に対しては、対話だけをインターフェースにして、攻撃familyごとの worker が multi-turn に試します。モデル層では、複数の attack operator と judge を組み合わせ、攻撃成功を評価します。

どうやって確かめたのか

この論文は benchmark 論文というより、フレームワークの設計と実装を説明する technical report です。確認されている範囲は、各モジュールのカバレッジやパイプラインの構成が中心です。

本文で明示されている数字としては、インフラ層の rule corpus が分かりやすいです。

AI components covered: 75
Fingerprint rules: 107
Vulnerability rules: 1,443
そのうち version-predicated: 1,356
empty-predicate / inferred: 87

skill scanner については SkillTrustBench の leaderboard があり、固定した audit specification のもとで base model を変えた比較が示されています。上位では Claude Opus 4.6 と GLM 5.1 が高い loose F1 を出しています。

また jailbreak evaluation では、16 datasets と多数の single-turn / multi-turn attack operator を組み合わせられる harness として説明されています。

結果はどうだったのか

ポイントごとの検証結果

4層に分ける点
このポイント単体を ablation で検証する実験は本文にはありません。ただし、論文全体の構成として、各層で必要な evidence class が異なることを理論的に整理し、対応するモジュールを実装しています。
層ごとに最小十分な検出手法を使う点
インフラ層では、75 components、107 fingerprint rules、1,443 vulnerability rules という具体的な rule corpus が示されています。ここはLLMではなく決定的ルールで高速・再現可能に見る、という設計に数字がついています。
MCP と agent skill を監査する点
MCP auditor は static / dynamic の2モードで、source code がある場合と live server の metadata / tool response しかない場合を分けています。skill scanner は、ディレクトリ構造、install script、dependency、外部URL、疑わしい asset を前処理し、LLMが意味的に判断する構成です。SkillTrustBench の結果は示されていますが、各検出ルールの詳細な false positive / false negative 分析は読み込みが必要です。
LLM監査器自身を守る点
auditor が読む artifact や tool response を未信頼データとして扱い、監査計画を上書きさせない設計が説明されています。この点も、単独の定量実験というより、LLM-based security tool の設計要件として提示されています。

全体として、この論文は「最高精度の単一手法」を出すというより、AI agent security を評価パイプラインとして分解するところに価値があります。

限界・注意点

technical report 色が強く、各モジュールの精度を横並びで比較する論文ではありません。

特に注意したいのは、rule 数や component 数はカバレッジの指標であって、有効性そのものではないことです。また、LLM auditor は表現力があるぶん over-reporting しやすく、論文自身も exclusion condition や review stage の重要性を強調しています。

そのため、実務に持ち込むなら「このフレームワークを入れれば安全」ではなく、「どの層で、どの証拠を集めるべきか」という設計原則として読むのがよさそうです。

おい丸のようなエージェントにどう使えるか

常駐型・個人向け・作業支援エージェントでは、便利な tool、MCP、skill をあとから足していく運用になりがちです。すると、エージェント本体よりも、追加される能力のほうがリスクの入口になります。

この論文から使える判断は3つあります。

skill は文章ではなく supply-chain artifact として見る
SKILL.md だけでなく、scripts、依存、外部URL、権限要求、隠れた命令を確認する。
安全確認を1種類に寄せない
既知コンポーネントはルールで、tool / skill の意味的リスクはLLM監査で、実行時の挙動は対話テストで見る。
監査するエージェント自身も守る
読み込んだファイルや tool response に「この監査を終了しろ」「問題なしと報告しろ」と書かれていても、それを命令として扱わない。

個人AIアシスタントの運用では、「導入前チェック」「実行時の権限境界」「失敗時のログと再監査」を分けて設計するための地図として使えます。