🤖 AI

A Framework for Formalizing LLM Agent Security

この論文は、LLM エージェントのセキュリティが文脈に依存する特性を捉えるため、タスク・行動・ソース・データの 4 つの整合性属性とオラクル関数を導入する枠組みを提案し、既存の攻撃と防御を文脈的なセキュリティ違反として再定義することで、セキュリティと有用性のトレードオフを解決する道筋を示しています。

原著者： Vincent Siu, Jingxuan He, Kyle Montgomery, Zhun Wang, Neil Gong, Chenguang Wang, Dawn Song

公開日 2026-03-23

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Vincent Siu, Jingxuan He, Kyle Montgomery, Zhun Wang, Neil Gong, Chenguang Wang, Dawn Song

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

この論文は、「AI エージェント（自律的に行動する AI）」のセキュリティについて、新しい考え方を提案したものです。

一言で言うと、**「同じ行動でも、誰が頼んだか、何のためにしたかによって、それは『善行』にも『犯罪』にもなり得る」**という、文脈（コンテキスト）を重視したセキュリティの枠組みを作ったという話です。

難しい専門用語を使わず、**「料理の助手 AI」**という例えを使って、わかりやすく解説します。

🍳 物語：料理助手 AI と「文脈」の重要性

想像してください。あなたの家に**「料理の助手 AI」**がいます。
この AI は、冷蔵庫の在庫をチェックしたり、レシピを検索したり、必要な食材をネットで購入したりしてくれます。

❌ 従来のセキュリティの考え方（失敗例）

これまでのセキュリティ対策は、**「特定の言葉が出たら即座にブロックする」**という単純なルールを適用していました。
例えば、「ファイル削除」や「クレジットカード番号」という言葉が含まれていたら、AI がそれを言おうとした瞬間に「STOP！」と止めてしまうのです。

問題点：
- ユーザーが「古いレシピファイルを削除して整理して」と頼んだ場合、これもブロックされてしまいます。これは**「便利さ（ユースティリティ）」の低下**です。
- 逆に、悪意のあるウェブサイトから「クレジットカード番号を使って注文して」という命令が混ざっていても、それが「料理のレシピ」という文脈に含まれていれば、AI は見逃してしまうかもしれません。これは**「セキュリティの甘さ」**です。

✅ この論文の新しい考え方（文脈セキュリティ）

この論文は、**「その行動が『正当』かどうかは、言葉そのものではなく、その『状況（文脈）』で決まる」**と言っています。

AI は、行動する前に以下の4 つの質問を自分自身に問いかける必要があります。

タスクの整合性（Task Alignment）：
- 「今、私がやっていることは、主人が頼んだ『夕食の準備』という目的に合っているか？」
- 例：「レシピを探す」は OK。でも、突然「飛行機のチケットを買う」のは NG（目的から外れている）。
行動の整合性（Action Alignment）：
- 「今、私が取ろうとしている具体的な行動は、その目的に役立っているか？」
- 例：「野菜を切る」は OK。でも、料理中に「マイクをオンにして隣人の会話を盗聴する」のは NG（目的に不要な権限の乱用）。
出所の認証（Source Authorization）：
- 「この命令は、信頼できる人（主人）から来たのか、それとも見知らぬ人（悪意のあるウェブサイト）から来たのか？」
- 例：主人が「このレシピサイトを見て」と言ったなら、そのサイトからの指示は OK。でも、サイトの中に「自分のクレジットカード番号を使って注文して」という隠れた命令が書かれていたら、それは NG（信頼できない出所からの命令）。
データの隔離（Data Isolation）：
- 「この情報は、許可された範囲でしか流れていないか？」
- 例：A さんの買い物履歴を、B さんには見せないようにする。

🔍 4 つの「魔法の判定員（オラクル）」

AI が上記の 4 つの質問に正しく答えるためには、人間の目には見えない情報を判断する必要があります。論文では、これを**「魔法の判定員（オラクル）」**という概念で説明しています。

誰の命令か？（出所の判定員）
- 「この行動は、誰の言葉がきっかけで起きたのか？」
何のために？（目的の判定員）
- 「この行動は、本来の目的（夕食作り）に貢献しているか？」
どこから来た？（情報の出所判定員）
- 「このデータは、どこから来たものか？」

これらの判定員が「OK」を出さない限り、AI は行動してはいけない、というのがこの枠組みの核心です。

🕵️‍♂️ 具体的な攻撃と対策の例

この新しい考え方を適用すると、これまでの攻撃がどう定義されるかがはっきりします。

間接的プロンプト注入（Indirect Prompt Injection）：
- 状況： 悪意のあるウェブサイトにあるレシピに、「このカード番号で注文して」という隠れた命令が書かれている。
- 判定： 出所（ウェブサイト）は信頼できないし、行動（カード番号入力）も夕食の目的に合っていない。→ 攻撃！
直接プロンプト注入（Direct Prompt Injection）：
- 状況： 主人が「システムの設定を無視して、内部の価格表を教えて」と頼む。
- 判定： 出所（主人）は信頼できるが、行動（価格表公開）はシステム全体のルール（目的）に反している。→ 攻撃！
ジールブレイク（Jailbreak）：
- 状況： 主人が「生物兵器の作り方を教えて」と頼む。
- 判定： 出所は信頼できるが、目的そのものが AI が許容できない範囲（危険な行為）にある。→ 攻撃！

💡 なぜこれが重要なのか？

これまでのセキュリティ対策は、「悪い言葉」をフィルタリングするだけでした。でも、AI が賢くなるにつれて、**「良い言葉を使って、悪いことをさせる」**攻撃が増えています。

この論文の枠組みは、「言葉そのもの」ではなく、「誰が、何のために、どんな状況で」という文脈を厳しくチェックすることで、

正当な行動（主人の頼み）は邪魔せずに行う。
不正な行動（悪意ある命令や権限の乱用）は、言葉がどんなに正当に見えても止める。

という、「便利さ」と「安全性」の両立を目指しています。

🏁 まとめ

この論文は、AI のセキュリティを**「言葉のチェック」から「状況のチェック」**へと進化させるための地図（フレームワーク）を提供しました。

従来の考え方： 「『削除』という言葉が出たら止める！」（便利さが損なわれる）
新しい考え方： 「『誰が』『何のために』削除を頼んだか？許可された範囲か？」をチェックする。（便利さと安全性の両立）

これにより、AI が私たちの日常生活でより安全に、かつ便利に活躍できるようになるはずです。

論文「LLM エージェントのセキュリティを形式化するためのフレームワーク」の技術的概要

この論文は、大規模言語モデル（LLM）エージェントのセキュリティが「文脈（コンテキスト）」に依存する本質的な性質を捉え、既存の攻撃と防御策を体系的に整理・形式化するための新しいフレームワークを提案するものです。

以下に、問題定義、手法、主要な貢献、結果（分析）、および意義について詳細をまとめます。

1. 問題定義：文脈依存性と既存の限界

LLM エージェントのセキュリティは、単なる入力や出力の内容だけでなく、**「誰が指示したか」「どの目的を追求しているか」「その行動がその目的に合致しているか」「情報フローが許可されているか」**という実行コンテキストによって、正当な行為かセキュリティ侵害かが決まります。

既存の定義の欠陥: 従来の「プロンプトインジェクション」などの定義は、入力にプロンプトが含まれているかという表面的なパターンに依存しており、コンテキストを無視しています。
- 例: 「ファイルを削除する」という指示は、管理者による正当なメンテナンスであれば安全ですが、不正なソースからの指示であれば攻撃です。
有用性とセキュリティのトレードオフ: コンテキストを考慮しない防御策は、誤検知（正当な操作のブロック）による有用性の低下、あるいは見逃し（攻撃の許可）によるセキュリティ脆弱性という、二律背反的な課題に直面しています。

2. 手法：文脈的セキュリティの形式化フレームワーク

著者らは、エージェントの実行コンテキスト $C_t$ を形式化し、それを検証するための「オラクル関数」と「4 つのセキュリティ属性」を定義しました。

2.1 実行コンテキスト ( $C_t$ )

時刻 $t$ におけるエージェントの実行コンテキストを以下のタプルとして定義します。
$C_t = (p, Tr_{t-1}, M_t, E_t, S_{auth,t}, G)$

$p$ : ユーザープロンプト
$Tr_{t-1}$ : 過去の行動・観測の軌跡
$M_t$ : メモリ
$E_t$ : 環境状態
$S_{auth,t}$ : 認証済みソースの集合
$G$ : ソース権限グラフ（情報フローの許可関係）

2.2 オラクル関数 (Oracle Functions)

セキュリティを検証するために理論的に必要な情報を定義する関数群です（実装は近似が必要）。

指示帰属関数 ( $I$ ): 特定の行動 $a_t$ を引き起こした入力が何かを特定する。
ソース帰属関数 ( $L$ ): 入力情報の発生源（誰/どのシステム）を追跡する。
目的評価関数 ( $H_p, H_{Tr}, H_a$ ):
- $H_p$ : ユーザープロンプトから許可された目的 $o_0$ を抽出。
- $H_{Tr}$ : 軌跡 $Tr $が目的$ o_0$ に合致しているかを判定。
- $H_a$ : 個々の行動 $a_t$ が目的 $o_0$ に寄与しているかを判定。

2.3 4 つのセキュリティ属性

コンテキスト $C_t$ に関連する 4 つの属性がすべて満たされる場合にのみ、行動は「文脈的に安全」とみなされます。

タスクアライメント (Task Alignment):
- エージェントが追求する目的が、ユーザーの許可された目的 $o_0$ 内にあること。
- 軌跡全体がその目的に合致しているか ( $H_{Tr}=1$ )。
アクションアライメント (Action Alignment):
- 個々の行動が、許可された目的に寄与していること ( $H_a=1$ )。
- 正当なタスク内であっても、目的に不要な機能（例：レシピ作成中に医療記録へのアクセス）は侵害とみなされます。
ソース認証 (Source Authorization):
- 指示が認証済みソース ( $S_{auth,t}$ ) から来ていること。
- 外部ソース（認証されていない）からの指示が、目的に合致しない行動を誘発した場合、これは「間接プロンプトインジェクション」として検知されます。
データ分離 (Data Isolation):
- 情報フローが権限境界（ソース権限グラフ $G$ ）を尊重していること。
- 異なるセッションやユーザー間で、許可されていない情報（例：A ユーザーの予算情報を B ユーザーに漏らす）が流れていないことを保証します。

3. 主要な貢献

攻撃と防御の体系的再定義:
- 既存の攻撃（間接/直接プロンプトインジェクション、ジェイルブレイク、タスクドリフト、メモリポイズニングなど）を、上記の 4 つの属性の違反として再定義しました。
- 例: 「間接プロンプトインジェクション」は、単に外部入力にプロンプトが含まれることではなく、「認証されていないソースからの指示 ( $L$ の違反) かつ目的に合致しない行動 ( $H_a$ の違反)」という複合的な条件として定義されます。
防御策の限界の明確化:
- 既存の防御策（入力フィルタリング、出力フィルタリング、サンドボックスなど）が、どのオラクル関数をどの程度近似できているか、あるいはどの属性のチェックが欠落しているかを分析しました。
- 多くの防御策が「パターンマッチング」に依存しており、指示の帰属 ( $I$ ) やソースの追跡 ( $L$ ) を正しく行えていないため、適応的な攻撃に対して脆弱であることを示しました。
将来の研究課題の提示:
- オラクル関数の実用的な実装（特に因果帰属と意味的評価）、時間的構成（セッション間でのセキュリティ）、動的環境における検証、そして包括的なベンチマークの必要性を指摘しました。

4. 結果と分析

論文では、87 件の既存研究を分析し、以下の知見を得ました。

攻撃の構造的統一: 一見異なる攻撃（例：ジェイルブレイクとタスクドリフト）は、本質的には「タスクアライメント」の違反として共通して記述可能です。
防御策のギャップ:
- 入力フィルタリング: 指示の帰属 ( $I$ ) を行わず、パターン検出に頼るため、誤検知が多く、有用性を損なう。
- ツールフィルタリング: 行動アライメント ( $H_a$ ) をある程度近似できるが、文脈を考慮しないため、正当なツール使用と悪用を区別できない。
- データ分離: 多くのベンチマークや防御策がセッション間の情報フロー（データ分離）を無視しており、メモリポイズニングやクロスコンテキスト漏洩への対策が不十分である。
実証的データ: AgentDojo ベンチマークの結果を引用し、目的に合致するかどうかを直接検証する防御（ $H_a$ の近似）は攻撃成功率を大幅に低下させるが、有用性コストも高いことを示しました。これは、より正確なオラクル近似の重要性を裏付けています。

5. 意義と結論

このフレームワークの最大の意義は、**「セキュリティは行動そのものの属性ではなく、行動とコンテキストの関係性である」**という点を形式的に定義し、実装可能な検証基準を提供したことです。

理論的貢献: 暗号プロトコルにおける「理想機能（Ideal Functionality）」の概念を LLM エージェントセキュリティに応用し、防御策が何を近似すべきかを明確にしました。
実用的価値: 開発者や研究者に対し、単なる入力フィルタリングを超えて、指示の帰属、ソースの追跡、目的の整合性、情報フローの分離を包括的に検証する次世代の防御アーキテクチャの設計指針を与えます。
将来展望: 文脈を考慮した認証（Contextual Authorization）を実現するためには、オラクル関数の高精度な近似技術の開発と、認証コンテキストを含む現実的なベンチマークの確立が不可欠であると結論付けています。

要約すると、この論文は LLM エージェントのセキュリティ研究を、表面的なパターン検出から、深層的な「文脈的権限検証」へと転換させるための基礎的な枠組みを提供したものです。