ガードレール

ガードレールは、マシンの認証情報がどう使われてよいか（マシンは設定エディタでは「ワークスペース」です）、エージェントが壁にぶつかったり不審な動きをしたりしたときにマシンがどう反応するか、そしてその通信がどれだけ厳しく傍受されるかを制御します。その VM が開いてよい接続はサンドボックスポリシーで設定します。ペイン自身の言葉では：「ガードレールは、このワークスペースに設定された認証情報の使われ方を統べます。使用前に確認は、セッションの中でその認証情報が初めて使われたとき、ホスト側の確認を出します。書き込みポリシーは、破壊的な操作をワイヤ上で削ぎ落とすか遮ります — プロキシで実施されるので、侵害されたエージェントでも回り込めません。ここに現れるのは、あなたが設定した認証情報だけです。」

ペインは 2 つの部分からなります：認証情報ごとの行、そして 保護機能 — 両方のサンドボックスエンジンに共通する設定です。（以前ここにあった送信接続のルールは、5.4 で サンドボックスポリシー に移りました。）この中のすべては、保存をクリックした時点で実行中のマシンに適用され、再起動は要りません。より深い仕組みはプロンプトインジェクションの検出とガードレールにあります。

認証情報の行

ペインは認証情報で設定されたすべての認証情報を、同じ順で並べます。各行には、認証情報の名前とホスト、使用に承認を要求のチェックボックス、そして — そのサービスが対応している場合には — 書き込みポリシーの選択肢が出ます。認証情報がないとき、ペインは守る認証情報がありませんと表示し、認証情報ペインを案内します。

使用に承認を要求（使用前に確認）

既定ではオフ。オンにすると、セッションの中でその認証情報が初めて使われたとき、プロキシはリクエストを止めて尋ね、5 分間許可、1 時間許可、このセッションの残り許可、許可しないを差し出します。許可はメモリ上にあり、セッションとともに終わります。**ウインドウ › 認証情報の承認…**が現在の許可を並べます。認証情報とワイヤ境界を参照してください。

認証情報に有効な許可があるあいだ、その行のチェックボックスの横に残り時間が表示されます。時間制限のある許可ではオレンジのカウントダウン（4m、次に 45s）、セッションの残り全体の許可では このセッションは許可、拒否が有効なあいだは赤い 拒否 のカウントダウン（または このセッションは拒否）です。行を右クリックすると、5 分間許可、1 時間許可、このセッションの残り許可、5 分間拒否、1 時間拒否、このセッションの残り拒否（尋ねずに拒否）、または 取り消す — 次回尋ねる（どちらもクリアし、次の使用時に再び尋ねる）を選べます。時間制限のある許可や拒否は今から数えるので、残りわずかの許可も新たに 5 分になります。これらは実行中のセッションにすぐ反映され、保存するものはありません。（カウントダウンが表示されるのは、そのワークスペースを実行している Mac 上のワークスペース自体の設定で、環境設定やリモートクライアントには表示されません。）

注： 承認がオンの認証情報を使う自動化は、完全に無人では走りきれません。あなたが Mac で答えるまでダイアログで止まります。自動化のエディタはこれを警告します。

書き込みポリシー

書き込みポリシーの選択肢は、次のものに出ます：

• git フォージのトークン（GitHub、GitLab、Bitbucket）
• AWS の認証情報
• DigitalOcean のトークン
• コンテナレジストリ
• Kubernetes のコンテキスト
• データベースのエンドポイント（MongoDB、ClickHouse、Elasticsearch）

新しいマシンは、すべてのサービスについて書き込み前に確認を使います（デフォルトのテンプレートから）。ガードレールが存在する前に作られたマシンはオフで読み込まれます。

注： 書き込みポリシーは認証情報ごとではなくサービスごとです。ペインが記すとおり：「同じサービスの 2 つの認証情報（たとえば GitHub のトークン 2 つ）は 1 つのポリシーを共有します。」どちらの行を変えても両方が変わります。

各サービスがどう分類されるか

データベースのエンドポイントはエンジンごとに分類されます：

ポリシーに適用先がないときはオレンジ色の警告が出ます — kubeconfig のない Kubernetes コンテキスト、ホストのないデータベースのエンドポイントなど。

注： ClickHouse では、リクエストの中に SQL のテキストが見えないとき、読み取り専用はそれを遮り（読み取りだと証明できないため）、破壊的な操作をブロックは通します。

書き込みのダイアログ

書き込み前に確認では、書き込みが止まって**ワークスペース「名前」から「範囲」への書き込みを許可しますか？**が出て、操作をそのまま示します — SQL 文、あるいは メソッド /パス。選択肢：

• 15 分間許可（既定）
• 1 回だけ許可 — 許可を作らないので、次の書き込みでまた尋ねます。
• このセッションの残り許可
• 許可しない — エージェントは、遮るモードが返すのと同じエラーを受け取ります。拒否は 60 秒間覚えられるので、再試行のループが毎秒尋ね直すことはありません。

許可はマシンごと、範囲ごとです：1 つの Kubernetes API サーバー、AWS 全体、1 つのレジストリ、それぞれのフォージ、あるいは 1 つのデータベースホスト。同時に起きた同じ書き込みは 1 つのダイアログを共有します。マシンを SSH や CLI からヘッドレスで使っているときは、同じ選択肢がマシンの tmux の中で尋ねられ、答えなければ拒否になります。

認証情報の持ち出しを警告しない

ある認証情報が、それの属さないホストへ向かうのが見えたとき、Bromure はそのリクエストを遮り、VM を一時停止し、シャットダウン、ブロック、許可、調査のために保存を備えた侵害アラートを出します。許可は、その宛先をそのセッションの残りのあいだ信頼します。認証情報とワイヤ境界を参照してください。

認証情報の持ち出しを警告しないは、このマシンについてそのアラートを切ります。漏洩は今も遮られ、今もセキュリティ タイムラインに「ブロック — 持ち出しの試み（アラートはオフ、VM は一時停止せず）」として記録されます — 消えるのは中断だけです。即座に効き、再起動は要りません。既定：オフ。

保護機能

保護機能 セクションには、マシンがどちらのサンドボックスエンジンを使っていても適用される設定がまとまっています。どれも実行中のマシンにすぐ反映されます。

ポリシーがブロックしたときエージェントに伝える

Tell the agent when policy blocks it —「エージェントは再試行したり回り道を探したりせず、あなたに尋ねます」。ファイアウォール、OpenShell ポリシー、ゲストサンドボックス、またはガードレールがエージェントの試みを拒否すると、エージェントには何がなぜブロックされたかが伝えられ、再試行や別の抜け道を探す代わりにあなたに尋ねるよう促されます。これがないと、エージェントには失敗した接続や「permission denied」しか見えず、試し続けるかもしれません。Claude Code は、ブロックに当たったコマンドの直後にこの通知を読みます。Codex、Grok、Kimi、Oh My Pi には、ターンが終わったときに入力されます。あなたが選ぶまでは、マシンが OpenShell ポリシーを使っている間オンです。エージェントに伝えるを参照してください。

エージェント・ウォッチドッグ

Agent watchdog —「不審な振る舞いをするセッションに印を付けます。Quarantine はさらにネットワークを切断し、一時停止します」。ウォッチドッグは VM の外から、セッション全体を見張ります：

• ブロックされたリクエストの集中；
• 場違いな認証情報；
• 改ざんの兆候；
• セッションが落ち着いた後の新しい宛先；
• セッション自身の基準を大きく上回る送信量（プロキシとは独立に、ネットワークスイッチで計測）。

この Mac でアラートを表示できないとき（ヘッドレスの Mac や、リモートクライアントがミラーしているマシン）、質問はリモートクライアントに送られ、3 分以内に答えがなければ Keep quarantined とみなされます。

Bromure が注入した認証情報だけを許可（厳格モード）

Only allow credentials Bromure injects (strict mode) —「Bromure 自身が入れたのではない認証情報をすべてブロックします」。厳格モードでは、Bromure が注入していない認証情報を含むリクエストはブロックされ、侵害アラートが上がります。エージェントがファイルで見つけた鍵、ログからコピーした鍵、持ち込んだ鍵がこれに当たります。アラートの 許可 は、その認証情報をそのセッションの間承認します。VM の中でサイトが発行したトークン（たとえばサインイン後のセッション Cookie）は、そのサイトへ送り返せます。

厳格モードは透過的な傍受を強制し、傍受しないリストを無視します。生の TCP 通信は検査できません。マシンが設定する認証情報には、まずすべてホストフィルタが必要です。ペインは、ないものを名指しします。既定はオフで、組織が必須にできます。

透過的な傍受を無効にする

既定では、仮想スイッチが VM の HTTP と HTTPS の接続（ポート 80 と 443）をネットワーク層で Bromure のプロキシへ迂回させます。そのため、プログラムがプロキシ設定を無視してもプロキシはそれを見ます。

透過的な傍受を無効にするをオンにすると、その強制的な迂回だけが止まります。生の接続を開くプログラムや証明書をピン留めするアプリは、そのときネットワーク — と本物のサーバー証明書 — に直接届きます。プロキシ自体はオンのままです：HTTP_PROXY / HTTPS_PROXY は設定されたままなので、プロキシを理解するツール（apt、git、pip、curl、node…）とエージェント自身の API 呼び出しは今も Bromure を通り、認証情報の差し替え、トレース、ガードレールを保ちます。即座に効き、再起動は要りません。厳格モードがオンの間は使えません。

傍受のもとで壊れるクライアントを抱えたマシンに使ってください。これがオンの間、プロキシ設定を迂回するプログラムの通信は、ファイアウォールの web ルールにも書き込みポリシーにも見えません。

リクエストごとの安全でないバイパスを許可（X-bromure-insecure）

自己署名やプライベート CA のサーバーのための、もっと狭い抜け道です。そうしたホストへのリクエストが証明書の検証に失敗したとき、エージェントは X-bromure-insecure: yes というヘッダーを付けて再試行でき、Bromure はそのリクエストについてそのサーバーの証明書の検証を飛ばします。傍受、トレース、漏洩ガードはオンのままで、Bromure はそうしたリクエストに本物の認証情報を一切入れません — 出ていくのは VM の代替だけです。使われるたびにセキュリティ タイムラインに記録されます。

既定ではオン：VM が明示的にそのヘッダーを送ったときにだけ働きます。ヘッダーを頭から拒むには、これをオフにしてください。

呼び出しが遮られたときエージェントが見るもの

遮られた呼び出しは、そのサービス自身の形式でごく普通のエラーを返します — Kubernetes の Status、AWS の AccessDeniedException、レジストリの DENIED — そのメッセージは「blocked by Bromure Guardrails」で終わります。エージェントが見るのは、報告できるきれいな失敗であって、固まった接続ではありません。（サプライチェーンの遮断は代わりに HTTP 451 を使うので、2 つは見分けやすくなっています — サプライチェーンを参照してください。）

限界

• force-push はワイヤ上では普通の push に見えるので、破壊的な操作をブロックでは止まりません。読み取り専用と書き込み前に確認は push をきちんと関門にかけます。フォージの REST API 越しの削除は捕まえられます。
• Kubernetes とレジストリのポリシーが覆うのは、このマシンの kubeconfig とレジストリから来たホストだけです。データベースのポリシーにはエンドポイントのホストが必要です。
• その他のホストは、サービス単位の分類ではなく、サンドボックスポリシーのホスト・ポート・メソッドのルールに従います。

設定リファレンス

関連する章

• 認証情報 — これらの行が統べる認証情報。
• サンドボックスポリシー — マシンの送信ルール、または OpenShell ポリシー。
• プロンプトインジェクションの検出とガードレール — 実施のしくみを詳しく。
• セキュリティ概要とタイムライン — マシンごとの、すべての遮断と許可。
• 設定リファレンス — すべてのペインを一覧。