メインコンテンツへスキップ
AI エージェントは単にテキストを生成するだけではありません — アクションを取るの です。shell.exec を呼び出し、データベースをクエリし、URL を取得し、MCP サーバー 経由でツールをディスパッチします。これらのそれぞれが現実世界に影響を及ぼす アクションであり、プロンプトレベルのガードレール はそれらを見ることができません。エージェントファイアウォールはそれらを統制する アクション層のプレーンです：ゲートウェイがすべてのツール呼び出しで — ツールに到達する 前に — 評価する、ワークスペーススコープの名前付きポリシーです。 このページはファイアウォールセクションのハブです — ポリシーモデル、判定、 サーフェス、そしてポリシーがどうキーにアタッチされるか。各スポークがより深く 掘り下げ、完全なエンジンリファレンスは ファイアウォールとファイアウォールルール にあります。

​
1. エージェントファイアウォールが行うこと

ワークスペースコンソールでポリシーを一度作成し、API キーをそれにアタッチするか （あるいはワークスペースデフォルトに設定し）、それ以降はそのキーが発行する すべてのツール呼び出しがゲートウェイでポリシーに対してチェックされます。再デプロイ 不要、エージェントのコード変更不要 — エージェントは以前と全く同様にツール呼び出しを 発行し続け、ポリシーの編集は、それにアタッチされたすべてのキーで次の呼び出しから 反映されます。 ポリシーは順序付けられたルールのリストです。各ルールは、どのツール呼び出しに 適用されるかとそれにどう対処するかを決定します。エンジンは優先度順にルールを 辿り、最初にマッチしたものが勝ち、何もマッチしなければポリシーのデフォルト 判定にフォールバックします。
検出はゲートウェイで、初回使用時に行われます — インストール時ではありません。 エージェントが自己インストールしたツール、MCP サーバー、スキルは、その呼び出しが 初めてゲートウェイを横切ったときに捕捉されます。これは、ケイパビリティがどのように そこへ到達したかに関わらず、すべてのプロバイダ、すべてのエージェント、すべての ツール呼び出しを見る唯一のチョークポイントです。

​
2. 具体例

破壊的なシェルコマンドをブロックしつつ、それ以外はすべて audit のもとで通したいと します。コンソールで default_verdict = audit とひとつのルールを持つポリシーを 作成します： 
{
  "label": "block rm -rf",
  "tool_name_glob": "*.exec",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|drop table\"}]}",
  "verdict": "deny"
}
args_match_json は JSON エンコードされた文字列です（ゲートウェイは保存時に それを句スキーマに対して検証します）：path は呼び出しの引数への JSONPath、op は eq、contains、regex、in、cidr_match、gt、lt のいずれかです。 ポリシーにキーをアタッチします（キーに firewall_policy_id を設定）。これで エージェントが command: "rm -rf /" で shell.exec を発行すると、ゲートウェイは ツールを名指しする理由とともにエラーコード firewall_blocked で HTTP 400 を 返し — 呼び出しはシェルに到達しません。それ以外のすべてのツール呼び出しは許可され、 レビュー用に記録されます。
新しいポリシーはまずシャドウモードのもとで ロールアウトします：本番と全く同様に評価しログを取りますが、すべての強制判定が audit に格下げされ、理由には [shadow] would … が前置されます。events フィードを 監視してから、シャドウをオフにして強制します。

​
3. ポリシー、ルール、解決

ポリシーはワークスペーススコープで名前付きであり、enabled、is_default、 default_verdict（allow / audit / deny、デフォルト audit）、そして shadow_mode フラグを持ちます。ルールはその中のひとつのチェックです — ポリシーの作成と ルールスキーマを参照。 任意のツール呼び出しについて、ゲートウェイはこの順序でアクティブなポリシーを 解決します：
  1. キーアタッチメント — 呼び出し元キーの firewall_policy_id（そのポリシーが 存在し有効である場合）。
  2. ワークスペースデフォルト — それ以外の場合、有効な is_default ポリシー。
無効化されたアタッチ済みファイアウォールポリシーはワークスペースデフォルトに フォールバックします — これはガードレールとは異なります。ガードレールでは 無効化されたアタッチメントはnone に解決されます。キーのファイアウォールのオフ スイッチは「デフォルトを使う」であり、「強制なし」ではありません。 ポリシーの管理を参照。
ポリシーがまったく解決されない場合、挙動はワークスペースの firewall_observe_mode 設定に依存します：観察モードオンの場合、呼び出しは 許可されますがカバレッジのギャップとしてログされます（Discovered Tools に 表示されます）；オフの場合、呼び出しはサイレントに許可されます。

​
4. 判定

ルール — またはデフォルト — は次のいずれかを生成します：
判定何をするか
allow通します。ログされます。
audit許可 + レビュー用に記録。通常のデフォルト。
denyブロック。inbound では HTTP 400 firewall_blocked；MCP ではツールエラー。
sanitizeマッチした部分文字列をツールの引数からリダクトして転送。
pending_approval人間のために保留；HTTP 400 firewall_approval_pending。
cap_cost実行の支出がルールごとの上限を超えたら deny。
sanitize 判定は呼び出しの引数のみをリダクトします — ツールが返すコンテンツは 決して触りません。inbound サーフェスでは — まだ呼び出し時の引数がないため — sanitize はブロックにエスカレートします。判定と レスポンスのサニタイズを参照。

​
5. 4 つの強制サーフェス

すべてのツール呼び出しは、ちょうどひとつのサーフェスに対して評価されます — stage フィールドでルールをひとつに固定するか、空にしてすべてに適用します。

inbound

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

response

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

mcp

MCP ゲートウェイ経由でディスパッチされる tools/call。 MCP サーバーを参照。

egress

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

​
6. マッチング

ルールは、ホットパスで安全な、小さく決定論的な語彙で、どのツール呼び出しを 捕捉するかを表現します：
ツール名に対する大文字小文字を区別するグロブ（shell.*、*.delete）。 オプションで所有スキルに対するグロブと AND されます。 グロブ構文と ツール許可リストを参照。
呼び出しの引数に対する JSONPath 述語、演算子は eq、contains、regex、 in、cidr_match、gt、lt — 「shell.exec をブロック」と「コマンドが rm -rf のときのみブロック」の違いです。句はフェイルクローズします（リクエスト ではなくルールが）。引数の検証を参照。
egress サーフェス上の host / IP / CIDR 許可・拒否リスト。クラウドメタデータや RFC-1918 範囲に対する独自の deny ルールを作成できます。 egress 制御を参照。
sequence ルールはウィンドウをまたいだ順序付けられた呼び出しチェーンに マッチします（リアクティブに強制）；cap_cost ルールはエージェント実行の 累積支出がセント上限を超えたら deny します。 シーケンスルールと コスト上限を参照。

​
7. 人間による承認、自律性、異常

  • ヒューマンインザループ。 pending_approval 判定は呼び出しを保留し、その 承認 id を返します。レビュアーはコンソール（Developer+）または HMAC 署名付き webhook コールバック経由でそれを解決します；エージェントはポーリングし、単回使用の X-OrcaRouter-Firewall-Approval ヘッダーとともに再送信します。 承認と 承認 webhookを参照。
  • 自律性レベル。 ひとつのスイッチが姿勢全体を設定します：tight （デフォルト deny + 破壊的シェルを deny + フェッチ形のツール （http_fetch/web_search/fetch_url/request、SSRF ベクトル）を deny + PII Shield + Secrets Blocker を強制）、balanced（デフォルト audit、破壊的シェルを deny、PII Shield は audit のみ）、または permissive（観察のみ）。それぞれが 実在する編集可能なポリシーおよびガードレール行を書き込み、監査スナップショットから ワンクリックで取り消せます。
  • 異常検出。 静的なルールを超えて、ファイアウォールは学習された曜日内時間ベース ライン（14 日間）に対してツール使用をスコアリングし、レート/コストのスパイク、 retry_loop、novel_path を Member 可読のフィードでフラグします。最大 7 日間 スヌーズできます。

​
8. ファイアウォールがどこに収まるか

ファイアウォールは、隣接する 2 つのプレーンのアクション層のピアです：
プレーン統制対象いつ使うか
ガードレールプロンプト & レスポンスのテキストPII、シークレット、jailbreak、インジェクション意図
エージェントファイアウォールツールのアクションどのツール、MCP 呼び出し、ホスト、コスト
コンプライアンス証跡 & フレームワークSOC 2 / HIPAA / EU AI Act レディネス
コンテンツプレーンとアクションプレーンの両方が単一のリクエストに適用でき、自律性 レベルはそれらを一緒に構成します。 ガードレール vs. ファイアウォールと コントロールスタックを参照。

​
9. アタッチと接続

ポリシーは firewall_policy_id 経由でキーにバインドされます（コンソールで設定； バインディングはゲートウェイのキー上にあります）。ツール呼び出しがエンジンに到達する 方法は 2 つあり、どちらもファイアウォールゲートウェイスコープのキー （is_firewall_gateway = true）を必要とします — 通常のリレーキーはこれらのルートで 403 を受け取ります：
  • MCP ゲートウェイ — MCP クライアントを統合された ANY /api/v1/firewall/mcp エンドポイントに向けます；すべての tools/call が インラインで評価されます。MCP サーバーを参照。
  • Evaluate フック — ディスパッチする前に、独自のエージェントループから POST /api/v1/firewall/evaluate（マルチステッププランの場合は /evaluate_plan）を 呼び出し、判定に応じて動作します。
すべてのコンソール設定は /api/workspace/firewall/* 経由でセッション下で実行されます。 ポリシー、設定、discovered tools、読み取り専用の自律性シミュレータ、異常フィードの 読み取りはすべてのワークスペースメンバーに開放されています；ドライランの Test サンドボックス、Events / Runs ログ、そしてすべての書き込みは Developer+ を 必要とします。ゲートウェイキーと ルールのテストを参照。

​
10. このプレーンが対処する脅威

危険なツール呼び出し

破壊的シェル、DB ドロップ、危険な動詞をグロブ + 引数で deny。

データ持ち出し

egress リストと read-then-export シーケンスルール。

MCP ツールポイズニング

ディスパッチ前の mcp サーフェスでの呼び出しごとの評価。

過剰なエージェンシー

承認、コスト上限、デフォルト deny の姿勢。

​
次のステップ

ポリシーの作成

最初のポリシーとルールを作成します。

判定

各判定がワイヤー上で何をするか。

Events ログ

ファイアウォールが何を、なぜ決定したかを読みます。