技術要約：ソブリン実行ブローカー（Sovereign Execution Broker）

問題提起

大規模言語モデル（LLM）によって駆動される自律エージェントが、受動的な分析ツールから能動的な運用プランナーへと移行するにつれ、それらはプロダクション・インフラストラクチャのワークフロー（例：オートスケーリング、コンテナのデプロイ、セキュリティグループの管理）に統合されつつある。しかし、これらの非決定論的な推論プロセスに対して、直接的かつ常設的なアクセス資格情報（standing access credentials）を付与することは、深刻なセキュリティリスクを生じさせる。単一のハルシネーション（幻覚）や敵対的なプロンプト注入が、許可されていない、あるいは破壊的なインフラストラクチャの変異を引き起こす可能性がある。

既存のアーキテクチャは、提案されたアクションを検証し、暗号署名された証明書（$\Omega$）を発行する「ソブリン保証境界（Sovereign Assurance Boundary: SAB）」のようなアドミッション・ゲートを導入することで、この問題を軽減しようと試みている。しかし、アドミッション証明書だけでは強制執行には不十分である。実行時にその証明書を要求するランタイムメカニズムがなければ、エージェントや侵害されたラッパーは、常設の資格情報を使用してアドミッション・ゲートを完全にバイパスできてしまう。さらに、アドミッションのプロセスに従ったとしても、提案の承認から実際の実行までの間にタイムラグが生じるため、システムの状態がドリフトしたり、セキュリティポリシーが変更されたりする脆弱性の窓（Time-of-Check to Time-of-Use、またはTOCTOU脆弱性）が生じる。

手法：ソブリン実行ブローカー（Sovereign Execution Broker: SEB）

本論文では、認証された自律的な提案と、実際のインフラストラクチャ変異の間のギャップを埋めるためのランタイム強制境界として、**ソブリン実行ブローカー（SEB）**を導入する。コアとなるアーキテクチャ原則は、「提案（proposal）」、「承認（admission）」、および「実行（execution）」の分離である。

コア・アーキテクチャ

1. ゼロ常設権限（Zero Standing Privileges）： 想定されるデプロイメントにおいて、エージェントのランタイムやラッパーはいかなるプロダクション変異用の常設資格も保持しない。すべての自律的な変異リクエストは、SEBを経由しなければならない。
2. 証明書検証パイプライン： SEBは、SAB証明書（$\Omega$）と実行リクエスト（$req$）を消費するゲートキーパーとして機能する。実行前に、SEBは以下の形式検証パイプラインを実行する：
   • 署名（$\Phi_{sig}$）： SAB署名の妥当性。
   • コントラクト一致（$\Phi_{match}$）： リクエストのパラメータ、ターゲット、および操作が、認証されたコントラクト $C$ と正確に一致していることの確認。
   • 有効性（$\Phi_{time}$）： リクエストが証明書の有効期間内であることの確認。
   • ポリシーおよび失効（$\Phi_{policy}, \Phi_{rev}$）： 証明書がアクティブなポリシーバージョンと一致しており、グローバルなエポックカウンタによって失効していないことの検証。
   • ドリフト検知（$\Phi_{drift}$）： 承認時にキャプチャされたエビデンス状態（$E_{admit}$）とライブなターゲット状態（$St$）を比較し、TOCTOUによる変化を検知する。
   • リプレイ耐性（$\Phi_{replay}$）： 証明書のノンスが以前に使用されていないことの確認。
3. スコープ化された実行アイデンティティ： 検証に成功すると、SEBは自身のマスター資格を使用して実行するのではなく、トークンブローカーとして機能し、認証されたコントラクト、ターゲットリソース、および有効期間に厳格に紐付けられた、短寿命でスコープを絞った実行アイデンティティ（$ID_{exec}$）を発行する。
4. 強制パターン： バイパスを防ぐために、ターゲットとなるインフラストラクチャ（例：AWS、Kubernetes）は、ブローカーまたはブローカー発行のセッション以外からのすべての変異リクエストを拒否するように構成される必要がある。これは、サービスコントロールポリシー（SCP）、IAM権限境界、およびアドミッションウェブフックの検証を通じて実現される。
5. 監査可能性： すべての検証決定（拒絶または再承認）および実行結果は、署名された追記専用レジャーに記録され、アクションを元の証明書に結びつける暗号的な証拠を提供する。

主な貢献

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

1. ブローカーによる強制された自律性： 認証された提案と実際の変異の間の強制のギャップを特定し、エージェントが常設の資格を保持することを防ぐランタイム境界としてSEBを定義した。
2. 証明書検証実行モデル： ブローカーのインターフェース $Execute(\Omega, req, St, Platform) \rightarrow D | O$ を定式化し、署名、コントラクト一致、有効性、ポリシー、失効、ドリフト、およびリプレイチェックの述語を詳細に記述した。
3. スコープ化されたアイデンティティと実行前の失効： 資格は実行時のみに発行され、コントラクトにスコープされ、実行直前に失効チェックが行われるという、最小権限モデルを導入した。
4. プロトタイプの実装と評価： Go言語によるプロトタイプ（約4,200行のコード）を実装し、AWS STSおよびKubernetes TokenRequest用のアダプターを備え、必須の変異パスとしてデプロイし、現実的なワークロード下で評価を行った。

実験結果

プロトタイプは、レイテンシ、スループット、およびフォールト注入下でのセキュリティを測定するために、AWSおよびKubernetesクラスター（Amazon EKS）上で評価された。

• レイテンシ・オーバーヘッド：
  • Kubernetes： ブローカーは変異操作に対して約 28.2 ms（p50）のオーバーヘッドを追加する。主なボトルネックは、ライブ・ドリフト・チェック（42.9%）と資格の発行（42.9%）である。
  • AWS： オーバーヘッドはより高く、約 136.9 ms（p50）であり、AWS STSによる資格発行とドリフト・チェック（DescribeSecurityGroups API呼び出し）によって支配されている。
  • 比較： Direct IAMおよび監査のみのロギングはオーバーヘッドがほぼゼロであるが、SEBのセキュリティ保証を欠いている。SEBのオーバーヘッドは、高リスク・低頻度の変異（例：ファイアウォールの変更、オートスケーリング）については許容可能と考えられるが、マイクロ秒単位の制御ループには不向きであると指摘されている。
• 失効の伝播： 失効エポックのポーリング間隔を5秒とした場合、システムはエポックの進行から100%のリクエスト拒絶まで、最大 5.2秒 の伝播遅延を達成する。
• セキュリティとフォールトトレランス：
  • ブローカーのバイパス、古い証明書のリプレイ、リクエストと証明書の不一致、ネットワーク分断などの脅威をカバーする1,000件の注入テストケースにおいて、SEBは不正または無効なリクエストに対して 100%の拒絶率 を達成した。
  • フェイルクローズ・セマンティクス： ネットワーク分断やサービス障害が発生した場合、ブローカーは安全でない実行を防ぐために、リクエストを拒絶するデフォルト設定となる。
  • クラッシュリカバリ： システムは、冪等性トークンを使用してブローカーのクラッシュを処理し、重複した変異を防ぎ、状態の一貫性を確保することに成功した。

意義と主張

本論文は、従来のアイデンティティおよびアクセス管理（IAM）やポリシーエンジンでは提供できない、エージェントによるコントロールプレーンのための必要なランタイム強制層をSEBが提供すると主張している。

• アイデンティティからアクションへの転換： IAMが「誰が何を行えるか」を認可するのに対し、SEBは「現在のシステムエビデンスの下で、この特定の、認証されたアクション」を認可する。
• TOCTOUの緩和： 変異の直前にライブ状態のドリフトと失効エポックをチェックすることにより、SEBは承認と変異の間の脆弱性の窓を閉じる。
• 強制定理： 本論文は、特定のデプロイメント仮定（エージェントに常設資格がなく、ターゲットAPIがブローカー以外のアイデンティティを拒否すること）の下では、信頼できないエージェントは、有効で、期限切れではなく、失効しておらず、かつリプレイされていない証明書と、強制可能なスコープに一致しない限り、プロダクション状態の変異を引き起こすことはできないという形式的な証明（定理1）を提示している。

著者らは、SEBがレイテンシのオーバーヘッドを導入する一方で、認証された権限を短寿命で、失効可能で、かつ監査可能なランタイム能力へと変貌させ、セキュリティ侵害のコストがレイテンシのコストを上回るプロダクション環境における自律エージェントのセキュリティ確保のための、実行可能なソリューションにすると結論付けている。