技術要約：銀行業務におけるLLMエージェントのための検証可能な委任権限

1. 問題の定義

LLM（大規模言語モデル）エージェントを銀行インフラに統合することは、根本的なセキュリティ上のギャップをもたらす。従来のAPIセキュリティモデルは、安定したアクターの仮定（認証されたセッション内の人間、またはバージョン管理されたAPIを呼び出す決定論的なサービス）に基づいている。しかし、LLMエージェントは非構造化されたコンテキストを読み取り、非決定論的に推論し、実行ごとに変動する可能性のあるアクションシーケンスを選択するため、これら両方の仮定を打破してしまう。

エージェントが資金移動を行うシステムに接続される場合、この非決定性は重大なリスクを生む。既存の安全性研究の多くは、モデルレベルでのプロンプトインジェクションの検出やフィルタリングに焦点を当てている。しかし、著者は、規制対象である銀行業務においては、権限の強制をモデル内ではなく、実行境界（execution boundary）へと移行させる必要があると主張している。核心となる課題は、エージェントを「信頼できない確率論的な提案者（untrusted stochastic proposer）」として扱い、そのエージェントが委任された権限を超過できないという形式的な保証を提供しつつ、第三者（監査人または規制当局）がエージェントの自己報告を信頼したりモデルの重みにアクセスしたりすることなく、コンプライアンスを検証できるようにすることである。

2. メソドロジーとシステムアーキテクチャ

本論文は、LLMを厳密に「型定義されたアクションの信頼できない提案者」として扱い、決定論的なポリシーエンジンと実行レイヤーがすべての権限を強制する形式的なアーキテクチャを提案している。

コアコンポーネント

• 権限の形式モデル:
  • アクション（Actions）: パラメータ空間（例：金額、通貨）と関連する損失エクスポージャーを持つ、型定義されたアクションとして定義される。
  • 委任チェーン（Delegation Chains）: 権限は、時間の経過とともに減衰（attenuate）していく一連の付与（grants）として表現される。有効なチェーンは、いかなるエージェントも権限を昇格させられないことを保証する。すなわち、エージェントの有効な権限は、ルート・プリンシパルの付与のサブセットとなる。
  • 信頼できるコンピューティング基盤（TCB）: ポリシーエンジン、実行レイヤー、追記専用ログ、およびアイデンティティ・インフラストラクチャを含む。LLMは明示的にTCBから除外される。
• 署名付き意図エンベロープ（Intent Envelopes）とトークンのプロトコル:
  • 意図エンベロープ: 提案されたアクションは、アクション、エージェントの識別子、委任チェーン、およびビジネスケースを含む署名付きエンベロープに包まれる。
  • 能力トークン（Capability Tokens）: ポリシー承認後、エンジンは単回使用かつパラメータ制限付きのトークンを発行する。極めて重要な点は、トークンの有効期間（$t_{exp}$）が、基礎となる委任チェーンの期限によって厳格に制限されていることである。
  • 実行チェック: 実行レイヤーは、トークンの署名を検証し、アクションがトークンの型およびパラメータ範囲と一致しているかを確認し、トークンが有効期間内であることを確認し、識別子が一度使用されていないことを確認する。
• 検証可能なワークフロー:
  • すべての状態遷移は、ハッシュチェーン化された追記専用ログに署名付きイベントを放出する。
  • **エビデンスのみの検証器（evidence-only verifier）**は、モデルを再再生することなく、ログ、公開鍵、およびポリシーバージョンのみを使用して、ワークフロー全体を検証できる。
• マルチエージェント合意（Multi-Agent Consensus）:
  • 高リスクの意図に対しては、独立して構成されたセカンド・レビューアー・エージェントが導入される。
  • 本論文では、「共通原因（common-cause）」による失敗（例：共有された学習上の盲点）をモデル化し、レビューアーの**多様性（diversity）**が、残留リスクを低減させるためにはレビューアーの数よりも重要であることを示す。

3. 主な貢献

本論文は、以下の5つの具体的な理論的および実用的な貢献を提供している。

1. 形式モデル: 銀行業務におけるLLMエージェントの委任権限の定義。これには、型定義された金融アクション、減衰する委任チェーン、および人間による承認ライフサイクルを備えた決定論的な属性ベースアクセス制御（ABAC）ポリシーエンジンが含まれる。
2. 認可プロトコルと証明:
   • 定理1（権限の包含）: 任意の敵対的提案者の下でも、ポリシーエンジンと署名スキームが安全である限り、実行されるすべての操作は有効な委任チェーンの有効権限内に含まれることを証明する。
   • 定理2（無人時の損失上限）: 型ごとの上限およびスライディングウィンドウ方式のレート制限に基づき、人間の承認なしで実行されたアクションによる財務的損失の閉じた形式の上限を導出する。
3. マルチエージェント合意分析:
   • 命題1: 合意の残留リスクを定量化し、レビューアーの数を増やすだけでは、共通原因による失敗確率（$\gamma$）が多様性によって低減されない限り、収穫逓減が生じることを示す。
   • 命題2: 被害の確率とレビューのコストに基づき、人間またはエージェントによるレビューを呼び出すためのコスト意識のあるルールを確立する。
4. 検証可能なワークフローの定義:
   • 定理3（改ざん耐性）: 署名付きのヘッドと独立したウィットネス（ロールバック攻撃を防ぐため）を持つログは、いかなる受け入れられたエビデンスシーケンスも、正当なログと一致することを証明する。
   • 定理4（健全性）: エビデンスのみの検証器が、モデルにアクセスすることなく、実行されたアクションが承認され、範囲内であったことを健全に証明できることを示す。
   • 命題3: モデルのバージョン変更に伴うポリシー・ドリフトを検出するためのサンプル複雑性（sample-complexity）の境界を提供する。
5. リファレンス実装とシミュレーション:
   • 敵対的プロポーザー（LLMをループに入れない）に対するPython実装を用いて、包含性、損失境界、および改ざん耐性を検証した。

4. 結果

リファレンス実装とシミュレーションにより、以下の結果が得られた。

• 包含性: 偽造トークン、リプレイ、パラメータ改ざんを含む9つの攻撃クラスをカバーする、敵対的プロポーサーによる70万回の試行において、包含定理に違反する不正な実行はゼロであった。
• 損失境界の緊密性: レート制限を飽和させたアドバーサリが達成した最大エクスポージャーは、定理2の理論的境界と正確に一致しており、この境界がタイトであることを裏付けた。
• 特定されたプロトコルの欠陥: シミュレーションにより、初期設計における2つの重大な欠陥が露呈した。
  1. トークンの期限切れ: ルール $t_{exp} \le t_k$ （トークン期限 $\le$ チェーン期限）がない場合、2万件の試行のうち12,383件が委任されたグラントの期限切れ後に実行されていた。
  2. ログのロールバック: 独立したウィットネス・チェックがない場合、攻撃者は署名付きの古いヘッドへとログをロールバックすることに成功したが、ウィットネス・チェックを用いることで、検出率が100%となった。
• パフォーマンス: エンフォースメント・パイプライン（エンベロープ・チェック、ポリシー、トークン発行、実行、ロギング）のメディアン・オーバーヘッドはアクションあたり45マイクロ秒であり、強制のコストがボトルネックにはならないことを示唆している。
• 合意モデリング: 共通原因モデルを用いたモンテカルロ・シミュレーションは、誤差範囲内で命題1の解析的予測と一致した。

5. 意義と主張

著者は、本研究を一般的なマルチエージェントの安全性研究とは異なる、規制対象の銀行業務に特化した形式的な取り扱いとして位置づけている。

• 信頼境界のシフト: エンフォースメントを実行境界へと移動させ、LLMを「信頼できない提案者」として扱うことで、モデルの推論やアライメントに依存しない**「証明可能な権限の包含」と「定量化可能な損失境界」**を実現できると主張している。
• 監査可能性: 第三者（監査人/規制当局）が、独自のモデルやその重みにアクセスすることなく、エビデンスのみの検証器を通じてコンプライアンスを検証できるという点は、重要な主張である。
• 定量的リスク管理: マルチエージェント・レビューに関する定量的なフレームワークを提供し、残留リスクを低減させるための主要なレバーは、単にレビューアーの数を増やすことではなく、**「多様性」**であることを論じている。
• スコープに関する謙虚な姿勢: 著者は、結果が「エンフォースメントされた境界内」で動作するLLMを前提としていることを明示している。プロンプトインジェクションによってエージェントが（許可された範囲内ではあるが望ましくない）アクション（例：制限内での誤った支払いの再提出）へと誘導される問題を、無害に解決するものではない。ただし、コンセンサスがそのような事象の発生確率を低減させることには触れている。また、証明は「ペンと紙」によるものであり、機械化されたものではないこと、およびシミュレーションは実際のLLMをループに入れない合成データを使用しているため、現実世界のインジェクション耐性や有用性の評価は今後の課題であることを認めている。

結論として、本論文は、このような形式的なアーキテクチャなしでは、エージェントをコアな銀行インフラに統合することは「ほとんど監査されていない攻撃表面」を生み出すことになると主張している。このアーキテクチャを用いることで、金融機関は、包含性と検証可能性の形式的な保証を伴って、エージェントによる自動化をバックオフィス・ワークフローへと拡張することが可能となる。