Vai al contenuto principale
Un MCP server che connetti porta tool che si protendono verso la rete — un fetch, una web_search, un poster di webhook. Il nome del tool potrebbe essere sulla tua allow-list, gli argomenti potrebbero sembrare puliti, e la chiamata finisce comunque per fare il POST dei tuoi dati verso un host controllato da un attaccante o per estrarre credenziali dall’endpoint metadata 169.254.169.254. La destinazione è la parte della chiamata che le tue regole sul nome del tool non vedono mai. Il mcp egress control chiude quella lacuna. Una regola egress dà scope a un verdetto del firewall a dove un tool arriva — un host, un IP, o un range CIDR — così lo stesso http_fetch che è consentito verso api.openai.com è negato verso tutto il resto. Gira sulla superficie egress del firewall, sopra la valutazione per chiamata che ogni tools/call già attraversa.
Questo è un task di console. Le regole del firewall vivono sulle route /api/workspace/firewall/*, che si autenticano con il tuo session / access token — non con una chiave relay sk-orca-…. Scrivere una regola richiede il ruolo Developer+.

​
1. Cosa controlla una regola egress

Una regola normale matcha sul nome del tool e sui suoi argomenti. Una regola egress aggiunge una terza dimensione: la destinazione a cui la chiamata si risolve. Imposti lo stage della regola su egress e alleghi una lista egress_json di voci allow / deny. Il motore estrae l’host di destinazione dalla chiamata e fa scattare la regola solo quando quell’host è in scope. Le voci sono matchate in tre modi:

Hostname

Match esatto case-insensitive, es. api.openai.com. Un punto finale viene rifilato su entrambi i lati.

IP letterale

Match esatto contro l’IP di dial risolto, es. 169.254.169.254.

Range CIDR

L’IP di destinazione — letterale o DNS-risolto — deve cadere dentro il blocco, es. 10.0.0.0/8.
Quando una destinazione è un hostname ma la tua lista porta voci IP/CIDR, il nome viene risolto e i suoi IP vengono ri-controllati — così metadata.internal matcha un deny 169.254.0.0/16 anche se non è listato per nome. Questa è difesa-in-profondità best-effort contro un nome che risolve in un range negato; la guardia SSRF autorevole gira comunque al layer di dial del gateway.

​
2. Un esempio concreto

Nega a ogni tool a forma di fetch di raggiungere l’endpoint cloud-metadata e i range RFC-1918. Questo è il taglio canonico della leg di esfiltrazione SSRF: un verdetto deny sullo stage egress, con scope da una denylist egress_json. 
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\"]}"
  }'
Un tools/call la cui destinazione risolve in uno qualsiasi di quei range torna al modello come un errore di tool; una chiamata a un host pubblico che la denylist non copre passa.
Le liste allow/deny invertono significato con il verdetto. Su una regola deny (o altra enforcing), la lista deny è l’insieme in-scope e allow ritaglia le esenzioni — “nega questi, eccetto quelli”. Su una regola allow i ruoli si invertono: la lista allow è l’insieme in-scope e deny ritaglia le esenzioni — “consenti solo questi”. Un egress_json non vuoto deve dichiarare almeno una voce allow o deny, o la scrittura viene rifiutata.

​
3. Mettere in allow-list una sola destinazione

L’inverso dell’esempio sopra: blocca un tool fetch su un singolo host autorizzato e lascia che il default_verdict della policy (o un catch-all successivo) gestisca il resto. Poiché questo è un verdetto allow, la lista allow è l’insieme in-scope. 
// egress_json su una regola allow-verdict, stage=egress
{ "allow": ["api.openai.com", "api.anthropic.com"] }
La regola ora scatta (consente) solo quando la destinazione è uno di quei due host. Qualsiasi altra cosa ricade sulla regola successiva — abbinala a una policy default-deny così una destinazione non listata viene rifiutata anziché lasciata passare.
Testala prima di fidartene. La tab Test della console e l’endpoint POST /api/workspace/firewall/test (Developer+) rieseguono una chiamata di esempio contro la tua bozza di policy così puoi confermare il verdetto su una destinazione nota senza inviare traffico live.

​
4. Come si compone con il resto del firewall

Una regola egress è una regola tra molte in una policy del firewall del workspace. Il motore percorre le regole in ordine di priorità (la più bassa prima) e il primo match vince, quindi metti un egress deny stretto sopra qualsiasi allow ampio.
Verdetto su una regola egressEffetto
denyBlocca la chiamata verso le destinazioni in-scope — registrata sulla superficie egress e restituita al tool come un errore.
auditLogga la chiamata matchata come un evento del firewall; fa comunque il dispatch.
allowPermette le destinazioni in-scope; si abbina a un floor default-deny.
pending_approval e cap_cost non sono applicati sulla superficie egress — egress è un controllo di destinazione, non un’attesa o un tetto di spesa. Usa quei verdetti sulle superfici mcp o inbound invece. Vedi il riferimento dei verdetti.
Due controlli correlati vale la pena cablare accanto a una regola egress:
Indipendentemente da qualsiasi regola che scrivi, il gateway MCP valida ogni endpoint di server e il suo IP di dial risolto contro una policy SSRF — i range intranet e l’indirizzo cloud-metadata sono rifiutati, e l’IP viene ri-controllato a ogni hop per sconfiggere il DNS rebinding. La tua regola egress stratifica una policy di destinazione specifica per workspace sopra quel baseline.
Un singolo egress deny ferma un tool dal raggiungere un host. Una regola di sequenza ferma la catena — es. “leggi un file, poi fai egress nella finestra” — segnalando la leg di egress solo quando segue una lettura sensibile. È il breaker della trifecta letale; lo scoping dell’egress è il controllo per chiamata.

​
5. Fai prima lo shadow, poi enforce

Far andare un egress deny direttamente all’enforcement su un workspace trafficato rischia di rompere un’integrazione legittima che hai dimenticato. Due reti di sicurezza:
  • Shadow mode. Una policy in shadow mode declassa ogni verdetto enforcing a audit — il tuo egress deny logga [shadow] would deny … invece di bloccare, così vedi il raggio dell’esplosione prima che morda.
  • Observe mode. L’impostazione del workspace firewall_observe_mode logga le chiamate non coperte come Tool Scoperti, presentando le destinazioni reali che i tuoi agent già raggiungono così puoi scrivere un’allow-list accurata dai dati invece che a indovinare.
Il matching di destinazione egress fa chiave sull’host a cui la chiamata risolve al momento della valutazione. Un server ostile può comunque ri-bindare il DNS tra il controllo della policy e il dial effettivo (TOCTOU) — che è esattamente il motivo per cui la guardia IP a layer di socket del gateway è il controllo autorevole e questa regola è difesa-in-profondità, non l’unica linea.

​
6. Ruoli e route

Tutte le route della console hanno scope a livello di workspace e si autenticano con il tuo session / access token. Le letture sono aperte a qualsiasi Member; scrivere o modificare una regola richiede Developer+.
Metodo & pathRuoloScopo
GET /api/workspace/firewall/policies/:idMemberLeggi una policy e le sue regole.
POST /api/workspace/firewall/rulesDeveloper+Aggiungi una regola (imposta stage: egress).
PUT /api/workspace/firewall/rulesDeveloper+Aggiorna una regola (id nel body).
DELETE /api/workspace/firewall/rules/:idDeveloper+Rimuovi una regola.
POST /api/workspace/firewall/testDeveloper+Riesegui una chiamata di esempio contro una bozza di policy.

​
Correlati

Riferimento delle regole del firewall

Il DSL completo delle regole — glob dei tool, matching degli argomenti, liste egress, sequenze.

Connettere un MCP server

Registra un server così le sue chiamate a tool girano dietro il firewall.

Allow-list dei tool MCP

Default-deny sui tool che non hai esplicitamente approvato.

Esfiltrazione dei dati

La minaccia che il controllo di egress è costruito per fermare.