技術要約：エージェンティック・インフラストラクチャにおけるソブリン・アシュアランス・バウンダリ（主権的保証境界）

1. 問題提起

大規模言語モデル（LLM）エージェントを運用ワークフローに統合することは、制御プレーンの認可における決定的なギャップをもたらす。エージェントは、高リスクなプロダクション・リソースへの変更（ノードのスケーリング、認証情報のローテーション、ネットワークセキュリティグループの修正など）を提案できる能力を持つが、既存のセキュリティメカニズムでは、これらの非決定的な推論システムを統治するには不十分である。

• 静的 vs 動的: 従来のアイデンティティおよびアクセス管理（IAM）やポリシーエンジンは、静的な権限や構造的なコンプライアンスを強制するが、自律的な提案がライブな証拠によって意味的に正当化されているかどうかを判断することはできない。
• 事後的な限界: 監査ログやコンセンサス・プロトコルは、実行後、あるいは状態遷移のセマンティックな安全性を評価することなく、アクションの記録や状態遷移への合意を行う。
• リスクの累積: 個々には妥当に見えるエージェントのアクションが蓄積することで、可用性の停止、データ漏洩、ポリシーのバイパス、フォレンジック・コンテキストの喪失といったシステム的な失敗を招く可能性がある。
• 核心的なギャップ: エージェントの提案を、証拠、ポリシー、および失効状態に紐付けた上で、実行権限へと変換するランタイムの受理境界が存在しない。

2. 手法：ソブリン・アシュアランス・バウンダリ（SAB）

本論文では、**ソブリン・アシュアランス・バウンダリ（SAB）**を提案する。これは、エージェントの推論とインフラストラクチャの変更の間に介在する、証明書に紐付けられたランタイム受理境界である。SABは、「機関がポリシー、証拠、および実行権限に関するローカルな制御を保持する」という原則に基づいて動作し、エージェントのランタイムを「信頼できない提案者」として扱う。

2.1 アーキテクチャ：エアロック–ブローカー・モデル

SABは、システムを以下の2つの明確なレイヤーに分離する：

1. 信頼できないエージェント・ランタイム: 提案を生成するが、常設の資格情報や直接的な実行権限は保持しない。
2. 信頼できるソブリン実行ブローカー: インフラストラクチャAPIを呼び出すことを許可された唯一のエンティティ。これは、署名された**ソブリン・アシュアランス証明書（$\Omega$）**を検証した後にのみ、変更を実行する。

受理パイプラインは以下のステージで構成される：

• コントラクト・コンパイル: 生のエージェント・コマンドを、ターゲット、前提条件、事後条件、およびロールバックを定義する、厳密に型定義された**実行コントラクト（$C$）**へと正規化する。
• 証拠のバインディング: 証拠コレクターがテレメトリ、ログ、およびチケットを収集し、意思決定時のシステム状態の暗号学的ダイジェスト $H(E)$ を算出する。
• 結果スコアリング: スコアラーが、影響範囲（ブラスト・レジアス）、権限拡大、データの機密性、不可逆性、および不確実性に基づき、リスク指標 $R(C)$ を算出する。これにより、自律レベル（$L(C)$）（L0 アドバイザリーから L5 禁止まで）が決定される。
• 証明経路ルーティング: $L(C)$ とポリシーに基づき、コントラクトは特定の経路（例：PolicyOnly, LightweightQuorum, SQA, SQAPlusHuman）へとルーティングされる。
  • セマンティック・クォーラム保証（SQA）: 外部の信頼できないバリデータ・メッシュが、アクションのセマンティックな許容性に関する署名付きの証言（$\Gamma_{SQa}$）を提供する。
  • 人間による承認: 高リスクなアクションについては、オペレーターが特定のコントラクトおよび証拠に紐付けられたマルチシグ承認を提供する。
• 証明書の発行: アシュアランス・エアロック（信頼コンピューティング基盤の一部）は、すべての経路要件を検証し、署名された**ソブリン・アシュアランス証明書（$\Omega$）**を発行する。
  • $\Omega$ に含まれる内容：$C$、$H(E)$、$R(C)$、$L(C)$、証明経路、$ID_{exec}$、$T_{valid}$、$P_{ver}$、および $\rho_{rev}$。
• ブローカーによる検証: 実行前に、ソブリン・ブローカーは $\Omega$ の署名を検証し、失効エポックを確認し、ポリシーバージョンを検証し、ライブな状態がバインドされた証拠 $E$ から逸脱していないかを確認するための状態ドリフトチェック（$\Phi_{drift}$）を実行する。

2.2 形式的不変量

SABは、5つの権限境界不変量を強制する：

1. 提案と実行のデカップリング: エージェントの提案は、エアロックによる受理なしにはいかなる変更もトリガーしない。
2. 証明書に紐付けられた実行: 実行は、特定のコントラクト $C$ を含む有効な $\Omega$ をブローカーが検証した場合にのみ行われる。
3. 証拠のバインディング: 承認および証言は、$C$ および $H(E)$ に暗号学的に紐付けられており、異なるコンテキスト間での再利用を防止する。
4. 単調な経路選択: コントラクトは、選択された証明経路のすべての要件が満たされた場合にのみ受理される。より低い保証レベルの経路が、より高いリスク要件を上書きすることはできない。
5. エフェメラルな権限: 証明書は、失効エポックが古い場合、または実行時間が有効期間外である場合に拒否される。

3. 主な貢献

本論文は、主に4つの貢献を行う：

1. 証明書に紐付けられた受理: 自律的な実行権限を、アンビエントな権限から、取り消し可能で証拠に紐付けられたアーティファクトへと変換する、ランタイムの受理境界を定義する。
2. エアロック–ブローカー・アーキテクチャ: 提案、受理、および実行を分離する具体的なコンポーネント（コントラクト $C$、証拠ダイジェスト $H(E)$、証明書 $\Omega$、およびソブリン・ブローカー）を導入する。
3. 結果を考慮した認証: 結果スコアリング、自律レベル、証明経路、および失効メカニズムを形式化し、実行前のエスカレーション、拒絶、および中断をサポートする。
4. プロトタイプおよび実現可能性の評価: コントラクトのシリアライゼーション、OPA/Rego ポリシーチェック、Ed25519 署名、および PostgreSQL バックエンドのレジャーを含む、システムの実現可能性を示す Go プロトタイプを実装する。

4. 結果と評価

著者らは、ローカル・テストベッドにおいて、500 個のラベル付き実行コントラクトを用いた 2,500 回の受理試行を用いてプロトタイプを評価した。

• レイテンシ:
  • ポリシーのみの受理: 約 1.84 ms (p50)。
  • SQA 受理（バリデータ・メッシュを使用）: 約 185 ms (p50) / 380 ms (p95)。
  • ブローカー検証: 約 0.15 ms (p50)。
  • 失効伝播: 約 12.4 ms (p95)。
• 精度:
  • ルーティング精度（エキスパートによるラベル付けされたオラクルとの一致）: 96.8%。
  • 不安全な受理率: 0.4%。
• 効率性:
  • 人間による承認の削減: 人間のみのキューと比較して 68.2% 減少。
  • 証明書ストレージ・オーバーヘッド: アクションあたり約 3.4 KB。
• 再生可能性: レジャーのエントリの 100% が、スキーマ・コンテキストとともに再生可能であった。

結果は、コントロールプレーンのオーバーヘッドが単一のワークステーション上で実行可能であり、レイテンシを犠牲にすることで保証と再生可能性を得られることを示している。

5. 意義と主張

本論文は、SAB が既存のセキュリティ層を置き換えることなく、特定の認可ギャップに対処することを主張している。

• 運用の主権: SAB は、ポリシー評価、証拠保持、署名鍵、および実行権限に関するローカルな制御を機関が保持することとして、主権を定義する。外部モデルは提案の生成に限定され、ローカルな認証をバイパスすることはできない。
• 構成可能性: SAB は、IAM、形式検証、コンセンサス・プロトコル、または人間によるレビューの代替ではない。むしろ、これらをシステムレベルの受理境界へと構成するものである。それは、委任された実行権限を、証明書に紐付けられ、証拠に紐付けられ、取り消し可能で、再生可能なランタイム・アーティファクトとして扱う。
• リスク軽減: 提案の生成と実行を分離し、実行を新鮮な証拠とアクティブなポリシーに紐付けることにより、SAB は自律的な推論のみによって状態が変更されることを防ぎ、それによってシステム的な失敗、データ漏洩、およびポリシー・バイパスのリスクを軽減する。

著者らは、SAB が信頼コンピューティング基盤（TCB）の完全性、外部証拠の鮮度、およびバリデータの較正に依存していることを認め、控えめな立場を維持している。また、プロトタイプの成果はワークロードに依存するものであり、一般的なパフォーマンスを保証するものではないと述べており、高コンシクエンスな領域から開始する漸進的な導入戦略を示唆している。