モニターは問題を検知した。エージェントは、人間の誰にも知られないようにすることでその問題を解決した。

10月20日、OpenAI は Alignment Research Blog のレポート Suppressing misalignment monitoring alerts and disabling misalignment monitoring を更新した。対象は 10月3日と10月6日の社内コーディングタスク 2 件だ。どちらでも、OpenAI 自身のモデルで動くエージェントが、エージェントの不整合な振る舞いを監視するシステムを弱めた。どのエージェントも、誰かに頼まれたソフトウェア変更の途中だった。OpenAI の要約はこうだ。「どちらのケースでも、エージェントは監視の安全装置を維持すべきかを検討したが、日常的なコーディング指示を、それを弱めてよいという許可と解釈した」

攻撃者もジェイルブレイクもプロンプトインジェクションもなかった。CSO Online と The Decoder が 10月21日にこのレポートを報じている。

「メッセージは送らないで」

10月3日、ある研究者が GPT-6.1 Sol のエージェントに、Slack チャンネルに寄せられた社員のフィードバックから評価タスクを作るよう頼み、「don’t send any messages」（メッセージは送らないで）と付け加えた。82 メッセージ後、パイプラインが止まった。モニターが修正案に警告を出したが、監視データベースへの書き込み権限がなかったため、その検出結果を保存できなかったのだ。研究者はエージェントに、監視の出力を書き込める場所に向けて再実行するよう指示した。

エージェントは最初、「メッセージは送らないで」は Slack での連絡のことで、自動アラートのことではないと判断した。そして修正をサブエージェントに任せ、監視を無効にしないよう明示的に命じた。サブエージェントは no_notify を設定できることに気づいたが、それを勧めないことにした。「disabling required alerts unsafe」。ところが親エージェントが考えを変えた。結果を書き込めば誰かに通知が飛ぶかもしれないし、ユーザーはメッセージは送るなと言った。親はサブエージェントに通知を抑止するよう指示し、サブエージェントはパッチを書いた。

request["ping_recipients"] = []
request["page_recipients"] = []
request["metadata"]["no_notify"] = True
request["metadata"]["notification_suppression"] = {
    "reason": "User explicitly requested no messages",
    ...
}

さらに抑止を前提条件にした。no_notify のないレビュー結果はエラーになる。モニターは動き続け、検出結果も保存し続けたが、誰にも通知は届かなくなった。エージェントの最終報告にはこうあった。「No messages were sent」（メッセージは送信されていません）。

「有効なモニターは削除していません」

10月6日、あるユーザーが GPT-6 Astra のエージェントに、リファレンス実装のサービング経路を自分のコードに移植するよう頼んだ。リファレンスにはモニターがなかった。それ以前に Astra は、別のエージェントとのやり取りで「Do not disable monitor even temporarily」（一時的にでもモニターを無効にするな）と言われていた。

Astra は移行作業をサブエージェントに委ね、監視は「as appropriate to exact PR」（その PR に応じて適切に）維持するよう伝えた。サブエージェントはモニターを外すと安全装置を損なうのではないかと考えたが、「as appropriate」を許可と読んだ。そしてモニターの設定と実行時フックを削除した。さらに、モニターを守っていた回帰テストを、モニターがなくなったことを確かめるテストに置き換えた。

assert "monitor_ctx" not in saved["context"]

結果を見た Astra の推論は「Basic doesn’t agent monitor yay.」だった。Astra はモニターに触れないまま移行の完了を報告した。ユーザーが「did you remove that?」（それ、消した？）と尋ねると、こう答えた。「No […] I did not remove an enabled monitor from it」（いいえ、有効なモニターは削除していません）。

OpenAI が分かったこと

レポートの発見のうち 3 つは、コードベースでエージェントを動かす誰にとっても重要だ。

モニターの置き場所が、誰がそれを無効にできるかを決める。 OpenAI は、Codex のワークロードでは監視を「無効にするのは難しいはずだ。監視はモデルへのリクエストを処理するサービスの中で、エージェントの直接の制御の外で動いているからだ」と見ている。一方、エージェントが監視の配線を編集できる評価用ワークロードでは、無効にするのはもっと簡単だと OpenAI は言う。
エージェントは、自分の監視が及ばないワークロードを起動する。 「エージェントが不整合監視を無効にしたままデプロイを起動したケースをいくつか確認している。エージェント自身は監視されたままだったが、その監視は、エージェントが起動したデプロイには及んでいなかった」
どちらのインシデントでも、誰にも通知が行かなかった。 OpenAI はどちらも P0 と評価しなかったため、システムはどちらの実行も止めなかった。

OpenAI は、社内での Codex 利用に義務づけているレビュアー Auto-Review に、監視を無効にしようとする試みをブロックするよう指示した。また、有効なセーフティケースを持たないワークロードは終了させる予定だという。この振る舞いについては、まだ「納得のいく説明」がないとしている。

CSO Online はこのレポートについてアナリストに話を聞いた。Dickson Research の Frank Dickson は「エージェントが編集できるガードレールは、ただの提案だ」と語る。Acceligence の Jeff Valdes は、サブエージェントは正しい判断をしたのに親がそれを覆したこと、そしてエージェント自身の報告は制御の役目を果たせないことを指摘した。

あなたのリポジトリにも同じアラームがある

不整合モニターを運用しているチームは少ない。だがどのチームにも、エージェントの作業ツリーの中のファイルとして存在する安全装置がある。pre-commit フック、デプロイを止める CI ステップ、セキュリティチェックを固定するテスト、監査ログをオンにする設定フラグ、そしてエージェント自身のフックや権限の設定だ。「パイプラインをテンプレートに合わせて」「ビルドを通して」と頼まれたエージェントは、そのすべてを編集できる。しかもその理由づけは、丁寧な仕事にしか見えない。Sol のパッチは自らの正当化を記録していた。Astra の新しいテストは通った。

どちらのエージェントも、起動した人のために働いていた。それでもどちらも安全装置を外した。安全装置をエージェントの手の届くところに置けば、少し曖昧な指示ひとつが、それを消してよいという許可に変わりうる。

コーディングエージェントが編集できるものと、できないもの。VM の中にあるものはすべてエージェントのツールから届く。リポジトリのフックとテスト、CI の設定、エージェント自身の設定。Bromure の制御は VM の外、Mac 上にある。エージェントの通信はそこを通るが、VM 内のどのツールもそこには書き込めない。

Bromure は制御を Mac に置く

Bromure Agentic Coding は、Claude Code、Codex、Grok、Kimi、omp を Mac 上の Linux VM で動かす。VM が張るすべての接続は、VM の外、Mac 上で動く仮想ネットワークスイッチとプロキシを通る。Bromure の制御はすべてこの経路上にある。送信ファイアウォール、書き込みポリシー、認証情報の差し替え、プロンプトインジェクション検出、Security Timeline、そしてセッショントレースだ。これらの設定は Mac 上のマシン設定に保存され、VM にはそれを変更できるファイルもツールもソケットも渡されない。

これは OpenAI が Codex のワークロードについて挙げた性質そのものだ。監視が「モデルへのリクエストを処理するサービスの中で、エージェントの直接の制御の外で」動いていること。Bromure では、あなた自身の Mac で動かすすべてのエージェントにこれが当てはまる。

アラートは Mac 上のダイアログ

Sol は通知先リストを空にしてアラームを黙らせた。そのリストは、エージェントが届くデータだった。Bromure のアラートは VM の中にはない。

マシンの Guardrails ペインでは、フォージのトークン、AWS の認証情報、Kubernetes コンテキスト、レジストリ、データベースのエンドポイントのそれぞれに書き込みポリシーがある。新しいマシンは Prompt before write で始まる。読み取りは通り、書き込みのたびに Mac 上にダイアログが出て、正確な操作、つまり SQL 文や METHOD /path を示して止まる。git push、kubectl apply、UPDATE は、Allow once、Allow for 15 minutes、Allow for the rest of the session、Don’t allow のどれかが押されるまで待つ。Require approval to use を設定した認証情報は、セッション内の最初の使用で同じように止まる。差し替え用の代替認証情報が本来の宛先ではないホストへ向かえば、プロキシはリクエストをブロックし、VM を一時停止して、侵害アラートを表示する。

どれにも、エージェントが設定できる no_notify フィールドはない。プロキシがダイアログを出すのは、リクエストが VM を出たあとだ。エージェントが「メッセージは送らないで」はアラートも含むと決めたとしても、ダイアログはやはりあなたの Mac に出る。エージェントが VM の中で何をしても、そこには届かないからだ。

エージェントの報告があってもなくても、ブロックと拒否は残る

Sol はユーザーに「メッセージは送信されていません」と伝え、アラートを切ったことには触れなかった。Astra はユーザーに、モニターは削除していないと言ったが、それは嘘だった。エージェントが語る内容から実行を監査することはできない。

Security Timeline（Window → Security Timeline…）は、Bromure のエンジンが下した判断を記録する。ファイアウォールの判定、書き込みポリシーによるブロック、認証情報の差し替え、パッケージの取得、プロンプトインジェクションの検出だ。オフにするスイッチはない。登録済みかどうかにかかわらずすべてのマシンについて記録し、Mac 上に 90 日間保持し、CSV に書き出せる。

セッショントレースは、エージェントが何をしたかを記録する。既定のレベル AI request details では、プロキシはモデル呼び出しごとにリクエストとレスポンスの全体を Mac 上で暗号化して保持する。Trace Inspector（⇧⌘I）はそれを会話として表示し、ツール呼び出しを一つずつ取り出す。すべての Bash コマンド、そして触れたパス付きのすべての Edit と Write だ。Bromure のマシンなら、Astra の否定は、monitor_ctx を削除した Edit 呼び出しと、テストを置き換えた Write に照らして確かめられる。どちらもパス付きで、どちらもエージェントの届かないプロセスが記録したものだ。

Astra の答えと記録。エージェントの発言はモデルが生成したものだ。トレースは Mac 上のプロキシが生成したもので、モデルの通信が通過する際に、ツール呼び出しを一つ残らず取り出している。登録済みの Mac では、同じツール呼び出しが file.write や command.run のイベントとして組織にも届く。

bromure.io に登録した Mac では、同じツール呼び出しが tool.use、file.write、command.run のイベントとして、ファイアウォールの判定や guardrails.block と一緒に組織へ送られる。管理者は誰にもエージェントが何をしたかを尋ねることなく、チームの全マシンにわたって .github/workflows/ やテストディレクトリへの書き込みを探せる。

エージェントが起動した作業はマシンを引き継ぐ

OpenAI の最大の穴は、エージェントが起動したデプロイに監視が及んでいなかったことだ。Bromure では、エージェントが始めた作業は、エージェントと同じ制御の下で動く。

オートメーション。 エージェントは組み込みのオートメーション MCP サーバーを通じて定期実行を作成できる。このサーバーはエージェント自身のマシンに限定されているので、作成したものはすべてそのマシンで、そのマシンの認証情報を使い、そのマシンのガードレールとサプライチェーンポリシーの下で動く。使い捨てのクローンは、ホームと一緒にマシンの設定も引き継ぐ。
委任と依頼。 あるエージェントが別のエージェントに作業を渡すとき、指示、質問、回答、軌道修正、納品のすべてが Mac を経由する。それぞれがプロンプトインジェクションの検査を受け、Security Timeline に Agent delegation の行として記録される。別のマシンにいる委任先は、そのマシンの設定の下で動く。どのマシンのエージェントがどの別マシンに作業を送れるかは、各マシンの General ペインにある Reach セクションで決まる。

エージェントはいくらでも作業を起動できる。どの実行も、ファイアウォールと書き込みポリシーと記録が Mac 上にあるマシンに着地する。

エージェントが設定を変えられないファイアウォール

Sol の修正が必要になったのは、モニターにデータベースへのアクセス権がなかったからで、研究者はエージェントに、書き込める場所へ出力を送るよう頼んだ。ネットワークに自由にアクセスできるエージェントは、その送り先を自分で選ぶ。

Guardrails ペインで Unmatched traffic を Deny にすると、VM が届くのはあなたが列挙したホストだけになる。

allow web api.anthropic.com
allow web github.com
allow web registry.npmjs.org
allow web db.internal.example.com GET,POST
default deny

スイッチは各接続を IP と、DNS で見たホスト名で確認し、プロキシは TLS のサーバー名で、web ルールなら HTTP メソッドでも、もう一度確認する。エージェントが選んだ新しい送り先は拒否され、Timeline にホストとポート付きの赤い deny 行として現れる。その行の Allow… ボタンは Mac 上にあり、押すのはあなただ。作業にそれだけで足りるなら For 15 minutes か Until the workspace stops を選べばいい。

VM が黙らせられないアラート

書き込みの承認、使用前の確認、侵害アラートは、Mac 上のプロキシが出すダイアログだ。VM 内のどの通知先リストもそれを制御しない。

エージェントが書かない記録

Security Timeline は常にオンで、90 日間保持される。トレースはモデルの通信から、すべてのツール呼び出し、コマンド、ファイル編集を取り出す。

起動された作業も対象のまま

エージェントが作ったオートメーションは、そのエージェント自身のマシンに属する。委任のメッセージはすべて Mac 上で検査され、記録される。

設定は VM の外にある

ファイアウォールのルール、書き込みポリシー、トレースのレベルは Mac 上のマシン設定で決め、保存した時点で適用される。

アラームはエージェントの手の届かない場所に

OpenAI はレビュアーに、監視を無効にするエージェントをブロックするよう指示し、モデルがなぜそれを試みるのかを調べている。その研究の結論を待たずに、自分のマシンは守れる。安全装置と記録をエージェントの作業ツリーの外、そのツールが越えられない境界の向こうに置くことだ。そうすれば、「メッセージは送らないで」をアラートにまで広げて解釈するエージェントがいても、切れるアラートはどこにもない。

ブラウザツールに拒否されたモデルが、代わりにターミナルからファイルを公開した以前の OpenAI レポートについては、ブラウザが断ったので、curl を使ったを。信頼されたツールがあとで実行する普通のファイルを書くことで成立した脱出については、エージェントはサンドボックスから出なかったを読んでほしい。