ガードレール

ガードレールは、ワークスペースの認証情報がどのように使用されるかをホスト側で制御する Bromure Agentic Coding の機能です。ペイン自体が示すとおり、ガードレールはこのワークスペースに設定された認証情報の使われ方を管理します。使用前に確認を有効にすると、セッションで認証情報が初めて使用されるときにホスト側の確認が表示されます。書き込みポリシーはワイヤ上で破壊的な操作を取り除くかブロックします。これはプロキシで強制されるため、VM 内の侵害されたエージェントがこれを回避することはできません。ここには、あなたが設定した認証情報のみが表示されます。

このペインには、認証情報ペインで一覧される順序と同じ順で、設定された認証情報ごとに1行が表示されます。各行には認証情報のタイトルとホストが表示され、2つのコントロールを備えています。

• 使用前に確認チェックボックス（コントロール自体には使用に承認を要求と表示）— 認証情報ごとの同意ゲートで、認証情報ペインからここに移動しました。
• インラインの書き込みポリシー選択。認証情報のサービスが対応している場合にのみ表示されます。

ワークスペースに認証情報がない場合、ペインは空の状態 — 保護する認証情報がありません — を表示し、認証情報ペインへ案内します。強制の詳細、エラー形式、監査証跡についてはプロンプトインジェクションとガードレールの詳細解説で説明します。

使用前に確認

各行には使用前に確認チェックボックスがあり、デフォルトではオフです。オンのとき、セッションでその認証情報が初めて使用されると、プロキシは一時停止し、時間制限付きの許可 — 5分間、1時間、またはセッションの残り時間 — もしくは許可しないを提示する同意ダイアログを表示します。許可はメモリ上にのみ存在し、セッションウィンドウが閉じると消去されます。すべての有効な決定は**ウィンドウ → 認証情報の承認…**に一覧されます。同意モデル、同時プロンプトの統合、承認ウィンドウについては認証情報とワイヤ境界で説明します。

このチェックボックスは、プレーンな API キー、SSH キー、手動トークンを含むあらゆる認証情報に適用されます。書き込みポリシーを持たない行にはこのコントロールのみが表示されます。

書き込みポリシー

認証情報のサービスが自身のトラフィックを分類できる場合、その行には書き込みポリシー選択も表示されます。これは次の場合に表示されます。

• Git フォージ — GitHub、GitLab、Bitbucket のトークン。
• AWS の認証情報。
• DigitalOcean のトークン。
• コンテナレジストリ（Docker Hub、ghcr.io など）。
• Kubernetes のコンテキスト。
• データベースのエンドポイント（MongoDB、ClickHouse、Elasticsearch）。

すべての書き込みポリシーは同じ4つのモードを提供します。

新しいワークスペースでは、ポリシーに対応するすべてのサービスで（設定テンプレートを通じて）書き込み前に確認がデフォルトになります。ガードレールが存在する前に作成されたワークスペース — または JSON にこのフィールドを含まないプロファイル — はオフとしてデコードされます。

メモ: 書き込みポリシーは認証情報ごとではなく、サービスごとです。同じサービスに対する2つの認証情報 — たとえば2つの GitHub トークン — は1つのポリシーを共有するため、どちらかの行で選択を変更すると両方に反映されます。

メモ: ガードレールは操作を分類しますが、認証情報を隠すわけではありません。認証情報自体は認証情報で設定したとおり、プロキシによって注入・差し替えされます。多層防御のために、読み取り専用の書き込みポリシーと同じ行の使用前に確認チェックボックスを組み合わせてください。

各サービスによる呼び出しの分類方法

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

ポリシーが設定されていても適用対象がない場合 — Kubernetes コンテキストに kubeconfig がない、データベースエンドポイントにホストが設定されていない — には、オレンジ色のインライン警告が表示されます。ガードには適用するホストがないためです。

メモ: ClickHouse では、リクエストに SQL テキストが見えない場合、読み取り専用はリクエストをブロックし（Bromure はそれが読み取りであることを証明できないため）、破壊的操作をブロックは通過させます（オープン側に倒れます）。

同意ダイアログ（書き込み前に確認）

書き込み前に確認モードでは、読み取りは静かに通過し、すべての書き込みは Allow write on "<scope>" from workspace "<name>"? というタイトルのホストダイアログのために一時停止します。ダイアログ本文には正確な操作がそのまま表示されます — データベースであればリテラルな SQL 文、REST 呼び出しであれば METHOD /path — そのため、要約ではなく実際に実行される内容を承認できます。ボタンは次のとおりです。

• 15分間許可（デフォルトのボタン）
• 1回だけ許可 — 意図的に許可を作成しないため、次の書き込みで再び確認されます。おしゃべりなエージェントを書き込みごとに監査するのに便利です。
• セッションの残り時間許可
• 許可しない — エージェントはブロックモードが生成するのと同じハードエラーを受け取ります。拒否は60秒間記憶されるため、同じ書き込みをループで再試行するエージェントが毎秒再確認されることはありません。

許可はワークスペースごと、プロトコルスコープごとにスコープされます。1つの Kubernetes API ホスト、AWS 全体、1つのコンテナレジストリ、各 git フォージ全体、または1つのデータベースホストです。あるホストで ClickHouse の書き込みを許可しても、他のどこにも許可は付与されません。同時の同一書き込みは1つのダイアログに統合され、すべての決定はメモリ上にのみ存在します。セッションスコープの許可はセッションの終了時に消去されます。

ワークスペースが SSH または CLI 経由でヘッドレスに駆動される場合、同じ4つの選択肢がワークスペースの tmux 内のテキストプロンプトとして提示されます。応答がない場合は拒否されます。

メモ: ガードレールの書き込み許可はどのウィンドウにも一覧されません。認証情報の承認ウィンドウ（ウィンドウメニュー → 認証情報の承認…）には、認証情報の同意決定 — 使用前に確認の許可 — のみが表示されます。書き込みポリシーの許可は独自のタイマーまたはセッションの終了時に期限切れとなります。

エグレスファイアウォール

認証情報の行の下に、ペインはワークスペースの 送信接続 ファイアウォールを備えています。これは、VM がそもそもどの接続を開いてよいかを管理する順序付きのルールテーブルであり、対象はガードレールが分類するサービスだけでなく、あらゆるプロトコル、あらゆる宛先です。ルールは上から下へ照合され、最初に一致したものが適用されます。セグメント化された 未一致トラフィック コントロールは、どのルールにも一致しないものの既定動作を選びます。許可（新しいワークスペースの既定）か、あるいはロックダウンした許可リスト方式にするための 拒否 です。

各ルールは 5 つの部分から成ります。

一番下の開閉パネルには、同じルールセットが正規の pf 形式 で表示されます。1 行 1 ルールで、末尾は default allow または default deny です。これがルールの保存形式であり、CLI と管理プロファイルが運ぶ形式でもあります。

allow tcp api.github.com:443
allow web api.example.com GET,POST     # これらのメソッドだけがサイトに到達する
deny  web api.internal PUT,DELETE      # これらのメソッドをブロックし、それ以外は許可
deny  udp any:53
deny  any 10.0.0.0/8
default deny

強制はホスト側で階層的に行われるため、侵害されたエージェントもこれを迂回できません。仮想ネットワークスイッチは、宛先 IP と DNS スヌーピングで得たホスト名によって、すべてのフロー（平文の TCP と UDP を含むすべてのプロトコル）にルールを適用します。さらに MITM プロキシが、TLS のサーバー名によって、そして web ルールについては個々の HTTP メソッドによって、再度ルールを適用します。このメソッドという次元こそが、書き込みを許可されていない API をワークスペースが読み取ることを可能にします。allow web api.example.com GET,POST は、VM 内のどのツールがリクエストを発行するかに関わらず、ワイヤ上でエージェントに変更を伴わない問い合わせだけを許可します。

ルールの編集は 実行中のセッションに即座に適用されます。ワークスペースを保存すると、ヘッドレスセッションを含め、再起動なしでライブポリシーが更新されます。各判定は セキュリティタイムライン ウィンドウの Firewall 行として記録され、登録済みのインストールでは組織のストリームに egress.firewall イベントとして記録されます。

メモ: ローカル推論は構造上、対象外です。ホスト上の推論エンドポイント（bromure.llm）に対する allow ルールがあなたのルールより前に挿入されるため、default deny であってもエージェントがローカルモデルから切り離されることはありません。このトラフィックがあなたの Mac を離れることはありません。

透過的インターセプト

VM が単にプロキシを無視できてしまえば、ファイアウォールは助言的なものにすぎなくなります。そこで、もはやそれはできません。仮想スイッチは VM のポート 80 とポート 443 のフローをホストプロキシへ透過的に転送します。環境変数は不要で、ゲスト側で解除できるものは何もありません。ポート 80 の平文 HTTP も、HTTPS と同じようにインターセプトされ検査されます。これはすべてのワークスペースで既定で有効です。

抜け道は、ルールテーブルの下にある 透過的インターセプトを無効化 トグルです。これをオンにするとスイッチは :80/:443 を転送しなくなり、ガードレールとファイアウォールの web ルールは、プロキシ環境変数を自発的に使用するトラフィックしか見られなくなります。インターセプトによって本当に動作しなくなるワークスペース（たとえば、組み込みのパススルーリストでカバーされない強固な証明書ピン留めなど）にのみ使用し、有効な間はファイアウォールを助言的なものとみなしてください。

呼び出しがブロックされたときエージェントが見るもの

ブロックされた呼び出しは、プロトコルに応じた 403 スタイルのエラーボディ — Kubernetes Status JSON、AWS AccessDeniedException、レジストリの DENIED ペイロード — を返し、そのメッセージは "blocked by Bromure Guardrails" で終わります。エージェントには、ハングした接続ではなく、報告可能なクリーンで通常の API 失敗として見えます。（サプライチェーンのブロックは、両者を一目で区別できるようにするため、代わりに HTTP 451 を使用します — サプライチェーンを参照。）

制限事項

• Git のフォースプッシュはワイヤ上で通常のプッシュと区別できないため、破壊的操作をブロックではブロックされません。プッシュをゲートするのは読み取り専用と書き込み前に確認のみです。フォージの REST API を通じた明示的な削除は依然として捕捉されます。
• Kubernetes とコンテナレジストリのポリシーは、ワークスペースの kubeconfig と設定されたレジストリから導かれるホストにのみ適用されます。データベースのポリシーには、認証情報で設定されたエンドポイントのホストが必要です。適用対象がないガードは何もフィルタリングしません（ペインがインラインで警告します）。
• 書き込みポリシーは上記のサービスを対象とします。他のホストへのトラフィックは、意味的な分類ではなく、エグレスファイアウォールのホスト/ポート/メソッドのルールによって管理されます。パッケージのダウンロードについてはサプライチェーンを、エージェントの AI トラフィックについてはプロンプトインジェクションを参照してください。