メインコンテンツへスキップ
ファイアウォールポリシーは、エージェントが行うすべての ツール呼び出しについてひとつのことを決定します：判定です。ルールがマッチして 判定を生成するか、どのルールもマッチせずポリシーのデフォルト判定が引き継ぐかの どちらかです。このページは両方をカバーします — 各ファイアウォール判定が何をするか、 cap_cost がどう解決されるか、そしてなぜ audit が開始するデフォルトなのか。 判定がルール文法のどこにあるかについては ファイアウォールルールを、ポリシー作成時にデフォルト 判定を選ぶことについては作成 & アタッチを 参照してください。

​
1. 6 つのルール判定

ルールはちょうど 6 つの判定のうちのひとつを生成します。コンソールのルールエディタで それらを作成します；エンジンは優先度順にルールを辿り、最初にマッチしたものが 勝ちます。
呼び出しは手を加えられずに進みます。それでも events フィードに allow として着地する ため、何もブロックせずに監査証跡を維持できます。デフォルト deny ポリシーでの 明示的な許可として使います。
トラフィックの結果は allow と同一ですが、呼び出しは監視したかったものとして フラグされます。これはデフォルト判定が箱から出した状態で着地する値でも あります — 強制する準備ができるまで、すべてを観察し、何もブロックしません。
呼び出しはツールに決して到達しません。inbound サーフェスでは、リレーは ツールと理由を名指しするエラーコード firewall_blocked の HTTP 400 を 返します；mcp サーフェスではツールエラーとして返ってくるため、モデルが 反応できます。ブロックがどう見えるかを参照。
ツール呼び出しの引数からマッチした部分文字列をリダクトし（エージェントが command や body フィールドに入れたシークレットや PII）、クリーニングされた 呼び出しを転送します。引数のみをリダクトします — ツールが返すコンテンツは 決して触りません。inbound サーフェスではまだ呼び出し時の引数がないため、 sanitize は deny にエスカレートします。 レスポンスのサニタイズを参照。
呼び出しを帯域外のレビューに変えます。リレーはコード firewall_approval_pending と承認 id を持つ HTTP 400 を返します；呼び出しは ツールに到達しません。レビュアーがコンソールまたは webhook コールバック経由で それを解決し、エージェントは単回使用の承認ヘッダーとともに再送信します。 承認を参照。
コストサーキットブレーカー — ルールとして作成されますが、評価時に allow または deny に解決されます。§3と コスト上限を参照。
シャドウモードは強制を平坦化します。 シャドウモードでは、すべての強制判定 （deny、sanitize、pending_approval、そして deny に解決された cap_cost）が audit に格下げされ、理由には [shadow] would … が前置されます。強制ポリシーを この方法でロールアウトし、ライブにする前に events フィードを監視します。

​
2. デフォルト判定

デフォルト判定（ポリシーの default_verdict）は、ポリシーがどのルールも マッチしないツール呼び出しに対して行うことです。それはあなたの姿勢の床であり、 ルール判定とは異なり、3 つの値のみを受け入れます：
default_verdictどのルールもマッチしないとき…
audit (デフォルト)呼び出しを許可しますが、記録します。安全な開始点。
allow許可してログ、レビューレコードなし。
denyルールが明示的に許可しないものをブロック — デフォルト deny の姿勢。
新しいポリシーはデフォルトで audit です：すべてのツール呼び出しを観察し、 強制ルールを追加するまで何もブロックしません。3 つのルール専用判定 — sanitize、 pending_approval、cap_cost — はデフォルトになれません；デフォルト判定は 全体的なフォールバックであり、それらの判定は特定のマッチにスコープされたときのみ 意味を持ちます。
デフォルト判定としての deny はデフォルト deny です：ルールが明示的に allow しないツール呼び出しはブロックされます。ロックダウンされたエージェントには強力ですが、 許可リストし忘れた呼び出しを止めてしまいます。明示的な allow ルール （ツール許可リスト）と組み合わせ、まず シャドウモードのもとでロールアウトしてください。

​
3. cap_cost は allow または deny に解決される

cap_cost は、events に表示されるものと異なる唯一の判定です。cap_cost_cents 上限を持つルールを作成しますが、評価時にエンジンはそれをイベントが記録される前に 具体的な allow または deny に解決します — そのため events フィードはリテラルの cap_cost 判定を 決して運ばず、エージェントが実際に見た allow/deny のみを運びます。 上限はエージェント実行ごとです：エンジンは実行の累積支出を上限と比較します。
  • 上限未満 → allow に解決されます。（内部的にはこれは非マッチとして扱われる ため、cap_cost を最初のマッチとして許可として勝たせるのではなく、次のルールに 評価が続きます。）
  • 上限超過 → deny に解決され、実行の合計と上限を名指しする理由が付きます。 これは終端の、サーキットブレーカーの結果です。
// A rule that caps a run at $5.00 of accumulated spend.
{
  "label": "run cost ceiling",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
cap_cost はディスパッチ前のサーフェス（inbound、mcp）でのみ発火します — 呼び出しを ブロックすることで依然として支出を防げるポイントです。ディスパッチ後の response と egress サーフェスでは不活性です（止めるものが何も残っていません）ので、エンジンは そこではそれをスキップします。

​
4. 判定がどう選ばれるか

任意のツール呼び出しについて、どの判定が勝つかに関わらず解決は同じです：
ゲートウェイは呼び出し元キーにアタッチされたポリシー（firewall_policy_id）、 またはワークスペースデフォルトを選びます — 解決を 参照。
ルールは priority ASC 順で実行されます。サーフェス、ツールグロブ、オプションの 引数句、オプションの egress スコープがすべてマッチする最初のルールが判定を 生成します。
どのルールもマッチしなければ、ポリシーの default_verdict が適用されます — 変更していなければ audit です。
呼び出しが統制されたスキルによって所有されている 場合、block モードのスキルは deny を強制し、quarantine モードのスキルは deny 未満のものを pending_approval にエスカレートします。

​
5. deny のコストと再試行の挙動

inbound サーフェス上のファイアウォール判定はアップストリームのモデル呼び出しの 前に発火するため、そこでの deny はモデルトークンを消費しません。エラーは skip-retry とマークされます — 同じブロックされた呼び出しを再実行してもまた ブロックされるだけなので、ゲートウェイはクライアントに再試行しないよう伝えます。 これはガードレールブロックとは 異なります。ガードレールはツールのアクションではなくプロンプト/レスポンスの テキスト（PII、シークレット）をスクリーニングし、独自の guardrail_blocked エラーを返します。リクエストは両方のプレーンを通過できます。
各判定は証跡を残します。 すべての評価 — allow、audit、deny、解決された cap_cost、保留された承認 — はファイアウォールイベントとして記録され、判定、サーフェス、 ツール、実行でフィルタ可能です。events フィードは、ポリシーが期待する判定を生成して いることを確認する方法です。events ログと 分析を参照。

​
次に進む場所

ポリシーの作成 & アタッチ

デフォルト判定を選び、ポリシーをキーにバインドします。

コスト上限

支出上限を作成し、それが実行ごとにどう解決されるか。

シャドウモード

影響を測定する間、すべての強制判定を audit に格下げします。

ルールリファレンス

判定の背後にある完全なマッチング言語。
これらの判定が止めるべき脅威については、 危険なツール呼び出しと 過剰なエージェンシーを参照してください。