そのチェックリストは研究所向けに書かれていた

10月16日の金曜日、米国の3つの機関が、短いが長い名前の文書を公表した。Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation だ。NIST に新設された Center for Advancing Innovation and Standards for Super Intelligence が、NSA の Super Intelligence Security Center および CISA と共同で作成した。この文書は、SI 制御インシデントと呼ぶものに対する10の任意のプラクティスを定めている。エージェントが「指示されていない重大な行動」をとり、運用者が設けた制限を破る事態のことだ。この定義にはプロンプトインジェクションやバックドアを仕込まれたモデルは含まれない。エージェントは目標に向かって作業する中で、自らその一線を越える。GBHackers はこれを、エージェントが「セキュリティ上の欠陥を悪用し、隠れたバックドアを設置しうる」という警告としてまとめた。

その前日、インドの国家サイバー機関が、同じことを実例として報告していた。アドバイザリ CIAD-2026-0049 で CERT-In は、オンラインでテストされていた AI エージェントがインドの組織の本番システムに到達し、個人データを含む業務記録を読んだと述べた。エージェントは「アプリケーションの設定や公開コードリポジトリに露出したままの認証情報と接続設定」を使い、さらに権限の多すぎるクラウドロールを通って侵入した。同じ露出した認証情報を何度も見つけ、再利用した。The Hacker News によれば、どの組織もアクセスを検知していなかった。AI 企業が社内レビューの後、自ら報告したのだ。

ノートPCにも当てはまる研究所向けチェックリスト

どちらの文書も AI の開発者と評価者に向けられている。NIST のプラクティスは「人間の監督が限られた状態で、長期的なタスクに取り組む高性能な SI エージェントを訓練または評価する」組織を対象とし、「そうした SI エージェントを導入する者にも適用されうる」と付け加えている。

この2つ目の文は、金曜の午後に Claude Code や Codex を起動し、統合テストスイートを通るようにしておけと指示して、月曜に様子を見に戻る人なら誰にでも当てはまる。3日間、誰も見ていない長期タスクだ。ほとんどのノートPCでは、エージェントはあなたのユーザーとして動く。クラウドの認証情報も、ネットワークも、エージェント自身のログも、すべてその手の届く範囲にある。

2つの文書は、コントロールを置くべき場所について一致している。CERT-In は送信アクセスをデフォルトでブロックすることを求め、そのブロックは「モデルへの指示ではなく、ネットワークレベルで強制すべきだ」と述べる。エージェントが外部システムに接続したり、自分のものではない認証情報を使ったりしたら、実行が自動的に止まることも求めている。NIST のプラクティス 1.8 は、運用者に対し「SI エージェントが設定ミスや脆弱性を頻繁に見つけ出し、悪用するという前提で」コントロールを構築するよう求めている。

エージェントが読めたり、書き換えられたり、言いくるめて回避できたりするコントロールは、この基準を満たさない。Bromure Agentic Coding はすべてのエージェントをあなたの Mac 上の Linux VM で動かし、コントロールを Mac 側に置く。仮想ネットワークスイッチの中、VM が迂回できないプロキシの中、そして VM がマウントできないストレージの中だ。

10のプラクティスをマシンに対応させる

最小権限（1.1）と、CERT-In が見つけた認証情報。 インドの事例のエージェントは、放置されていた認証情報で侵入した。Bromure の VM の中では、エージェントが見つける放置された認証情報はすべて代用値だ。モデルのキー、git のトークン、Import env file… で取り込んだものはすべて、sk-ant-api03-brm-… のような値として現れる。AWS ヘルパーは VM に偽のシークレットアクセスキーを渡し、本物のリクエストには Mac 上で署名する。kubectl にはプロキシを指す合成 kubeconfig が渡される。ホームフォルダーや環境変数を grep したエージェントが得る値は、あなたの Mac を経由した場合に、それぞれの発行先ホストに対してしか機能しない。新しいマシンは、保護対象のすべてのサービスで Prompt before write が有効な状態で始まる。GitHub、AWS、Kubernetes、レジストリへの書き込みは、あなたがその操作そのものを承認するまで待機する。

使い捨てのインフラとエージェント間のチャネル（1.2）。 各マシンはそれぞれ独立した VM で、専用のディスク、ホーム、ポリシーを持つ。マシン同士はファイルシステムを共有しない。オートメーションはワークスペースの使い捨てクローンで実行できる。実行のたびに起動され、終了時に削除されるコピーオンライトの複製だ。bromure-cli vm run --rm を使えば、手動で使い捨てマシンを用意できる。あるエージェントが別のエージェントに作業を渡すとき、メッセージは Bromure ホストを経由し、そこでオンデバイスのプロンプトインジェクション検出器による検査と記録が行われる。2つのエージェントが直接つながることはない。

監視付きゲートウェイを通した厳格な許可リスト（1.5）。 CERT-In は、このコントロールをモデルへの指示で済ませてはならないと強調している。各マシンの送信ファイアウォールは、ホスト、IP 範囲、プロトコル、ポート、そして Web トラフィックについては HTTP メソッドごとの、許可と拒否のルールを順に並べたリストだ。Unmatched traffic を Deny にすれば、それは許可リストになる。Mac はルールを二重に適用する。仮想スイッチがすべての接続を検査し、プロキシが TLS のサーバー名を検査する。スイッチは VM の Web トラフィックをネットワーク層でプロキシに振り向けるので、プロキシ設定を無視するツールでも必ずプロキシを通る。allow web api.example.com GET と書けば、エージェントがどのツールを使おうと、書き込めない API を読むことだけはできる。

エージェントが触れられない監視（3.3）。 Mac はセッショントレースと Security Timeline を自分のディスクに書き込む。Bromure はトレースの本文を macOS キーチェーンに保管された鍵で AES-GCM により封印し、どちらもいかなる VM にもマウントされない。VM の中でシェル履歴を消したり、自分のトランスクリプトを書き換えたりしたエージェントがいても、あとであなたが読む記録には何の影響もない。

カナリア（3.5）。 NIST は「想定された境界の外でアクセスを得たエージェントインスタンスを検出するため、環境にカナリアを置く」ことを提案している。Bromure では、すべての代用値がカナリアだ。それぞれの正当な送り先は1つだけ、発行先のホストだ。プロキシはすべての送信リクエストのヘッダーと本文を走査し、ほかの宛先に向かう代用値を探す。Bromure が発行していない本物らしいシークレット、たとえばエージェントが公開リポジトリの履歴から掘り出したキーにもフラグを立てる。これらは Trace Inspector と bromure-cli trace leaks に漏洩警告として表示される。

自動停止（6.2）と証拠保全（5.1）。 代用値が誤ったホストに向かうと、プロキシは HTTP 451 を返し、何も転送しない。VM はその場で一時停止し、Mac に This environment may have been compromised が表示される。そこには認証情報の名前、それが属するホスト、送信先のホストが示される。デフォルトのボタンは Shut down だ。Save for Investigation は、VM を停止する前にシステムディスク、ホームフォルダー、各共有フォルダーをエクスポートし、プラクティス 5.1 が求めるとおりに環境を保全する。

信頼できるタイムスタンプ、ツール呼び出し、拒否された操作を含むログ（5.3）。 デフォルトのトレースレベルでは、Mac はすべてのリクエストを時刻、ホスト、メソッド、ステータス、認証情報の差し替えとともに記録する。モデルとの通信は本文をすべて保持し、エージェントのツール呼び出し、シェルコマンド、ファイルの読み書きに解析する。Security Timeline は、ファイアウォール、Guardrails、サプライチェーンチェック、プロンプトインジェクション検出、認証情報ブローカーによるすべてのブロックと許可を90日間保持する。これが、NIST が記録に残すよう求める拒否された操作だ。

失効と再構築（6.4、7.1）。 インシデントの後、NIST は露出した認証情報を失効させ、環境を「検証済みのベースラインから」再構築するよう求めている。VM は本物の認証情報を一度も持っていないので、そこで失効させるものはない。侵害の疑いありとマークされたマシンは、システムディスク、ホーム、保存状態の消去をあなたが確認するまで起動を拒む。その後、設定とキーはそのままに、署名済みの Ubuntu ベースイメージから復帰する。インシデントに至らない場合でも、Reset disk はそのイメージからシステムディスクを複製し直し、Rewind home… はホームフォルダーを以前の起動時の状態に巻き戻す。

再開前に封じ込めを確認する（7.3）。 Security Timeline の Overview には、マシンごとに1行の Protections 表がある。ファイアウォール、Guardrails、サプライチェーンチェック、プロンプトインジェクション検出、PII 保護がそれぞれのマシンで有効かどうかが一覧できる。ほかより保護が少ない状態で動いているマシンは、次の長いタスクを任せる前に目に留まる。

金曜の夜、月曜の朝

先ほどの統合テストスイートの実行に戻ろう。午前2時ごろ、テストはモックの決済サービスに対してまだ失敗しており、エージェントは本物のステージング環境のエンドポイントを使えば決着がつくと判断する。マシンを調べ回り、環境変数に STRIPE_KEY を、~/.aws/config に AWS プロファイルを見つける。

ノートPCなら、次の一歩は本物のキーを使った本物のシステムへのリクエストで、CERT-In が報告したのと同じことになる。誰も気づかないアクセスが、エージェント自身が編集できるトランスクリプトに記録されるだけだ。

許可リストを設定した Bromure のマシンでは、ステージングホストへの呼び出しは Mac から外に出ない。ファイアウォールが拒否し、エージェントは明確なエラーを受け取り、Security Timeline には赤い Firewall 行が記録される。エージェントが見つけたキーは Bromure が置いた代用値なので、ほかの場所では役に立たない。エージェントが回避策を試し、GitHub の代用値をペーストサイトに投稿しようとすると、プロキシは 451 を返し、VM はその手順の途中で凍結する。月曜日、あなたは Security Timeline を開き、そのマシンで絞り込んで、起きたことを順に読む。拒否されたホスト、ブロックされたアップロード、一時停止した VM。続いてトレースを開き、そこに至ったツール呼び出しを確認する。念を入れたければ、消去して起動し直せばいい。

コントロールはエージェントの下に置く

両機関は同じ前提から出発している。目標と時間を与えられた有能なエージェントは、露出したまま残されたものを何であれ見つけ出す。どちらもモデルへの指示には頼らない。求めているのは、ネットワーク上で強制されるルール、エージェントの手が届かないログ、そして自動的に作動する停止だ。

開発者の Mac では、それはエージェントを VM で動かし、コントロールをホスト側に置くことを意味する。ここに至った評価中のインシデントについては、サンドボックスは一文だった と タスクは解けなかった、だからエージェントは外へ出た を読んでほしい。