この論文は、AIエージェントや自分で動作環境に手を伸ばせる「逃げられる」AIシステムが、自分自身の内側に置かれた安全措置を突破してしまう問題を扱います。研究者は、コントロールをエージェントのプロセス外に置くことで、エージェントから到達できない形で行動を許可・拒否する仕組みを設計しました。これを「実行時（execution-time）AI整合」と呼び、学習時や推論時の対策を補う層だと位置づけています。

研究チームは、アーキテクチャ的に有効な認可（許可）機構が満たすべき四つの性質を定めました。プロセス分離（エージェントと認可機構を別プロセスにする）、構造的に唯一の経路で事前に執行を強制すること（実行前に必ず検査する経路を作る）、リクエストとシステムの両面で失敗時に閉じる（fail-closed）性、そして外部で検証可能な署名付きの証拠を出すことです。これらを実現する参照実装が「Unfireable Safety Kernel」で、Rustで書かれています。実装は「ノーカーネル、ノーエージェント（no kernel, no agent）」のライフサイクル制約や、オペレータの鍵で署名されるEd25519形式の追跡可能な不変ログ（追跡・検証可能な記録）を備えます。

正しさの検証にも力を入れています。安全に拒否する性質（fail-closed）は二段階で機械的に検証されました。まずSMT（満たされるかを論理的に調べる手法）の定理証明器Z3でモデルを証明し、実際のRust決定関数についてはバウンド付きモデル検査器Kaniで包括的な検査を行い、4つの検査ハーネスがすべて通りました。実装移行でも慎重で、PythonからRustへの移植はバイト等価性でゲートをかけ、1,000件の確定的テストで1000/1000一致、17クラスの攻撃的ケースでも17/17で同じ拒否振る舞いを示したと報告しています。公開実装はApache-2.0で配布されています。

実運用に近い評価も示されています。研究チームは「完全自律で自己改変する世界モデル」を制御対象にして攻撃者を想定した試験を行いました。1,000回の自己改変試行のうち、安全性の核心に対する704件の攻撃的改変はすべて拒否され、逃走は確認されませんでした。さらにオペレータのキルスイッチを有効にした追加300回も拒否されました。別の試験では6,240回の認可往復を行い、そのうち6,038回はコンパイル済みRustカーネルをHTTP経由で使ったケースで、成功するバイパスは報告されませんでした。また、同分類の既存システム（GalileoAgentControl、Microsoft Agent Governance Toolkit、Microsoft Authorization Fabric）と比べると、既存の多くはエージェント側が制御を呼び出す設計なのに対し、本実装ではエージェントにその選択肢が与えられない点が特徴だと述べています。

重要な限界も明示しています。設計はデプロイ側のインフラ（ホストやネットワーク、オペレータ鍵を保管する環境）を信頼する前提です。カーネルは上流でのプロンプト注入（入力を通じた操作影響）を防ぐものではありませんし、モデルのテキスト出力を内容でフィルタする機能も提供しません。サイドチャネル（挙動の時間や応答で情報を漏らす問題）への対策は既知の手法があるとしつつ未実装です。サービス拒否（Denial of Service）攻撃が起きれば稼働停止になる可能性があり、この場合でも安全方針は「閉じる」のでバイパスにはなりませんが、運用上の停滞は生じます。さらに、オペレータ鍵の内部悪用（署名された悪意ある方針の発行）をこの設計だけで防ぐことはできず、多者署名のような追加措置が必要とされています。