Zum Hauptinhalt springen
Ein MCP-Server, den Sie verbinden, liefert Tools, die ins Netzwerk hinausgreifen — ein fetch, ein web_search, ein Webhook-Poster. Der Tool-Name mag auf Ihrer Allow-List stehen, die Argumente mögen sauber aussehen, und der Aufruf landet trotzdem dabei, Ihre Daten an einen angreiferkontrollierten Host zu posten oder Credentials vom 169.254.169.254-Metadata-Endpunkt zu ziehen. Das Ziel ist der Teil des Aufrufs, den Ihre Tool-Namen-Regeln nie sehen. mcp-Egress-Steuerung schließt diese Lücke. Eine Egress-Regel scopt ein Firewall-Verdikt darauf, wohin ein Tool reicht — einen Host, eine IP oder einen CIDR-Bereich — sodass derselbe http_fetch, der zu api.openai.com erlaubt ist, zu allem anderen verweigert wird. Sie läuft auf der egress-Oberfläche der Firewall, obendrauf auf der Auswertung pro Aufruf, die jeder tools/call bereits durchläuft.
Dies ist eine Konsolen-Aufgabe. Firewall-Regeln leben auf den /api/workspace/firewall/*-Routen, die mit Ihrer Session / Ihrem Access-Token authentifizieren — nicht einem sk-orca-…-Relay-Key. Das Verfassen einer Regel erfordert die Rolle Developer+.

​
1. Was eine Egress-Regel steuert

Eine normale Regel matcht auf den Tool-Namen und seine Argumente. Eine Egress-Regel fügt eine dritte Dimension hinzu: das Ziel, zu dem der Aufruf auflöst. Sie setzen die stage der Regel auf egress und hängen eine egress_json-Liste von allow- / deny-Einträgen an. Die Engine extrahiert den Ziel-Host aus dem Aufruf und feuert die Regel nur, wenn dieser Host im Scope ist. Einträge werden auf drei Arten gematcht:

Hostname

Case-insensitiver exakter Match, z. B. api.openai.com. Ein nachfolgender Punkt wird auf beiden Seiten getrimmt.

IP-Literal

Exakter Match gegen die aufgelöste Dial-IP, z. B. 169.254.169.254.

CIDR-Bereich

Die Ziel-IP — literal oder DNS-aufgelöst — muss in den Block fallen, z. B. 10.0.0.0/8.
Wenn ein Ziel ein Hostname ist, Ihre Liste aber IP/CIDR-Einträge trägt, wird der Name aufgelöst und seine IPs werden neu geprüft — sodass metadata.internal ein 169.254.0.0/16-deny matcht, auch wenn es nicht namentlich gelistet ist. Dies ist Best-Effort-Defense-in-Depth gegen einen Namen, der in einen verweigerten Bereich auflöst; die maßgebliche SSRF-Wache läuft weiterhin auf der Dial-Ebene des Gateways.

​
2. Ein konkretes Beispiel

Verweigern Sie jedem fetch-förmigen Tool, den Cloud-Metadata-Endpunkt und RFC-1918-Bereiche zu erreichen. Das ist der kanonische SSRF-Exfil-Leg-Schnitt: ein deny-Verdikt auf der egress-Stage, gescopt durch eine egress_json-Denylist. 
curl https://api.orcarouter.ai/api/workspace/firewall/rules \
  -H "Authorization: Bearer <your-session-or-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "policy_id": 12,
    "priority": 10,
    "label": "Deny SSRF / metadata egress",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny",
    "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"]}"
  }'
Ein tools/call, dessen Ziel in einen dieser Bereiche auflöst, kommt zum Modell zurück als Tool-Fehler; ein Aufruf zu einem öffentlichen Host, den die Denylist nicht abdeckt, geht durch.
Die allow/deny-Listen kippen ihre Bedeutung mit dem Verdikt. Bei einer deny-(oder anderen durchsetzenden) Regel ist die deny-Liste der In-Scope- Satz und allow schnitzt Ausnahmen heraus — „verweigere diese, außer jene”. Bei einer allow-Regel kehren sich die Rollen um: die allow-Liste ist der In-Scope-Satz und deny schnitzt Ausnahmen heraus — „erlaube nur diese”. Ein nicht leeres egress_json muss mindestens einen allow- oder deny-Eintrag deklarieren, sonst wird der Schreibvorgang abgelehnt.

​
3. Nur ein Ziel per Allow-List

Die Umkehrung des Beispiels oben: pinnen Sie ein fetch-Tool auf einen einzigen sanktionierten Host und lassen Sie das default_verdict der Policy (oder ein späteres Catch-all) den Rest erledigen. Weil dies ein allow-Verdikt ist, ist die allow-Liste der In-Scope-Satz. 
// egress_json on an allow-verdict, stage=egress rule
{ "allow": ["api.openai.com", "api.anthropic.com"] }
Die Regel feuert nun (erlaubt) nur, wenn das Ziel einer dieser beiden Hosts ist. Alles andere fällt durch zur nächsten Regel — paaren Sie dies mit einer Default-Deny-Policy, sodass ein nicht gelistetes Ziel verweigert statt durchgewunken wird.
Testen Sie es, bevor Sie ihm vertrauen. Der Test-Tab der Konsole und der POST /api/workspace/firewall/test-Endpunkt (Developer+) spielen einen Beispiel-Aufruf gegen Ihre Entwurfs-Policy ab, sodass Sie das Verdikt für ein bekanntes Ziel bestätigen können, ohne Live-Traffic zu senden.

​
4. Wie es sich mit dem Rest der Firewall zusammensetzt

Eine Egress-Regel ist eine Regel unter vielen in einer Workspace-Firewall-Policy. Die Engine durchläuft Regeln in Prioritätsreihenfolge (niedrigste zuerst), und der erste Match gewinnt, also platzieren Sie ein enges Egress-deny über jedes breite allow.
Verdikt bei einer Egress-RegelEffekt
denyBlockiert den Aufruf zu In-Scope-Zielen — aufgezeichnet auf der egress-Oberfläche und an das Tool als Fehler zurückgegeben.
auditLoggt den gematchten Aufruf als Firewall-Event; dispatcht trotzdem.
allowErlaubt In-Scope-Ziele; paart sich mit einem Default-Deny-Boden.
pending_approval und cap_cost werden auf der egress-Oberfläche nicht durchgesetzt — Egress ist eine Ziel-Prüfung, keine Zurückhaltung oder ein Ausgaben-Cap. Verwenden Sie diese Verdikte stattdessen auf den mcp- oder inbound-Oberflächen. Siehe die Verdikt-Referenz.
Zwei verwandte Controls sind es wert, neben einer Egress-Regel verdrahtet zu werden:
Unabhängig von jeder Regel, die Sie verfassen, validiert das MCP-Gateway jeden Server-Endpunkt und seine aufgelöste Dial-IP gegen eine SSRF-Policy — Intranet-Bereiche und die Cloud-Metadata-Adresse werden verweigert, und die IP wird bei jedem Hop neu geprüft, um DNS-Rebinding abzuwehren. Ihre Egress-Regel schichtet eine workspace-spezifische Ziel-Policy obendrauf auf diese Baseline.
Ein einzelnes Egress-deny stoppt ein Tool, das einen Host erreicht. Eine Sequenz-Regel stoppt die Kette — z. B. „eine Datei lesen, dann innerhalb des Fensters egressen” — indem sie den Egress-Leg nur dann markiert, wenn er auf einen sensiblen Read folgt. Das ist der Lethal-Trifecta-Breaker; das Egress-Scoping ist das Control pro Aufruf.

​
5. Erst im Shadow, dann durchsetzen

Ein Egress-deny direkt in die Durchsetzung auf einem geschäftigen Workspace zu rollen, riskiert, eine legitime Integration zu brechen, die Sie vergessen haben. Zwei Sicherheitsnetze:
  • Shadow-Modus. Eine Policy im Shadow-Modus stuft jedes durchsetzende Verdikt auf audit herunter — Ihr Egress-deny loggt [shadow] would deny … statt zu blockieren, sodass Sie den Wirkungsradius sehen, bevor er zubeißt.
  • Observe-Modus. Die Workspace-Einstellung firewall_observe_mode loggt nicht abgedeckte Aufrufe als Discovered Tools und bringt die echten Ziele, die Ihre Agenten bereits erreichen, an die Oberfläche, sodass Sie eine genaue Allow-List aus Daten statt aus Mutmaßungen schreiben können.
Das Egress-Ziel-Matching schlüsselt auf den Host, zu dem der Aufruf zur Auswertungszeit auflöst. Ein feindseliger Server kann DNS immer noch zwischen der Policy-Prüfung und dem tatsächlichen Anwählen neu binden (TOCTOU) — was genau der Grund ist, warum die Socket-Ebenen-IP-Wache des Gateways das maßgebliche Control ist und diese Regel Defense-in-Depth ist, nicht die einzige Linie.

​
6. Rollen und Routen

Alle Konsolen-Routen sind workspace-bezogen und authentifizieren mit Ihrer Session / Ihrem Access-Token. Lesevorgänge sind für jedes Member offen; das Verfassen oder Bearbeiten einer Regel erfordert Developer+.
Methode & PfadRolleZweck
GET /api/workspace/firewall/policies/:idMemberEine Policy und ihre Regeln lesen.
POST /api/workspace/firewall/rulesDeveloper+Eine Regel hinzufügen (stage: egress setzen).
PUT /api/workspace/firewall/rulesDeveloper+Eine Regel aktualisieren (id im Body).
DELETE /api/workspace/firewall/rules/:idDeveloper+Eine Regel entfernen.
POST /api/workspace/firewall/testDeveloper+Einen Beispiel-Aufruf gegen eine Entwurfs-Policy abspielen.

​
Verwandt

Firewall-Regel-Referenz

Das vollständige Regel-DSL — Tool-Globs, Args-Matching, Egress-Listen, Sequenzen.

Einen MCP-Server verbinden

Registrieren Sie einen Server, sodass seine Tool-Calls hinter der Firewall laufen.

MCP-Tools per Allow-List freigeben

Default-Deny der Tools, die Sie nicht explizit genehmigt haben.

Datenexfiltration

Die Bedrohung, die die Egress-Steuerung stoppen soll.