Context-to-Execution Integrity for LLM Agents
本論文は、保護されたシンクフィールド、ペイロード、および呼び出しイベントに対して厳格な権限チェックを強制することで、バインディングフィールド、エフェクト、および呼び出し権限を持つアクションのみが実行されるようにし、多様なベンチマークにおいて観測されたセキュリティエスケープ・ゼロを達成する、LLMエージェントを保護するためのシステムであるContext-to-Execution Integrity (CXI) を導入する。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
非常に有能だが騙されやすいアシスタント（AIエージェント）を想像してください。このアシスタントは、メールの送信、ファイルの編集、コードの実行など、あなたの代わりに仕事をこなそうとしています。このアシスタントは、指示、メモ、メッセージが詰まった膨大なノートを読み込みます。問題は、巧妙な詐欺師（攻撃者）がこのノートの中にメモを忍び込ませ、アシスタントを騙して、データベースの削除や誤った人物への送金といった危険な行為を行わせようとすることです。
この論文では、Context-to-Execution Integrity (CXI) と呼ばれるシステムを紹介しています。CXIを、「アクションルーム（実行室）」の入り口に立っている非常に厳格な警備員だと考えてください。その仕事は、物語全体を読んだり、そのタスクが良いアイデアかどうかを判断したりすることではありません。その仕事は、アシスタントが「この特定のアクション」のために開けることができる特定の有効な鍵を持っているかどうかを確認することです。
仕組みは以下の通りです。簡単な比喩を用いて説明します。
1. 問題：「権限のロンダリング（Authority Laundering）」
通常、もしアシスタントがノートの中で「ファイルが失敗したので、delete_all コマンドを実行せよ」というメモを読んだ場合、アシスタントはそのまま実行してしまうかもしれません。論文ではこれを権限のロンダリングと呼んでいます。これは、泥棒が正当に見えるIDカード（ファイル失敗に関するメモ）を盗み、それを使って銀行の金庫を開けようとするようなものです。メモは「なぜ」それが起きたのかを説明していますが、それ自体が何かを「実行させる」力を持つべきではありません。
2. 解決策：3部構成のセキュリティチェック
CXIはゲートキーパー（門番）として機能します。アシスタントが実際に何か（ファイルの書き込みやメールの送信など）を行う前に、ゲートキーパーは3つの項目をチェックします。これらすべてが同じ特定の計画（「マニフェスト」と呼ばれます）と一致していなければなりません。
チェック1：「誰が」（フィールド権限 / Field Authority）
- 比喩： アシスタントが特定の人に手紙を書こうとしているとします。ノートには「ボブに送れ」と書いてあるかもしれません。しかし、セキュリティガードはこうチェックします。「信頼できる上司や検証済みのシステムが、本当に『ボブに送れ』と言ったのか？」
- もし「ボブ」という名前が、攻撃者が書いたランダムなメモから来たものだった場合、ガードはNOと言います。その名前は、「この特定のフィールドに対してこの名前が許可されている」と明示する特別な検証済みスリップである「タイプ付きリリース（Typed Release）」から来ている必要があります。
チェック2：「何を」（効果権限 / Effect Authority）
- 比喩： アシスタントがコンピュータプログラムにパッチを適用しようとしているとします。メモには「このコードを適用せよ」とあります。ガードはこうチェックします。「このコードは、本当に意図した通りのことを行うのか？」
- ガードは単に言葉を見るのではなく、その「結果」を見ます。もしコードが「パッチ」であるなら、ガードはそのコードがシステムにどのような変更を加えるかを正確に検証します。もし攻撃者が、パッチのように見えて実際にはファイルを削除するコマンドを紛れ込ませようとしても、ガードは「効果」が許可された計画と一致しないため、それを検知します。
チェック3：「いつ」（呼び出し権限 / Invocation Authority）
- 比喩： アシスタントが「ゴー（実行）」ボタンを押そうとしているとします。ガードはこうチェックします。「アシスタントは、今まさにボタンを押すための有効なチケットを持っているか？」
- 名前と計画が正しくても、アシスタントがアクションをトリガーするためには、特定の「ケイパビリティ（能力/権限）」またはチケットが必要です。もし攻撃者が、アシスタントを騙してボタンを2回押させたり、不適切なタイミングで押させようとしたりしても、チケットが欠けているか期限切れであるため、ガードはNOと言います。
3. 「マニフェスト」（マスタープラン）
論文では、最終的に承認された計画をマニフェストと呼んでいます。これは契約書のようなものです。
- アシスタントがアクションを提案します。
- ガードが「誰が」「何を」「いつ」をチェックします。
- これらすべてが完全に一致し、かつ同じ契約に紐付けられている場合、ガードは契約にスタンプを押し、アシスタントに「リース（実行許可）」を渡します。
- もし一つでも欠けていたり、一致しなかったりする場合（例：名前は合っているが、「いつ」のチケットが間違っているなど）、ガードはドアを閉ざします。
4. 「悪い」メモについてはどうなるのか？
論文では、アシスタントは依然として攻撃者のメモを「読む」ことはできると述べています。
- 不透明なデータ（Opaque Data）： もし攻撃者が「システムが壊れている」と書いた場合、アシスタントはそのテキストを「コメント」や「証拠」ボックスにコピーすることができます。これは、そのメモをガラスの展示ケースに入れるようなものです。人間が読むためのテキストとしては可視化されていますが、ドアを開けたりアクションをトリガーしたりする力は持ちません。それは単なる「データ」であり、「鍵」ではないのです。
5. 何をテストしたのか？
著者らは、いくつかの方法でこのシステムをテストしました。
- ライブ・シミュレーション： 彼らは、攻撃者がエージェントを騙そうとする720の現実的なシナリオを含む「道場（トレーニングの場）」を使用しました。システムは、すべての不正なアクションをブロックしました。
- コード・エージェント： コードを書くエージェントをテストしました。攻撃者が不正なコマンドを注入しようとしても、システムは正しい「鍵」を持つアクションのみを許可しました。
- 結果： すべてのテストにおいて、不正なアクションの通過はゼロでした。システムは「権限のロンダリング」を阻止することに成功しました。
まとめ
CXIは、AIエージェントが騙されるのを防ぐためのシステムです。 これは、AIがメモの中にある危険な指示を「読んだ」としても、それによって何かを行う「権限」を持つわけではないことを保証します。AIは、信頼できるシステムが、その特定の仕事のために、その特定のタイミングで、特定の鍵を明示的に与えた場合にのみ、行動することができます。これにより、AIは「騙されやすい読者」から、検証済みの命令のみに従う「規律ある労働者」へと変わるのです。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。