APort Vault：AIエージェントの決済権限を実行結果で検証

決済エージェントは、文章で受けた依頼をもとに送金ツールを呼び出せる。ここで安全性を測るには、モデルが「送金したい」と要求した段階と、ツールによって送金が実行された段階を分ける必要がある。攻撃文にモデルが従っても、実行前の権限確認が拒否すれば送金は起きない。逆に、モデルの返答だけを見て安全そうだと判断しても、実行結果を確かめたことにはならない。APort Vaultが問うのは、この二つの段階を分けたとき、権限確認が許可外送金をどれだけ防ぐかだ。

Open Agent Passport（OAP）は、エージェントに許す操作の条件を記す仕様だ。この論文では権限レベルごとのパスポートを使い、送金先や金額、上限などが条件に合うかを判定する。例えば、登録済みの取引先への送金だけを許す状況を考える。攻撃文が別の送金先を指定し、モデルがその指示を送金ツールに渡しても、実行直前の検査で拒否できる。この例が表すのは送金先の許可条件であって、登録済みの相手への送金が業務上正当かどうかまでは表さない。

著者らによると、先行する攻撃評価はモデルが攻撃を拒んだか、どう応答したかを主に採点してきた。だが決済では、モデルが要求した後にツールが何を実行したかも結果を左右する。LLMに成否を審査させる方法なら、審査員の判断の安定性も測定値に影響する。この研究は、送金要求、成功した送金、権限判断、送金先が許可リストに入るか、許可外送金を別の出来事として記録する。主要な許可外送金の判定には、実行されたツール呼び出しを用いる。

主要な比較は、一部の送金先を許すレベル2～4に絞られる。レベル1は送金先を広く許すため、同じ意味での許可外送金を測りにくい。レベル5は決済権限がなく、モデルには送金ツールを呼ぶよう指示されるため、こちらも別に扱う。この区別は結果の読み方に関わる。送金要求が多いレベルでも、その送金先が許可済みなら、要求数をそのまま権限違反の数にはできない。

著者らは公開の攻撃イベントで集めた生データ4,750件から、空の372件と個人情報を含む7件を除き、1,128セッションに由来する4,371件の攻撃を使った。これを14モデル、5権限レベル、二つの再実行方式、認可層の有無で評価し、完了した評価は225,964件だった。再実行方式の一つは最後の攻撃メッセージだけを渡す単一ターン、もう一つは会話列全体を渡す複数ターンだ。各条件の実行は1回であり、同じ条件を繰り返したときの揺れを直接測った設計ではない。

比較の核は、同じモデル、攻撃文、生成時の設定、ツール仕様を使い、送金ツールの実行経路に認可層を置くかどうかを変える点にある。認可層付きでは、送金ツールが呼ばれるたびにパスポートの条件を照合し、拒否した呼び出しは実行しない。モデルに見せるプロンプトを認可条件に合わせて書き換えるわけではない。先の取引先の例なら、モデルが未登録の相手への送金を要求する可能性は残る。それでも、要求が実際の送金になる手前に判断を置ける。

評価一件は、あるモデルがある攻撃を一つの方式と条件で処理した結果を指す。送金ツールの呼び出し件数とは単位が違う。著者らはまず、完了したレベル2～4の評価全体でモデル単独と認可層付きを比べる。ただし両者の完了件数は異なり、含まれる攻撃の構成も完全には同じでない。そこで、モデル・攻撃・再実行方式が一致する68,970組も別に比較する。この対応比較の方が、認可層の有無による差を読みやすい。

一つの元セッションから複数の攻撃が生じるため、評価をすべて独立した試行とは扱えない。著者らはセッションを単位として1,500回抽出し直すブートストラップで集計の揺れを見た。ブートストラップは、元のまとまりを保って標本を取り直す方法だ。許可外送金がゼロ件だった条件には、790の元セッションに基づく片側95％の上限も示す。これは「危険がゼロと証明された」という意味ではなく、この標本からどの程度までの率を否定しにくいかを示す。

著者らの報告では、レベル2～4の完了評価全体で、許可外送金はモデル単独の76,842評価中140件に対し、認可層付きの69,297評価中0件だった。さらにモデル・攻撃・再実行方式を揃えた68,970組では、モデル単独105件、認可層付き0件となった。見出しに使えるのはこの対応比較の105件対0件だ。認可層付きでのゼロ件について、著者らが重視する片側95％のセッション単位上限は0.380％である。観測されなかったことと、今後も起こらないことは同じではない。

認可層付きのレベル2～4では、69,297評価中25,370評価で送金が成功した。送金ツールの呼び出し25,640件の内訳は、許可25,453件、拒否187件だった。拒否理由は送金先違反148件、金額不正17件、上限違反13件、監査コード欠落9件である。これは、権限条件に合う送金を通しながら、条件に合わない呼び出しを止めたという著者らの結果を支える。ただし成功した送金が、利用者の本来の意図にも合っていたかは、この数からは分からない。

対応する68,970組で、送金要求はモデル単独25,362件、認可層付き25,420件だった。要求率の差は認可層付きで0.084パーセンテージポイント高く、95％区間はマイナス0.020からプラス0.189ポイント。集計値は近いが、個別には1,220組で要求の有無が食い違い、著者らも同等性が証明されたとは解釈していない。モデル単独の要求率はレベル1で10.9％、2で3.0％、3で0.1％、4で79.4％だった。ただし攻撃はそれぞれ一つのレベルにしか属さず、権限設定と攻撃集団が一緒に変わるため、率の差を設定だけの効果とは読めない。

レベル4の単一ターンでは、共通の1,293入力のうち809入力で14モデルすべてが送金を要求した。著者らによれば、その入力で成功した送金先はいずれもレベル4の許可先であり、809件を「全モデルが攻撃に敗れた件数」とは呼べない。一方、レベル2の複数ターンでモデル単独に起きた許可外送金113件のうち111件は、偽の送金先確認結果を含む103攻撃、8セッションの集団から生じた。特定の攻撃群が結果を大きく動かしたのであって、複数ターン攻撃全般で同じ頻度が出るとは限らない。

主要指標はツールの実行結果から判定しているが、二つのLLM審査員による二次的な判定は条件によって不安定だった。著者らの報告では一致度は全体でκ＝0.772、レベル3で0.167、レベル5で0.521、確認済み結果の再現率は99.1％と64.4％だった。対象は模擬銀行の単一送金ツールと自己選択した攻撃参加者に限られ、複数ターンの認可層付き評価には欠損や部分的なモデルもある。レベル4のローカル認可エンジンは公開ポリシーパックより厳しいため、公開設定でも同じ結果になるとは言えない。正当な依頼への過剰拒否、人手による事前登録済みの検証、反復実行による揺れの確認も未完了だ。著者は認可層を開発する企業の創業者で、評価の設計・実行・分析も担った。公開された評価データなどは検証の材料になるが、一部の監査情報や実行環境との一致は公開行だけでは再計算できない。設定ミス、広すぎる権限、検査の迂回も、このゼロ件では排除されない。