この論文は、ユーザーが他者によってリモートにデプロイされた AI エージェント（たとえばオンラインプラットフォーム上のボット）を利用する際に生じる信頼のギャップを扱う。そうしたユーザーは、開発者が主張する安全ガードレールをエージェントが実際に実行しているかどうかを検証できない。著者らはこれを、安全対策が偽って宣伝される脅威として説明している。既存の 2 つの対処法は実行不可能だと論じられる。開発者に公開監査のためエージェントをオープンに実行することを義務づけるのは、システムプロンプトなどのエージェント実装が独自のノウハウであることと相容れず、信頼できる第三者の監査人に頼る方法は、普遍的に信頼される監査人が存在しない分散型やクロスプラットフォームのデプロイでは成り立たない。
提案手法である Proof-of-Guardrail は、特定のオープンソースのガードレールが実行された後に応答が生成されたことを示す暗号学的証明を、開発者が生成できるようにするシステムである。ラッパープログラムが公開ガードレールとその設定をバンドルし、エージェントのすべての入力、出力、ツール呼び出しを仲介する。このラッパーは Trusted Execution Environment（TEE） にロードされて初期化時に計測され、その後に開発者の非公開エージェントが秘密入力として渡される。各ユーザー入力に対して、ラッパーはガードレール付きのエージェントを実行し、エンクレーブの計測値と入力・応答へのコミットメントを含む署名付きのアテステーション文書を取得する。どのユーザーも、オープンソースのラッパーと TEE プラットフォームの検証鍵に照らして、これをオフラインで検証できる。エージェント自体は計測対象プログラムの一部ではなく秘密入力であるため非公開のまま保たれる。また、アテステーションはプラットフォームの リモートアテステーション 鍵で署名されているため、入力、応答、アテステーションがすべて公開されていても偽造や改ざんはできない。
著者らはこのシステムを AWS Nitro Enclaves 上の OpenClaw エージェント向けに実装し、実現可能だがコストが高いと報告している。TEE 内でのガードレール実行と応答生成には 25%〜38% のレイテンシのオーバーヘッドがかかり、アテステーション生成でおよそ 100ms が加わり、必要なインスタンスタイプは、同じエージェントに十分と彼らが考える非 TEE インスタンスより 1 時間あたり 18.5 倍高価である。著者らの中心的な注意点は、証明される性質が見かけよりも狭いということだ。有効な証明はガードレールが実行されたことを立証するが、応答が安全であることは立証しない。そのため、このシステムを安全性の証明（proof-of-safety）として解釈したり宣伝したりすべきではないと論じている。
要点
- 脅威モデルは、ガードレールを実行していると主張しながらそれをスキップしたり誤設定したりして、宣言されたガードレールなしで、あるいはその改変版で生成された応答を返す開発者である。
- システムが掲げる 3 つの要件は、ガードレール実行の計算上の完全性、開発者のエージェントの機密性、そしてユーザー入力や応答が開発者に対して機密であることを前提としないことである。
- 開発者のエージェントは計測されたラッパープログラムに秘密入力として渡されるため、アテステーションはエージェント実装を露出させずにガードレールとラッパーをカバーする。
- 信頼の拠り所は、デプロイにすでに使っているクラウドプロバイダーに置かれる。著者らは、AWS Nitro のハイパーバイザーがコードを正しく計測し TEE の秘密鍵を保護することを信頼すると述べており、これにより追加の第三者監査組織を信頼する必要がなくなると位置づけている。
- 3 つの模擬攻撃はすべて検証時に検出された。主張されたガードレールのコードを 1 行改変すると計測値の不一致が生じ（10 回中 10 回）、アテステーション文書のランダムな 1 バイトを改変すると署名が無効になり（100 回中 100 回）、ユーザーに示される応答を改変するとコミットメントハッシュの不一致が生じた（100 回中 100 回）。
- 非 TEE のベースラインに対して計測されたレイテンシのオーバーヘッドは、テストした 4 つのタスクで 24.8% から 38.0% の範囲にあり、アテステーション生成で 97.8ms が加わり、ユーザー側の検証には 5.1ms かかった。
- コスト比較は 1 つの組み合わせに基づく。1 時間あたり 0.192 ドルの m5.xlarge インスタンスと 1 時間あたり 0.0104 ドルの t3.micro の比較であり、Nitro Enclave ではガードレールのランタイム全体がメモリ上に存在する必要があるため、より大きなインスタンスが必要となる。
- これらの数値を得るのに使われた 2 つのガードレール自体も、テストしたデータセットでは不完全だった。コンテンツ安全性ガードレールは unsafe クラスで F1 0.56、ファクトチェック用ガードレールは非事実クラスと事実クラスでそれぞれ F1 0.76 と 0.67 だった。著者らはこれを、実行の証明が安全性の証明ではないことの直接的な証拠として示している。
- システムはガードレールがオープンソースであることを必要とするため、悪意のある開発者がそのガードレールに対してジェイルブレイク攻撃を仕掛けられると著者らは指摘し、金融ニュースのエージェントが有効な証明を提示しながら虚偽の助言でユーザーを誤導する例を挙げている。
- 著者らは、計測されたラッパープログラム自体に、計測されていないエージェントがガードレールを回避できるような脆弱性があってはならないと述べ、緩和策の 1 つとして、後から注入されるエージェントを実行不可能なプロンプト成果物に限定することを提案している。
補足
著者らはこの研究を、最も関連する先行研究として挙げるアテステーション可能な監査（attestable audits）と対比して位置づけている。これはユーザーが対話するモデルがセキュリティ監査に合格したことを証明可能にするものだと説明される。著者らは、Proof-of-Guardrail の利点は柔軟性にあると主張する。開発者は完全な監査をやり直すことなく、経験的に検証されたガードレールを採用しながら、その適用の暗号学的証明を生成できるからである。ガードレールの精度向上は対象外であり、ガードレール実行の証明とは補完関係にあることも明言している。
著者らは、特定した残存リスクを減らすために、検証者がベストプラクティスとされるオープンソースのガードレールとラッパープログラムに対する証明を要求することを提唱し、何をベストプラクティスとみなすかの確立は、研究、共有ベンチマーク、レッドチーミングの結果によって推進されるコミュニティのプロセスであると論じている。その根拠は、たいていのカジュアルなエージェント利用者は実装だけからガードレールの品質を評価しないだろうという点にある。インパクトステートメントでは、このシステムは低信頼の市場において誠実な開発者に利益をもたらすものとして位置づけられる一方、有効な証明はガードレールの実行を立証するだけで実際のエージェントの安全性は立証しないため、信頼のずれを生みうることも認めている。