メインコンテンツへスキップ
エージェントが http_fetch、web_search、またはアウトバウンド接続を開く任意の ツールを呼び出すとき、宛先こそ最も統制する必要のある部分です。169.254.169.254 に 到達できる混乱したまたは乗っ取られたエージェントは、あなたのクラウド認証情報を読み ます；攻撃者ホストに POST できるものは、あなたのデータを持ち出します。エージェント egress 制御はその宛先を統制します — ファイアウォールの egress サーフェスで host/CIDR の allow/deny ルールを作成し、キーにアタッチすると、ゲートウェイは呼び出しが 出ていく前にエージェントのツールが報告するすべてのアウトバウンド宛先をチェック します。 これは焦点を絞ったユースケースページです。完全なルール文法と判定セマンティクスに ついてはルールスキーマと 判定を；egress が他の強制ポイントの中にどう位置するか についてはステージを参照してください。

​
1. egress サーフェス上のエージェント egress 制御

ファイアウォールの 4 つのサーフェスのうち、egress はツールが報告するアウトバウンドネットワーク宛先 — ホスト、IP リテラル、または CIDR — を見るものです。stage: egress に固定されたルールは、ツール名やその引数では なくその宛先にマッチし、それを SSRF とデータ持ち出しの制御にします：このエージェントが どこに到達できるかに答えます — どのツールが到達したかとは独立して。
egress は宛先スコーピングであり、ツールブロッキングではありません。ツールが そもそも存在するのを止めるには、inbound サーフェスでそれを名前で deny します （ツールをブロック）。egress 制御はツールが 正当にフェッチするかもしれないと仮定します — どこへを制約するだけです。

​
2. 例 1 つ：SSRF 宛先を deny

典型的な egress ルールは、クラウドメタデータエンドポイントとプライベートな RFC-1918 範囲 — フェッチ形のツールが決して到達してはならない宛先 — を deny します。ワーク スペースコンソールでポリシーを開き、stage egress、判定 deny、そして egress リストを持つルールを追加します： 
{
  "label": "deny SSRF destinations",
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"],\"allow\":[\"api.openai.com\"]}"
}
egress_json は host/CIDR リストを運ぶ JSON エンコードされた文字列です — デコードすると {"deny": [...], "allow": [...]} です。各エントリは CIDR、 IP リテラル、または大文字小文字を区別しないホスト名としてマッチします。 deny 判定では deny リストがスコープ内のセット（ルールがブロックする宛先）であり、 allow リストがそこから例外を切り出します — そのため上記のルールは 4 つの範囲を ブロックしますが、api.openai.com がそのうちのひとつに解決されたとしても通します。 宛先がリテラル IP ではなくホスト名で、リストが IP/CIDR エントリを運ぶ場合、名前は ベストエフォートで解決され、そのアドレスが再チェックされるため、metadata.internal は名前でリストされていなくても依然として 169.254.0.0/16 の deny にマッチします。
代わりに許可リストの姿勢にするには — 名指しの宛先セットのみを許可し、残りを ブロック — ルールを判定 allow で書き、宛先を allow リストに入れます。極性が反転 します：allow がスコープ内のセットになり、deny が例外を切り出します。ポリシーの default_verdict を deny と組み合わせて、allow ルールがカバーしないものがブロック されるようにします。

​
3. CIDR ルールはあなたが作成する — プリセットは出荷しない

プリセット CIDR リストはありません。 OrcaRouter は 169.254.169.254、RFC-1918、 または他の任意の範囲を deny する組み込みルールを出荷しません。CIDR の allow/deny ルールはあなたが作成するものです — それは §2 の例で、あなた自身のネットワークに 対してあなたが書きます。それをコピーし、範囲と allow リスト例外をあなたの環境に合わせて 調整してください。
tight 自律性レベルとその block_ssrf_egress プリセットが出荷するのは、フェッチ形のツール名 — http_fetch、web_search、 fetch_url、request、加えてそれらの <server>.<tool> MCP バリアント — に対する deny のセットです。それは鈍い姿勢です：egress 形のツールがどこに到達できるかを スコープするのではなく、それらを完全に拒否します。エージェントがそもそもネットワーク 呼び出しをする必要がないときはそれに手を伸ばします；フェッチはするが承認済みの ホストセットからのみのときは宛先ルール（§2）に手を伸ばします。
アプローチ何を制約するか作成者
tight SSRF プリセットフェッチ形のツール名（それらを deny）組み込み
Egress CIDR/host ルールフェッチが到達できる宛先あなた

​
4. ブロックされた egress がどう見えるか

宛先が強制 egress ルールにマッチすると、呼び出しはゲートウェイを離れる前に deny され、 評価はサーフェス egress、判定 deny のファイアウォールイベントとして記録されます。 シャドウモードでは deny は理由に [shadow] would … が前置された audit に格下げされるため、強制する前に、ルールが 実トラフィックに対してどの宛先をブロックするであろうかを正確に測定できます。
不正な形または entry のない egress リストは保守的に扱われます：強制 deny ルールは 依然としてゲートします（タイプミスがサイレントにそれのブロックを止められません）が、 壊れたリストを持つ allow ルールは発火しません — さもなければ打ち間違えた許可 リストが allow-all になり、デフォルト deny をシャドウするでしょう。新しいルールは 保存時に検証されるため（リストは少なくとも 1 つの allow または deny エントリを宣言 しなければなりません）、これはレガシー行のみを保護します。

​
5. 実トラフィックから作成し、それからロールアウト

events ログは各 egress サーフェスイベントで 宛先ホストを記録するため（egress_host/egress_url）、それをサーフェス egress でフィルタし、推測するのではなく実際に現れた宛先から deny リストを作成します。 Discovered Tools タブはツール名ごとのロールアップ（ツール名とそれらが発火した サーフェス）です — どのフェッチ形のツールが実行されたかを教えますが、それらが 到達したホストは教えません。分析を参照。
コンソールの Test タブはサンプルの tool_name + サーフェス（+ オプションの args）に対してポリシーをドライランし、判定、マッチしたルール、理由を返します — 何もディスパッチされません。呼び出しがどのルールに解決するかを確認します； CIDR/host の計算を実宛先に対して確認するには、下記のシャドウモードを使います （Test ペイロードは宛先を運ばないため、egress リストマッチングはライブの egress トラフィックで行使されます）。ルールのテストを参照。
シャドウモードをオンにすると、egress deny は ブロックせずに発火するであろうものとしてログされます。サーフェス egress で フィルタしたevents ログを監視し、期待する宛先を 捕捉することを確認してから、シャドウをオフにします。
ゲートウェイでの宛先スコーピングは多層防御であり、最後の線ではありません。評価時に ホスト名が解決される IP は、ツールが実際にダイヤルするものと異なる可能性があります （DNS リバインディング）。独自の egress/dialer 層にも IP-deny 制御を維持してください； ゲートウェイルールは明白なケースのための安価なプリフライトキャッチです。

​
6. ポリシーをアタッチし、誰が編集できるか

ポリシーはキーがそれに解決するまで何もしません。コンソールで キーに firewall_policy_id を設定してアタッチ するか、ポリシーをワークスペースデフォルトにします。解決は：キーのアタッチ済み ポリシー（存在し有効である場合）、そうでなければワークスペースデフォルト。 すべての egress ルール設定はセッション下のコンソールで実行されます （/api/workspace/firewall/*）：
アクションロール
ポリシー、プリセット、discovered tools、自律性 Simulate の読み取りMember
egress ルールとポリシーの作成 / 編集 / 削除Developer+
ドライラン Test エンドポイント（POST /test）Developer+
events ログと実行集計の読み取りDeveloper+

​
関連

データ持ち出し

egress 制御が対処する脅威。

ステージ

4 つのサーフェスと、egress がどこに位置するか。

判定

deny、audit、allow がワイヤー上で何をするか。

ツールをブロック

宛先ではなく名前でフェッチツールを deny。

危険なツール呼び出し

より広いリスククラス。

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

egress リストを含む完全なルール + マッチングリファレンス。