ファイアウォール

ガードレールはモデルを流れるテキストをスクリーニングします。ファイアウォール はエージェントが取るアクションを統制します — 呼び出すツール、到達する MCP サーバー、ロードするスキル、通信するホストです。これは ガードレールのアクション層のカウンターパートです：同じ ワークスペーススコープ、同じアタッチワンスモデル、そして同じ「ポリシーは アプリではなくゲートウェイに存在する」という約束です。 このページは概念的な概要と運用リファレンスです。3 つのコンパニオンページが 可動部分を詳しく扱います：

​

1. ファイアウォールとは

AI エージェントは単にテキストを生成するだけではありません — アクションを取るの です。shell.exec を呼び出し、db.query をクエリし、URL を取得し、コミュニティ スキルをロードし、あるいはサードパーティの MCP サーバー経由でツール呼び出しを ルーティングします。これらのそれぞれが現実世界に影響を及ぼすアクションであり、 プロンプトレベルのガードレールはそれらを見ることができません。 ファイアウォールは、ゲートウェイがすべてのツール呼び出しで評価する ワークスペーススコープの名前付きポリシーです。ポリシーを一度作成し、API キーを それにアタッチするか（あるいはワークスペースデフォルトに設定し）、それ以降は そのキーが発行するすべてのツール呼び出しが — ツールに到達する前に — ポリシーに対してチェックされます。 各ポリシーは順序付けられたルールのリストです。ルールはひとつのことを決定します — どのツール呼び出しに適用されるか（ツール名グロブ。オプションでスキルや強制 サーフェスにスコープされます）とそれにどう対処するか（判定：allow、audit、 deny、sanitize、承認のための保留、またはコスト上限）。エンジンは優先度順に ルールを辿り、最初にマッチしたものが勝ち、何もマッチしなければポリシーの デフォルト判定にフォールバックします。 ポリシーを編集すると、それにアタッチされたすべてのキーが次の呼び出しで 反映されます。再デプロイ不要。エージェントのコード変更不要。ポリシーは ゲートウェイで強制されます — エージェントは以前と全く同様にツール呼び出しを 発行し続けます。

​

2. 4 つの強制サーフェス

すべてのツール呼び出しは、ちょうどひとつのサーフェス — ファイアウォールが それを見るリクエストライフサイクル上のポイント — に対して評価されます： ステージのないルールはすべてのサーフェスに適用されます；判定がそこでのみ 意味を持つ場合（例：egress 許可リスト）は、ルールをひとつのサーフェスに固定します。

​

3. コアコンセプト

​

スコープと解決

ポリシーはガードレールや API キーと全く同様に解決されます：アクティブな ワークスペースがある場合はワークスペース共有です。任意のツール呼び出しについて、 ゲートウェイはこの順序でポリシーを解決します：

1. キーアタッチメント — 呼び出し元のキーに firewall_policy_id がある場合、 そのポリシーが適用されます（存在し有効である場合）。
2. ワークスペースデフォルト — それ以外の場合、ワークスペースの有効な is_default ポリシーが適用されます。
3. どちらもなし — 強制なし。観察モードがオンの場合、呼び出しは許可され ギャップとしてログされます；オフの場合、呼び出しはサイレントに許可されます （この機能を一度も有効化していないワークスペースとバイト単位で同一です）。

ワークスペースごとに最大ひとつのポリシーがデフォルトになれます；新しい デフォルトをプロモートすると、同じトランザクション内で古いものが降格されます。

​

4. 判定

ルール（またはデフォルト判定）は次のいずれかを生成します： シャドウモードでは、deny / sanitize / pending_approval はすべて audit に 格下げされるため、ポリシーがトラフィックを変える前にその影響を測定できます。

​

5. ツール呼び出しがどう評価されるか

1. ツール呼び出しがゲートウェイに到達します（inbound でアドバタイズされる、 レスポンスで発行される、MCP ゲートウェイ経由でディスパッチされる、または egress として報告される）。
2. エンジンはアクティブなポリシーを解決します（§3）。
3. 優先度順にポリシーのルールを辿ります（低い優先度が先；同点はルール id で 解決）。ルールは、そのサーフェス、ツール名グロブ、オプションのスキル名グロブ、 オプションの引数句、そしてオプションの egress スコープがすべてマッチした ときにマッチします。
4. 最初にマッチしたものが勝ち → そのルールの判定が適用されます。どのルールも マッチしなければ → ポリシーの default_verdict。
5. 呼び出しが統制されたスキルによって所有されている 場合、スキルの強制モードがその上に適用されます — block モードのスキルは deny を 強制し、quarantine モードのスキルは deny 未満のものを pending_approval に エスカレートします。
6. 決定はファイアウォールイベントとしてログされ（ドライランでない限り）、エージェント 実行とセッションに相関付けられます。

​

6. ブロックがどう見えるか

inbound サーフェスで拒否された呼び出しは、OpenAI 形式のエラーボディ、 エラーコード firewall_blocked、そしてツールと理由を示すメッセージとともに HTTP 400 を返します — 例：tool "shell.exec" blocked by firewall: destructive shell command。エラーは構造化された metadata（理由コード、リスク要因、スコア）を 持ち、skip-retry とマークされます（同じ呼び出しを再実行してもまたブロックされる だけです）。 MCP ゲートウェイ経由でディスパッチされた呼び出しは、トランスポート障害では なくツールエラー（firewall deny: <reason>）としてブロックされるため、モデルは 拒否を見て反応できます — 別のツールを選ぶ、ユーザーに尋ねる、あるいは停止する — クラッシュする代わりに。 保留された呼び出し（pending_approval）は、コード firewall_approval_pending と、 クライアントがポーリングする承認 id とともに HTTP 400 を返します。

​

7. 人間による承認（HITL）

pending_approval 判定は、ツール呼び出しを帯域外のレビューに変えます：

1. エンジンは承認レコードをエンキューし、その id を持つ「保留中」のレスポンスを 返します；呼び出しはツールに到達しません。
2. レビュアーがそれを解決します — コンソールから（Developer+）、あるいは独自の 承認システムへの HMAC 署名付き webhook コールバック経由で。
3. エージェント（または MCP SDK）が承認 id をポーリングします；承認されると、 単回使用の X-OrcaRouter-Firewall-Approval ヘッダーとともに元の呼び出しを 再送信し、ゲートウェイはその一度限り通します。

決定はファーストライタウィンかつ冪等です。基礎となるルールが保留の後に編集された 場合、エンリッチメントは rule_changed を記録するため、レビュアーはコンテキストが 変わったことを知ることができます。

​

8. 自律性レベル — 姿勢全体のためのひとつのスイッチ

ポリシーをルールごとにチューニングするのは精密な道です；自律性レベルは 高速な道です。単一のコントロールが、ワークスペースのファイアウォールおよび ガードレールの姿勢を、ワンクリックの取り消しとともに、ひとつのトランザクションで アトミックに置き換えます： 取り消しは、監査スナップショットから直前の正確な状態を復元します。

​

9. 異常検出

静的なルールを超えて、ファイアウォールは各ワークスペースの通常のツール使用の形状を 学習し、逸脱をビューア可読のフィードでフラグします：

• レート / コストのスパイク — ツールごとのアクティビティが学習された 曜日内時間ベースライン（14 日間の移動平均）に対してスコアリングされるため、 「日曜午前 3 時の 100 回の db.query 呼び出し」は、各呼び出しが個別には許可される 場合でも際立ちます。
• retry_loop — エージェントが同じ失敗するツールを叩き続けている。
• novel_path — このワークスペースがこれまで一度も行ったことのない ツール間遷移。

フィードはツール名、リダクトされたトークン id、そしてカウントのみを報告します。 調査中の異常を最大 7 日間スヌーズできます。

​

10. 可観測性

ファイアウォールは、対処可能なトレイルを残します。すべてワークスペーススコープです：

​

11. ゲートウェイの他部分との関係

​

12. エージェントをファイアウォールゲートウェイに接続する

ツール呼び出しがエンジンに到達する方法は 2 つあります：

• MCP ゲートウェイ — MCP クライアント（Claude Desktop、Cursor、エージェント フレームワーク）を https://api.orcarouter.ai/api/v1/firewall/mcp に向けます。 ゲートウェイは到達可能なすべての登録済みサーバーのツールを <server>.<tool> で 名前空間化して公開し、各 tools/call をインラインで評価します。 MCP サーバーを参照。
• Evaluate フック — ツール呼び出しをディスパッチする前に、独自のエージェント ループから POST /api/v1/firewall/evaluate を呼び出し、判定に応じて動作します。

どちらもファイアウォールゲートウェイスコープのトークン — この目的のために 発行された専用の API キー — を必要とします。通常のキーはこれらのルートで 403 を 受け取ります。

​

13. API リファレンス

すべてのコンソールルートはワークスペースコンテキストを介してワークスペース スコープされ、RBAC を一貫して強制します：読み取りと test/simulate サンドボックスは すべてのメンバーに開放、書き込みは Developer+ が必要です。

​

ポリシーと設定

​

姿勢、プリセット、サンドボックス

​

可観測性

ルール、MCP サーバー、スキルはそれぞれ独自のエンドポイントを持ちます — ルール、 MCP サーバー、 スキルを参照。

​

ゲートウェイ（マシン間）

これらはコンソールセッションではなく、ファイアウォールゲートウェイスコープの トークン上で動作します：

​

14. FAQ

​

関連項目

エージェントセキュリティをさらに深く知りたいですか？ エージェントを保護する（ゼロトラスト） のガイドが、この機能をゼロトラストワークフローの中に位置づけます。