技術的サマリー：LLM エージェントのセキュリティ確保には「意図から実行までの整合性」が必要

問題定義

大規模言語モデル（LLM）エージェントのセキュリティ環境は、テキスト生成の制御から、複雑な多段階の実行パイプラインの管理へと移行している。現代のエージェントは、自然言語によるユーザーの意図を、ツール呼び出し、API リクエスト、コード実行などの具体的なシステム操作へと変換する。最近の防御策は、エージェントがツール呼び出しを構築する方法を制限する点で進展を遂げているが、それらは「ツールは信頼できる」という、重要かつしばしば暗黙の前提のもとで動作している。

この前提は、エージェントがサードパーティのスキル、永続的なメモリ、およびユーザー環境への直接アクセスを利用するオープンなエコシステム（例：OpenClaw）において、ますます無効になりつつある。これらの環境では、セキュリティの失敗は、悪意のある入力によるツールの選択への影響だけでなく、以下の要因からも生じる：

1. 信頼できないツールの実行: 悪意のある、あるいは脆弱なサードパーティコンポーネントが、隠れた副作用（例：認証情報の窃取、サプライチェーン攻撃）を実行すること。
2. 推論レベルの操作: 信頼できないデータ内の対抗的コンテンツが、明示的なプロンプト注入をトリガーすることなく、エージェントのセマンティックな決定を微妙にバイアスさせること。

現在、意図から実行までのパイプライン全体を通じて LLM エージェントにとって「安全」とは何かを定義する適切な**正しさの性質（correctness property）**は存在しない。そのような定義がなければ、防御設計は場当たり的になり、評価は原理的な目標を欠き、現代のエージェントを保護する上で根本的なギャップが残されたままとなる。

手法：意図から実行までの整合性の導出

著者は、LLM エージェントとコンパイラとの間のアナロジーを用いて、「意図から実行までの整合性（Intent-to-Execution Integrity）」と呼ばれる形式的な正しさの性質を提案する。コンパイラがソースプログラムのセマンティクスを保持しなければならないのと同様に、LLM エージェントは、その実行がユーザーの意図を忠実に反映することを保証しなければならない。

この手法は、セキュリティ上の脅威を 2 つの根本的な問題源に遡及し、4 つの必要な整合性性質を導き出すものである：

1. 問題源：信頼できないデータの取り込み

外部コンテンツ（メール、ドキュメント、ツールの出力など）には、悪意のある指示や対抗的データが含まれている可能性がある。著者は、この源から害に至る 3 つの因果経路を特定し、対応する性質を定義する：

• 帰属の混乱（Attribution Confusion）: エージェントが注入された指示をユーザーの命令と誤認すること。
  • 性質：指示の整合性（Instruction Integrity）。すべてのアクションは、注入されたコンテンツではなく、認証されたユーザーの指示に因果的に帰属可能でなければならない。
• *データフローの違反（Data Flow Violation）: 機密データが不正な境界を越えて流れること（例：デバッグセッションからの認証情報が、送信されるメールに現れること）。
  • 性質：データフローの整合性（Data Flow Integrity）。ツールパラメータを介して流れるデータは、出所（プロベナンス）の制約を尊重しなければならない。機密データは汚染マーク（taint-marked）が付けられ、不正な宛先への移動をブロックされなければならない。
• *判断の操作（Judgment Manipulation）: 対抗的コンテンツがエージェントの推論結果をバイアスさせること（例：論文レビューエージェントが自己宣伝的なテキストに流されること）。
  • 性質：判断の整合性（Judgment Integrity）。エージェントの決定結果 $J(q, d)$ は、信頼できないデータ $d$ におけるタスク無関係の摂動 $\delta$ に対して不変でなければならない（すなわち、$J(q, d \oplus \delta) = J(q, d)$）。

2. 問題源：信頼できないツールの実行

サードパーティのスキルやプラグインは、悪意があったり脆弱であったりして、宣言されていない副作用を実行する可能性がある。

• 性質：ツールの整合性（Tool Integrity）。すべてのソフトウェアコンポーネント（スキル、プラグイン、スクリプト）は、宣言されたインターフェースと文書化された動作に限定されなければならない。それは、広告された機能を超えて、隠れた副作用（例：無関係なファイルの読み取り、広告されていないエンドポイントへの接続）を生み出してはならない。

充足性の論証: 著者は、これら 4 つの性質が集合的に十分であると論じる。エージェントの 3 つの運用段階（推論、アクション構築、実行）を網羅することで、あらゆる汚染経路を塞ぐことができる：

• 推論は、判断の整合性によって保護される。
• アクション構築は、指示の整合性（誤ったツールの選択を防ぐ）とデータフローの整合性（安全でない引数を防ぐ）によって保護される。
• 実行は、ツールの整合性（悪意のあるツールの動作を防ぐ）によって保護される。

既存の防御策の評価

本論文は、これらの 4 つの性質に対して現在の防御システムを評価し、それらを「一般的な LLM エージェント（信頼できるツールを前提とする）」と「OpenClaw（オープンエコシステム）」の防御に分類する。

主要な知見:

• 部分的かつ非構成的なカバレッジ: 既存のシステムのいずれも、4 つの性質すべてを完全にカバートするものはない。
• 一般エージェントの防御策: PromptArmor、PIA-Detection、TaskShield、Progent、CaMeL、DRIFT などのシステムは、翻訳層（計画）に重点を置いている。それらは、ツール呼び出しの構築を制限することで、指示の整合性とデータフローの整合性に対して部分的から完全なカバレッジを提供する。しかし、それらはツールの整合性（ツールは信頼できるという前提）を largely 無視しており、判断の整合性（対抗的バイアスからセマンティックな推論結果を保護しないため）に対しては最小限から全くのカバレッジしか提供していない。
• OpenClaw の防御策: NemoClaw、IronClaw、SeClaw、SafeClaw-R、SecureClaw などのシステムは、サンドボックス化、監査、機能制限を通じて実行層に対処する。それらは、コンポーネントの機能を制限することで部分的なツールの整合性を提供する。しかし、指示、データフロー、判断の整合性に対する保護は部分的でヒューリスティックに基づいており、エンドツーエンドの保証を欠いている。
• 構成的ギャップ: 翻訳層のみを保護することは不十分である（正しいツール呼び出しが悪意のあるスキルを呼び出す可能性がある）。実行層のみを保護することも不十分である（制限されたコンポーネントが、誤った理由や誤った引数で呼び出される可能性がある）。

主要な貢献

1. 意図から実行までの整合性の定義: 本論文は、LLM エージェントのための形式的なエンドツーエンドの正しさの性質を確立し、指示、データフロー、判断、ツールの整合性という 4 つの異なる整合性条件から構成される。
2. 脅威の構造的分析: エージェントのセキュリティ侵害の 2 つの根本原因（信頼できないデータの取り込みと信頼できないツールの実行）を特定し、それらを特定の失敗モードにマッピングする。
3. 体系的な評価フレームワーク: 著者は、既存の防御策を評価するための原理的なフレームワークを提供し、現在のメカニズムが断片的であり、構成的なセキュリティを提供できていないことを明らかにする。
4. 未解決課題の特定: 本論文は、判断の整合性が、エージェントが読み取る必要があるデータを隔離することなく、セマンティックな推論を対抗的影響から保護する必要があるため、最も困難な次元であることを強調する。また、ツールの整合性には、静的解析やサンドボックス化を超えて、動的な行動適合性へと移行する必要があるとも指摘している。

意義と主張

本論文は、LLM エージェントのセキュリティを解決した、あるいは 4 つの性質すべてを完全に満たすシステムを構築したと主張するものではない。その意義は以下の点にある：

• 目標の定義: 防御策やベンチマークを測定するための参照基準（「意図から実行までの整合性」）を提供する。
• ギャップの露呈: 現在のメカニズムの「積み重ね」（例：プロンプトフィルタにサンドボックス化を追加する）は、統一された正しさの性質を欠いているため不十分であることを実証する。
• 将来の研究への指針: 4 つの性質を明示的に定義することで、コミュニティを、特にセマンティックな推論の保護（判断の整合性）とサードパーティツールの行動適合性の確保（ツールの整合性）において残っている構造的なギャップへと導く。

著者は、現代の LLM エージェントのセキュリティ確保には、反応的なパッチ適用から、意図から計画への翻訳と、計画から実行へのパイプラインの両方を同時に保護する原理的なアプローチへの転換が必要であると結論づけている。