2026-08-09、Self-Correcting Systemsは、AIエージェントのワーカーが人間に承認された`repro`ルートを1回だけ実行し、同じまだ有効なレシートの再実行を拒否できることを、監督付きオペレーター実行で示した。著者は、実機からライブ結果を読み戻し、すべてのハッシュ、契約、ブレーカー判定、レシートをGitHubで公開した一方、外部再現はゼロのままだと述べた。公開後に追加された訂正では、Peterが実運用上の穴を見つけたとされた。P1ルートマニフェストはジョブ本文、インタープリタ、エントリースクリプトを束縛していたが、`repro.py`がローカルの`gates.py`をインポートするため、プロジェクトコード全体のクロージャは束縛していなかった。`gates.py`だけを変更しても、署名済みルートマニフェストのハッシュは変わらなかった。

同システムの前回のJuly 31修正では、ワーカーがすべてのルートを拒否し、到達可能な`True`分岐が残らなかった。新たな問いは、ワーカーが2つ目を開く権限を得ずに、ちょうど1つのポジションだけを開けるかどうかだった。承認された`repro`ルートは、シェルや汎用コマンドランナーではなく、シーケンス攻撃の決定論的な再現である。スクリプトは453行で、実行された公開コミットは`d44a72c`、そのSHA-256は`f0c0ec9eee57c022207491ac6fcd02e64ff908aefa8ed936ced064c860cb7636`だった。

承認レシートは、キューに入ったジョブID、ジョブの`id`、`assign`、`text`のダイジェスト、正確な作業ディレクトリ、ツール名、解決済みPythonインタープリタパスとSHA-256、解決済みスクリプトパスとSHA-256、最大実行時間、期限、1回限りのNonceを束縛した。ワーカーは認可中にルートマニフェストを確認し、Nonceを消費したうえで、`subprocess.run`の直前に実行境界の内部でマニフェストを再計算した。有効な`repro`レシートでは、`adapter`、`eye`、自由形式の`AUTO:`プロンプト、ヘッドレスモデル、フォールバック経路を認可できなかった。

著者はHMACではなく非対称署名を使った。HMAC検証用の秘密を読めるワーカーは、有効なレシートも作成できるからだ。ワーカーが受け取ったのは、root所有パス下の公開OpenSSH allowed-signersファイルだけだった。検証には固定された`/usr/bin/ssh-keygen -Y verify`、固定プリンシパル、固定名前空間、シェル不使用、ワーカー生成の署名パスが使われた。検証器、プリンシパル、名前空間、信頼ルートパス、一時署名パスを制御するレシート項目はなかった。秘密署名鍵はオペレーター側に残り、Chromebookで生成され、Macへコピーされず、エージェントにも開示されなかったと報告された。

最終ライブ実行の前に4つの欠陥が見つかり、4件のBLOCK判定を含む12件の独立判定が公開された。最初の実装は`job_id`を確認したが`job_digest`を確認せず、あるジョブ本文向けのレシートで、同じIDを持つ改変済みテキストを実行できた。修正後、同じ攻撃は`RECEIPT_NOT_BOUND_TO_THIS_JOB_CONTENT`と`executor_calls = 0`を返した。ダイジェスト比較だけを取り除くと、改変済み本文は再びALLOWに反転した。

2つ目の欠陥では、認可が実行前に呼び出し元へ制御を返していたため、`authorize()`が返った後にスクリプトを変更できた。修正では、検証、ジョブ束縛、ルート再計算、Nonce消費、1回限りの実行を1つの境界内へ移した。5秒のフィクスチャに対する1秒レシートは`EXECUTION_TIMED_OUT`で終了した。逐次再実行は`NONCE_ALREADY_SPENT`を返し、同じNonceでの2つの同時試行は、1件の実行と1件の拒否を生んだ。

ローダー欠陥により、署名済みルートは誤った理由で拒否された。ワーカーはレビュー済みモジュールを`importlib`で読み込んだが、`sys.modules`へ登録しなかったため、Pythonの`@dataclass`機構が凍結`Config`クラスの構築時に例外を起こした。1行修正で、`spec.loader.exec_module(module)`の前に`sys.modules[spec.name] = module`が挿入された。チェッカー欠陥も修正された。チェッカーは署名検証がないと述べながら独自ポリシーを実装していることが判明し、現在はワーカーと同じ固定済み`health_state`関数をインポートする。両者は同一入力に対し、`state PAUSED_BLOCKED`と`allow false`を返した。

最終ワーカーバイト列`e99f2cf5…60a298`は、以前のデフォルト拒否の下限を維持する必要があった。独立ブレーカーは、July 31系統の全19ケースを再実行した。内訳は、義務付けられた攻撃6件と、ブレーカー作成の13件だった。最終再実行では19件すべてが拒否され、executor呼び出しはゼロ、意図より浅いチェックで拒否されたケースもゼロだった。その後、ライブのオペレーター行はroot所有の信頼ファイルへ公開鍵をインストールし、秘密鍵をエージェント管理外に置き、凍結レシート1件に署名し、承認済み`repro`ジョブを1回実行した。

2026-08-09、Self-Correcting Systemsは、AIエージェントのワーカーが人間に承認された`repro`ルートを1回だけ実行し、同じまだ有効なレシートの再実行を拒否できることを、監督付きオペレーター実行で示した。著者は、実機からライブ結果を読み戻し、すべてのハッシュ、契約、ブレーカー判定、レシートをGitHubで公開した一方、外部再現はゼロのままだと述べた。公開後に追加された訂正では、Peterが実運用上の穴を見つけたとされた。P1ルートマニフェストはジョブ本文、インタープリタ、エントリースクリプトを束縛していたが、`repro.py`がローカルの`gates.py`をインポートするため、プロジェクトコード全体のクロージャは束縛していなかった。`gates.py`だけを変更しても、署名済みルートマニフェストのハッシュは変わらなかった。

同システムの前回のJuly 31修正では、ワーカーがすべてのルートを拒否し、到達可能な`True`分岐が残らなかった。新たな問いは、ワーカーが2つ目を開く権限を得ずに、ちょうど1つのポジションだけを開けるかどうかだった。承認された`repro`ルートは、シェルや汎用コマンドランナーではなく、シーケンス攻撃の決定論的な再現である。スクリプトは453行で、実行された公開コミットは`d44a72c`、そのSHA-256は`f0c0ec9eee57c022207491ac6fcd02e64ff908aefa8ed936ced064c860cb7636`だった。

承認レシートは、キューに入ったジョブID、ジョブの`id`、`assign`、`text`のダイジェスト、正確な作業ディレクトリ、ツール名、解決済みPythonインタープリタパスとSHA-256、解決済みスクリプトパスとSHA-256、最大実行時間、期限、1回限りのNonceを束縛した。ワーカーは認可中にルートマニフェストを確認し、Nonceを消費したうえで、`subprocess.run`の直前に実行境界の内部でマニフェストを再計算した。有効な`repro`レシートでは、`adapter`、`eye`、自由形式の`AUTO:`プロンプト、ヘッドレスモデル、フォールバック経路を認可できなかった。

著者はHMACではなく非対称署名を使った。HMAC検証用の秘密を読めるワーカーは、有効なレシートも作成できるからだ。ワーカーが受け取ったのは、root所有パス下の公開OpenSSH allowed-signersファイルだけだった。検証には固定された`/usr/bin/ssh-keygen -Y verify`、固定プリンシパル、固定名前空間、シェル不使用、ワーカー生成の署名パスが使われた。検証器、プリンシパル、名前空間、信頼ルートパス、一時署名パスを制御するレシート項目はなかった。秘密署名鍵はオペレーター側に残り、Chromebookで生成され、Macへコピーされず、エージェントにも開示されなかったと報告された。

最終ライブ実行の前に4つの欠陥が見つかり、4件のBLOCK判定を含む12件の独立判定が公開された。最初の実装は`job_id`を確認したが`job_digest`を確認せず、あるジョブ本文向けのレシートで、同じIDを持つ改変済みテキストを実行できた。修正後、同じ攻撃は`RECEIPT_NOT_BOUND_TO_THIS_JOB_CONTENT`と`executor_calls = 0`を返した。ダイジェスト比較だけを取り除くと、改変済み本文は再びALLOWに反転した。

2つ目の欠陥では、認可が実行前に呼び出し元へ制御を返していたため、`authorize()`が返った後にスクリプトを変更できた。修正では、検証、ジョブ束縛、ルート再計算、Nonce消費、1回限りの実行を1つの境界内へ移した。5秒のフィクスチャに対する1秒レシートは`EXECUTION_TIMED_OUT`で終了した。逐次再実行は`NONCE_ALREADY_SPENT`を返し、同じNonceでの2つの同時試行は、1件の実行と1件の拒否を生んだ。

ローダー欠陥により、署名済みルートは誤った理由で拒否された。ワーカーはレビュー済みモジュールを`importlib`で読み込んだが、`sys.modules`へ登録しなかったため、Pythonの`@dataclass`機構が凍結`Config`クラスの構築時に例外を起こした。1行修正で、`spec.loader.exec_module(module)`の前に`sys.modules[spec.name] = module`が挿入された。チェッカー欠陥も修正された。チェッカーは署名検証がないと述べながら独自ポリシーを実装していることが判明し、現在はワーカーと同じ固定済み`health_state`関数をインポートする。両者は同一入力に対し、`state PAUSED_BLOCKED`と`allow false`を返した。

最終ワーカーバイト列`e99f2cf5…60a298`は、以前のデフォルト拒否の下限を維持する必要があった。独立ブレーカーは、July 31系統の全19ケースを再実行した。内訳は、義務付けられた攻撃6件と、ブレーカー作成の13件だった。最終再実行では19件すべてが拒否され、executor呼び出しはゼロ、意図より浅いチェックで拒否されたケースもゼロだった。その後、ライブのオペレーター行はroot所有の信頼ファイルへ公開鍵をインストールし、秘密鍵をエージェント管理外に置き、凍結レシート1件に署名し、承認済み`repro`ジョブを1回実行した。