Zum Hauptinhalt springen
Wenn ein Agent http_fetch, web_search oder ein beliebiges Tool aufruft, das eine ausgehende Verbindung öffnet, ist das Ziel der Teil, den Sie am dringendsten steuern müssen. Ein verwirrter oder gekaperter Agent, der 169.254.169.254 erreichen kann, liest Ihre Cloud-Credentials; einer, der an einen Angreifer-Host POSTen kann, exfiltriert Ihre Daten. Agent-Egress-Kontrolle steuert dieses Ziel — Sie verfassen eine Host/CIDR-Allow/Deny-Regel auf der egress-Surface der Firewall, hängen sie an einen Key, und das Gateway prüft jedes ausgehende Ziel, das das Tool eines Agenten meldet, bevor der Aufruf hinausgeht. Dies ist eine fokussierte Use-Case-Seite. Für die vollständige Regel-Grammatik und Verdikt-Semantik siehe Regel-Schema und Verdikte; dafür, wie Egress unter den anderen Enforcement-Punkten sitzt, siehe Stages.

​
1. Agent-Egress-Kontrolle auf der egress-Surface

Von den vier Surfaces der Firewall ist egress diejenige, die das ausgehende Netzwerkziel sieht, das ein Tool meldet — einen Host, ein IP-Literal oder ein CIDR. Eine auf stage: egress gepinnte Regel matcht auf diesem Ziel, nicht auf dem Tool-Namen oder seinen Argumenten, was sie zur SSRF- und Datenexfiltrations-Kontrolle macht: Sie beantwortet, wohin dieser Agent reichen kann, unabhängig davon, welches Tool das Reichen getan hat.
Egress ist Ziel-Scoping, kein Tool-Blocking. Um zu verhindern, dass ein Tool überhaupt existiert, verweigern Sie es nach Namen auf der inbound-Surface (Tools blockieren). Egress-Kontrolle nimmt an, dass das Tool legitim abrufen darf — sie beschränkt nur, wohin.

​
2. Ein Beispiel: die SSRF-Ziele verweigern

Die kanonische Egress-Regel verweigert den Cloud-Metadaten-Endpunkt und die privaten RFC-1918-Bereiche — die Ziele, die ein fetch-förmiges Tool nie erreichen sollte. Öffnen Sie in Ihrer Workspace-Konsole eine Policy und fügen Sie eine Regel mit stage egress, Verdikt deny und einer Egress-Liste hinzu: 
{
  "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 ist ein JSON-kodierter String, der die Host/CIDR-Listen trägt — dekodiert ist es {"deny": [...], "allow": [...]}. Jeder Eintrag matcht als CIDR, als IP-Literal oder als case-insensitiver Hostname. Für ein deny-Verdikt ist die deny-Liste die In-Scope-Menge (Ziele, die die Regel blockiert), und die allow-Liste schnitzt Ausnahmen heraus — sodass die obige Regel die vier Bereiche blockiert, aber api.openai.com durchlässt, selbst wenn es je in einen davon auflöste. Wenn ein Ziel ein Hostname statt eines literalen IP ist und Ihre Liste IP/CIDR-Einträge trägt, wird der Name nach bestem Bemühen aufgelöst und seine Adressen werden neu geprüft, sodass metadata.internal immer noch ein 169.254.0.0/16-deny matcht, obwohl es nicht namentlich gelistet ist.
Für eine Allow-List-Haltung stattdessen — nur eine benannte Menge von Zielen erlauben und den Rest blockieren — schreiben Sie die Regel mit Verdikt allow und setzen Ihre Ziele in die allow-Liste. Die Polarität kippt: allow wird die In-Scope-Menge und deny schnitzt Ausnahmen heraus. Paaren Sie es mit einem Policy-default_verdict von deny, sodass alles, was die Allow-Regel nicht abdeckt, blockiert wird.

​
3. Sie verfassen die CIDR-Regeln — kein Preset liefert sie

Es gibt keine Preset-CIDR-Liste. OrcaRouter liefert keine eingebaute Regel, die 169.254.169.254, RFC-1918 oder irgendeinen anderen Bereich verweigert. Die CIDR-Allow/Deny-Regel ist Ihre, um sie zu verfassen — es ist das Beispiel in §2, von Ihnen gegen Ihr eigenes Netzwerk geschrieben. Kopieren Sie es und passen Sie dann die Bereiche und die Allow-List-Ausnahmen an Ihre Umgebung an.
Was das tight-Autonomie-Level und sein block_ssrf_egress-Preset liefern, ist eine Menge von Denies auf den fetch-förmigen Tool-Namen — http_fetch, web_search, fetch_url, request plus ihren <server>.<tool>-MCP-Varianten. Das ist eine grobe Haltung: Sie verweigert die egress-förmigen Tools rundheraus, statt zu scopen, wohin sie reichen dürfen. Greifen Sie dazu, wenn ein Agent überhaupt nichts mit Netzwerk-Aufrufen zu tun hat; greifen Sie zu einer Ziel-Regel (§2), wenn er doch abruft, aber nur von einer genehmigten Menge von Hosts.
AnsatzWas es beschränktVerfasser
tight-SSRF-PresetFetch-förmige Tool-Namen (verweigert sie)Eingebaut
Egress-CIDR/Host-RegelDas Ziel, das ein Fetch erreichen darfSie

​
4. Wie ein blockierter Egress aussieht

Wenn ein Ziel auf eine durchsetzende Egress-Regel matcht, wird der Aufruf verweigert, bevor er das Gateway verlässt, und die Auswertung wird als Firewall-Event mit Surface egress und Verdikt deny aufgezeichnet. Im Shadow-Mode wird das deny auf audit herabgestuft, mit dem Grund vorangestellt [shadow] would …, sodass Sie genau messen können, welche Ziele eine Regel gegen echten Traffic blockieren würde, bevor Sie sie durchsetzen.
Eine fehlerhafte oder eintragslose Egress-Liste wird konservativ behandelt: Eine durchsetzende deny-Regel gatet trotzdem (ein Tippfehler kann sie nicht stillschweigend am Blockieren hindern), aber eine allow-Regel mit einer kaputten Liste feuert nicht — andernfalls würde eine vertippte Allow-List zu Allow-all und ein Default-Deny überschatten. Neue Regeln werden beim Speichern validiert (die Liste muss mindestens einen allow- oder deny-Eintrag deklarieren), sodass dies nur jemals Legacy-Zeilen absichert.

​
5. Aus echtem Traffic verfassen, dann ausrollen

Der Events-Log zeichnet den Ziel-Host auf jedem egress-Surface-Event auf (egress_host/egress_url), filtern Sie ihn also auf Surface egress und verfassen Sie Ihre Deny-Liste aus den Zielen, die tatsächlich auftauchten, statt zu raten. Der Discovered Tools-Tab ist ein Pro-Tool-Namen-Rollup (Tool-Namen und die Surfaces, auf denen sie feuerten) — er sagt Ihnen, welche fetch-förmigen Tools liefen, nicht die Hosts, die sie erreichten. Siehe Analytics.
Der Test-Tab der Konsole macht einen Dry-Run einer Policy gegen einen Beispiel-tool_name + Surface (+ optionale Args) und gibt das Verdikt, die gematchte Regel und den Grund zurück — nichts wird dispatcht. Er bestätigt, welche Regel ein Aufruf auflöst; um Ihre CIDR/Host-Mathematik gegen echte Ziele zu bestätigen, verwenden Sie den Shadow-Mode unten (die Test-Payload trägt kein Ziel, sodass das Egress-Listen-Matching auf Live-Egress-Traffic ausgeübt wird). Siehe Regeln testen.
Schalten Sie den Shadow-Mode ein, und das Egress-deny wird geloggt, wie es feuern würde, ohne zu blockieren. Beobachten Sie den Events-Log gefiltert auf Surface egress, bestätigen Sie, dass er die Ziele abfängt, die Sie erwarten, und schalten Sie dann den Shadow-Mode aus.
Ziel-Scoping am Gateway ist Defense-in-Depth, nicht die letzte Linie. Die IP, in die ein Hostname zur Auswertungszeit auflöst, kann von der abweichen, die ein Tool tatsächlich anwählt (DNS-Rebinding). Halten Sie auch auf Ihrer eigenen Egress-/Dialer-Ebene eine IP-Deny-Kontrolle vor; die Gateway-Regel ist der günstige Pre-Flight-Fang für die offensichtlichen Fälle.

​
6. Die Policy anhängen und wer sie bearbeiten kann

Eine Policy tut nichts, bis ein Key auf sie auflöst. Hängen Sie sie in der Konsole an, indem Sie firewall_policy_id auf dem Key setzen, oder machen Sie die Policy zum Workspace-Default. Die Auflösung ist: die angehängte Policy des Keys (wenn sie existiert und aktiviert ist), sonst der Workspace-Default. Alle Egress-Regel-Konfigurationen laufen in der Konsole unter Ihrer Session (/api/workspace/firewall/*):
AktionRolle
Policies, Presets, Discovered Tools, Autonomie-Simulate lesenMember
Egress-Regeln und Policies erstellen / bearbeiten / löschenDeveloper+
Dry-Run-Test-Endpunkt (POST /test)Developer+
Den Events-Log und Run-Aggregate lesenDeveloper+

​
Verwandt

Datenexfiltration

Die Bedrohung, die Egress-Kontrolle adressiert.

Stages

Die vier Surfaces und wo Egress sitzt.

Verdikte

Was deny, audit und allow auf der Leitung tun.

Tools blockieren

Ein Fetch-Tool nach Namen statt nach Ziel verweigern.

Gefährliche Tool-Calls

Die breitere Risikoklasse.

Firewall-Referenz

Die vollständige Regel- + Matching-Referenz, einschließlich Egress-Listen.