ファイアウォールルールスキーマリファレンス

ファイアウォールポリシーはルールの順序付けられたリストであり、ルールは小さなフィールドの袋にすぎません：どのツール呼び出しに、どのサーフェスでマッチし、それらについて何をするか。誰か他の人が書いたルールを読む必要があるとき — または構築中のものについて正確に推論するとき — フィールドリストを 1 か所に欲しいです。それがこのページです。ルールはコンソールのルールエディタで作成します（書き込みは Developer+ が必要）；エディタは以下の構造化されたフィールドを書き込みます。このページはフィールドレベルのマップです；深いマッチングエンジンはファイアウォールルールに存在します。

1. ファイアウォールルールスキーマ概観

すべてのルールは同じフィールドを運びます。verdict のみが常に必須です — それ以外はすべてルールが何にマッチするかを絞るか選ばれた判定を設定するかで、不在のマッチャは空虚に真です。

フィールド	目的
`priority`	評価順序 — 低いものが先に実行。
`verdict`	ルールがマッチしたときのアクション（必須）。
`stage`	スコープするサーフェス；空 = すべて。
`tool_name_glob`	ツール名に対するグロブ。
`args_match_json`	JSONPath 引数述語、JSON エンコードされた文字列として。
`egress_json`	Host / CIDR の allow-deny リスト（egress ルール）、JSON エンコードされた文字列として。
`sanitize_json`	リダクション設定（`verdict = sanitize` のとき）、JSON エンコードされた文字列として。
`cap_cost_cents`	USD セントでの実行コスト上限（`verdict = cap_cost` のとき）。
`sequence_json`	順序付けられたマルチステップチェーン述語（シーケンスルール）、JSON エンコードされた文字列として。
`label` / `notes`	人間向けの名前と根拠 — events に表示、エンジンには無視される。

ルールは、その宣言されたマッチャのすべてが一度に成立するときに発火します — ステージがマッチ（または空）、ツールグロブがマッチ、引数句がマッチ（または不在）、そして egress スコープがマッチ（egress ルールのみ）。エンジンは優先度順にルールを辿り、最初にマッチしたものが勝ちます；何もマッチしなければ、ポリシーの default_verdict が適用されます。

2. `priority` — 評価順序

整数の序数。低いものが先に実行；同じ優先度の 2 つのルールはルール id（挿入順）で同点を解決します。特定の切り出しを広いキャッチオールの上に置きます — priority 10 の 1 つの信頼されたツールへの allow は、priority 100 の deny * に勝ちます。

ギャップ（10、20、30）を残し、ポリシー全体を再番号付けせずに後で新しいルールを既存の 2 つの間に差し込めるようにします。順序付け戦略についてはルール優先度を参照。

3. `verdict` — アクション

唯一の必須フィールド。ルールがマッチすると、その判定が呼び出しに何が起こるかを決定します：

判定	効果
`allow`	呼び出しを通す、ログ付き。
`audit`	許可してレビュー用に記録 — 通常の `default_verdict`。
`deny`	呼び出しをブロック。
`sanitize`	マッチした部分文字列をツール引数からリダクトして転送。
`pending_approval`	人間のレビュアーのために呼び出しを保留。
`cap_cost`	エージェント実行の累積支出が上限を超えたら deny。

deny は inbound サーフェスで HTTP 400 firewall_blocked を、mcp サーフェスでツールエラーを返します。保留された呼び出しは、エージェントがポーリングする id とともに HTTP 400 firewall_approval_pending を返します。シャドウモードでは、すべての強制判定が audit に格下げされ、理由には [shadow] would … が前置されます。完全なテーブルとブロックの形については判定を参照。

4. `stage` — 強制サーフェス

ルールをファイアウォールのサーフェスのひとつに固定します。空のままにすると、ルールは すべてのサーフェスに適用されます：

inbound — アドバタイズされるツール定義

エージェントがリクエストでモデルにアドバタイズするツール。モデルがそれを選択できる前に、危険なツールをブロックします。

response — モデルが発行する tool_calls

モデルがその返信で発行する tool_calls。

mcp — tools/call ディスパッチ

ファイアウォール MCP ゲートウェイ経由でルーティングされる tools/call。

egress — アウトバウンド宛先

ツールが到達するアウトバウンドの host / IP / CIDR — SSRF とデータ持ち出しのサーフェス。

一部の判定 + ステージの組み合わせは、判定がそこで発火できないため保存時に拒否されます： cap_cost はディスパッチ前の実行コスト上限で、response と egress では不活性です； pending_approval は inbound でのみ保留するため、明示的な response/egress の固定は拒否されます。エディタはこれらの組み合わせを隠します；API はそれらを拒否します。ステージを参照。

5. `tool_name_glob` — どのツール

ツール名に対する小さく、大文字小文字を区別するグロブ — ファミリー全体には shell.*、サーバーをまたいだ動詞には *.delete、1 つの正確なツールには http_fetch。空または * はすべてのツールにマッチします。オプションのスキル名グロブ（同じ文法）は 所有スキルに 2 つ目の条件を AND するため、組み込みスキルからのツールを信頼し、コミュニティのものからゲートできます。完全な文法 — プレフィックス、サフィックス、インフィックス、exact、そして人を引っかけるエッジ — は独自のリファレンスです：グロブパターン構文。

6. `args_match_json` — どの引数で

グロブはどのツールに答えます；args_match_json はどの引数でに答えます — 「shell.exec をブロック」と「コマンドが rm -rf のときのみ shell.exec をブロック」の違いです。その値は、JSONPath 句のセットを運ぶ JSON エンコードされた文字列で、 すべて AND されます。デコードすると、句オブジェクトはこう見えます：

{
  "clauses": [
    { "path": "$.command",    "op": "regex",      "value": "rm -rf|drop table" },
    { "path": "$.connection", "op": "in",         "value": ["prod", "replica"] },
    { "path": "$.ip",         "op": "cidr_match", "value": "10.0.0.0/8" }
  ]
}

リクエストボディでは、このフィールドはそのオブジェクトをエスケープされた文字列として運びます。例： "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf\"}]}"。演算子は eq、contains、regex、in、cidr_match、gt、lt です。不在の args_match_json は空虚に真です — ルールはグロブ単独でマッチします。完全な述語言語、パス構文、壊れた句のフェイルクローズ挙動は引数の検証と引数クックブックにあります。

7. `egress_json` — どの宛先

egress サーフェスで使用：ツールが到達するアウトバウンド宛先に対してマッチされる host / CIDR の allow-and-deny リストを保持する JSON エンコードされた文字列。デコードすると、オブジェクトはこう見えます：

{
  "deny":  ["169.254.169.254", "10.0.0.0/8"],
  "allow": ["api.openai.com"]
}

エントリは CIDR、IP リテラル、または大文字小文字を区別しないホスト名としてマッチします。極性は判定に従います — 強制判定では deny リストが何がブロックされるかを定義し、 allow がそこから例外を切り出します。

Baseline ファイアウォールテンプレートは、既製の SSRF / クラウドメタデータの deny リスト（メタデータ IP 169.254.169.254、RFC-1918 範囲、ループバック、リンクローカル、そして metadata.google.internal）を持つ egress deny ルールを出荷するため、それらを手作成する必要はありません。ゲートしたい他のもののために、独自の宛先をその上に追加します。完全なレシピについてはEgress 制御を、それがなぜ重要かについてはデータ持ち出しを参照。

8. `sanitize_json` — 引数をリダクト

verdict = sanitize のときに使用：クリーニングされた呼び出しが転送される前に、どのプリセット / カスタム正規表現がツール引数からマッチした部分文字列をリダクトするかを名指しする JSON エンコードされた文字列 — アクション全体をブロックせずに、エージェントが引数に落としたシークレットや PII 値を剥がすのに便利です。デコードすると、オブジェクトはこう見えます：

{ "presets": ["email", "ssn_us"], "custom": ["foo-\\d+"] }

サニタイズは引数のみをリダクトします — ツールが返すコンテンツは決して触りません。サニタイズルールは少なくとも 1 つのプリセットまたはカスタムパターンを名指ししなければなりません（空のサニタイザは拒否されます）。inbound サーフェスにはリダクトする呼び出し時の引数がないため、そこでのサニタイズ判定は deny にエスカレートします。

プリセットライブラリとリダクションの形についてはレスポンスのサニタイズを参照。

9. `cap_cost_cents` — 支出上限

verdict = cap_cost のときに使用：ルールごとの実行コスト上限、USD セントでの整数。ルールがマッチすると、エージェント実行の累積支出が上限を超えた時点で呼び出しが deny されます — 暴走ループのためのサーキットブレーカーで、events では allow または deny に解決されます。上限は明示的かつ非負でなければならず、ルールは response または egress （判定が不活性）に固定できません。完全な挙動はコスト上限にあります。

10. 完全なルール 1 つ

フィールドを組み合わせて — shell.exec を deny、しかしコマンドが破壊的に見えるときのみ、モデルが発行したツール呼び出しにスコープ：

{
  "priority": 10,
  "label": "block destructive shell",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|:\\\\(\\\\)\\\\{\"}]}",
  "verdict": "deny",
  "notes": "fork bombs and recursive deletes only — plain shell.exec audits"
}

ステージは response サーフェスにマッチし、グロブは shell.exec を選び、単一の句は破壊的なコマンドに絞り、判定は deny します。コマンドが正規表現にマッチしない任意の shell.exec は、次のルールまたはポリシーデフォルトに落ちます。ポリシーにキーをアタッチすると（キーの firewall_policy_id）、次の呼び出しでライブになります — 再デプロイなし。

依存する前に、ルールが正確に期待どおりに発火することを確認します：ルールのテストはサンプルのツール呼び出しに対してポリシーをドライランし、何もディスパッチせずに判定、マッチしたルール、理由を返します。

11. フィールドがどう組み合わさるか

有効なルールが必要とする最小は？

verdict。それ以外はすべてオプションです：空の stage はすべてのサーフェスにマッチし、空の tool_name_glob（または *）はすべてのツールにマッチし、不在の args_match_json は任意の引数にマッチします。裸の { "verdict": "audit" } は有効なキャッチオールです。

マッチャは AND か OR か？

AND です。ルールは、そのステージ、ツールグロブ、スキルグロブ、引数句、egress スコープがすべて成立するときのみ発火します。OR を表現するには、別々のルールを書きます。

どのフィールドがどの判定とペアになるか？

sanitize_json は sanitize 判定にのみ読まれます；cap_cost_cents は cap_cost にのみ；egress_json は egress サーフェスでのみ。コンソールは保存時にこれらのペアリングを検証するため、ある挙動を表示しながら決してそれを強制できないルールは永続化できません。

2 つのルールが両方ともマッチしたら？

低い priority が勝ちます（同点はルール id で解決） — 最初にマッチしたものが勝ち、評価はそこで停止します。ルール優先度を参照。

ポリシーの作成

最初のポリシーを作成し、キーをアタッチ。

グロブ構文

完全なツール名グロブ文法。

判定

すべての判定とブロックがどう見えるか。

引数の検証

JSONPath 引数句を詳しく。

ポリシーの管理

ポリシーの編集、バージョン管理、リバート。