ガードレール
ガードレールは、ワークスペースの認証情報がどのように使用されるかをホスト側で制御する 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つのモードを提供します。
| モード | 動作 |
|---|---|
| オフ | フィルタリングなし。 |
| 書き込み前に確認 | 読み取りはそのまま通過します。すべての書き込みは、正確な操作を表示するホスト側の同意ダイアログのために一時停止し、時間制限付きの許可を提示します（下記参照）。 |
| 破壊的操作をブロック | 削除、drop、終了はブロックされ、作成と更新は通過します。 |
| 読み取り専用 | すべての変更はブロックされ、読み取りのみが通過します。 |
新しいワークスペースでは、ポリシーに対応するすべてのサービスで（設定テンプレートを通じて）書き込み前に確認がデフォルトになります。ガードレールが存在する前に作成されたワークスペース — または JSON にこのフィールドを含まないプロファイル — はオフとしてデコードされます。
メモ: 書き込みポリシーは認証情報ごとではなく、サービスごとです。同じサービスに対する2つの認証情報 — たとえば2つの GitHub トークン — は1つのポリシーを共有するため、どちらかの行で選択を変更すると両方に反映されます。
メモ: ガードレールは操作を分類しますが、認証情報を隠すわけではありません。認証情報自体は認証情報で設定したとおり、プロキシによって注入・差し替えされます。多層防御のために、読み取り専用の書き込みポリシーと同じ行の使用前に確認チェックボックスを組み合わせてください。
各サービスによる呼び出しの分類方法
| サービス | 範囲 | 分類 |
|---|---|---|
| Kubernetes | このワークスペースの kubeconfig から得られる Kubernetes API サーバー | GET/HEAD/OPTIONS = 読み取り、DELETE = 破壊的（deletecollection を含む）、その他の動詞 = 書き込み。ブロックされた呼び出しは、kubectl がきれいに描画する Kubernetes Status 403 JSON を返します。 |
| AWS | すべての *.amazonaws.com ホスト | X-Amz-Target ヘッダーのアクション名（DynamoDB や Lambda などの JSON プロトコルサービス）または Action= フォームパラメータ（EC2、IAM、SQS などのクエリプロトコルサービス）が接頭辞で分類されます。Delete*/Terminate*/Remove*/Purge*/Destroy*/Deregister*/Revoke* = 破壊的、Get*/List*/Describe* および類似 = 読み取り。S3 や REST スタイルのリクエストでは HTTP メソッドにフォールバックします。ブロックされた呼び出しは AccessDeniedException のボディを返します。 |
| DigitalOcean | api.digitalocean.com および *.digitalocean.com | HTTP メソッド: DELETE = 破壊的、GET/HEAD = 読み取り。 |
| コンテナレジストリ | 認証情報で設定されたレジストリと Docker Hub のエンドポイント | プル（GET）= 読み取り、プッシュ（PUT/POST）= 書き込み、DELETE = 破壊的。ブロックされた呼び出しはレジストリスタイルの DENIED エラーボディを返します。 |
| GitHub | github.com REST API および HTTPS 経由の git | REST はメソッドベース。git push（git-receive-pack）は書き込みとしてカウントされ、読み取り専用ではブロック、書き込み前に確認では確認されます。git fetch（git-upload-pack）は常に読み取りです。 |
| GitLab | gitlab.com REST API および HTTPS 経由の git | GitHub と同じ分類ロジック。 |
| Bitbucket | bitbucket.org REST API および HTTPS 経由の git | GitHub と同じ分類ロジック。 |
データベースのエンドポイントはエンジンごとに分類されます。
| エンジン | 読み取り | 書き込み | 破壊的 |
|---|---|---|---|
| MongoDB（Atlas Data API） | find、findOne、aggregate | insert、update、replace | deleteOne、deleteMany |
| ClickHouse | 先頭キーワードが SELECT、SHOW、DESCRIBE、EXPLAIN、WITH … の SQL | INSERT、CREATE、ALTER、… | DROP、TRUNCATE、DELETE、および ALTER … DELETE / DROP COLUMN / DROP PARTITION / CLEAR |
| Elasticsearch | _search、_msearch、_count、_mget、_sql、およびその他のクエリエンドポイント（POST 経由でも） | _bulk、_update、ドキュメントのインデックス作成 | DELETE および _delete_by_query |
ポリシーが設定されていても適用対象がない場合 — 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 内のテキストプロンプトとして提示されます。応答がない場合は拒否されます。
メモ: ガードレールの書き込み許可はどのウィンドウにも一覧されません。認証情報の承認ウィンドウ（ウィンドウメニュー → 認証情報の承認…）には、認証情報の同意決定 — 使用前に確認の許可 — のみが表示されます。書き込みポリシーの許可は独自のタイマーまたはセッションの終了時に期限切れとなります。
呼び出しがブロックされたときエージェントが見るもの
ブロックされた呼び出しは、プロトコルに応じた 403 スタイルのエラーボディ — Kubernetes Status JSON、AWS AccessDeniedException、レジストリの DENIED ペイロード — を返し、そのメッセージは "blocked by Bromure Guardrails" で終わります。エージェントには、ハングした接続ではなく、報告可能なクリーンで通常の API 失敗として見えます。（サプライチェーンのブロックは、両者を一目で区別できるようにするため、代わりに HTTP 451 を使用します — サプライチェーンを参照。）
制限事項
- Git のフォースプッシュはワイヤ上で通常のプッシュと区別できないため、破壊的操作をブロックではブロックされません。プッシュをゲートするのは読み取り専用と書き込み前に確認のみです。フォージの REST API を通じた明示的な削除は依然として捕捉されます。
- Kubernetes とコンテナレジストリのポリシーは、ワークスペースの kubeconfig と設定されたレジストリから導かれるホストにのみ適用されます。データベースのポリシーには、認証情報で設定されたエンドポイントのホストが必要です。適用対象がないガードは何もフィルタリングしません（ペインがインラインで警告します）。
- ガードレールは上記のサービスを対象とします。他のホストへの任意の HTTPS トラフィックは分類されません。パッケージのダウンロードについてはサプライチェーンを、エージェントの AI トラフィックについてはプロンプトインジェクションを参照してください。