Vai al contenuto principale
Quando un agent chiama http_fetch, web_search o qualsiasi tool che apre una connessione in uscita, la destinazione è la parte che hai più bisogno di governare. Un agent confuso o dirottato che può raggiungere 169.254.169.254 legge le tue credenziali cloud; uno che può fare POST verso un host attaccante esfiltra i tuoi dati. Il controllo dell’egress degli agent governa quella destinazione — scrivi una regola di allow/deny per host/CIDR sulla superficie egress del firewall, la colleghi a una chiave, e il gateway controlla ogni destinazione in uscita che un tool di un agent riporta prima che la chiamata parta. Questa è una pagina focalizzata su un caso d’uso. Per la grammatica completa delle regole e la semantica dei verdetti vedi Schema delle regole e Verdetti; per come l’egress si colloca tra gli altri punti di applicazione vedi Stage.

​
1. Controllo dell’egress sulla superficie egress

Delle quattro superfici del firewall, egress è quella che vede la destinazione di rete in uscita che un tool riporta — un host, un IP letterale o un CIDR. Una regola fissata a stage: egress fa matching su quella destinazione, non sul nome del tool o sui suoi argomenti, il che la rende il controllo di SSRF ed esfiltrazione di dati: risponde a dove può arrivare questo agent, indipendentemente da quale tool è arrivato lì.
L’egress è scoping della destinazione, non blocco dei tool. Per impedire del tutto l’esistenza di un tool, negalo per nome sulla superficie inbound (Blocca i tool). Il controllo dell’egress assume che il tool possa legittimamente fare fetch — vincola solo verso dove.

​
2. Un esempio: nega le destinazioni SSRF

La regola egress canonica nega l’endpoint cloud metadata e i range privati RFC-1918 — le destinazioni che un tool a forma di fetch non dovrebbe mai raggiungere. Nella console del tuo workspace, apri una policy e aggiungi una regola con stage egress, verdetto deny e un elenco 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 è una stringa codificata in JSON che porta gli elenchi di host/CIDR — decodificata, è {"deny": [...], "allow": [...]}. Ogni voce fa match come un CIDR, un IP letterale o un hostname case-insensitive. Per un verdetto deny l’elenco deny è l’insieme nello scope (le destinazioni che la regola blocca) e l’elenco allow ne ricava eccezioni — così la regola sopra blocca i quattro range ma lascia passare api.openai.com anche se dovesse mai risolversi in uno di essi. Quando una destinazione è un hostname anziché un IP letterale e il tuo elenco porta voci IP/CIDR, il nome viene risolto best-effort e i suoi indirizzi ri-controllati, così metadata.internal corrisponde comunque a un deny 169.254.0.0/16 anche se non è elencato per nome.
Per una postura allow-list invece — permetti solo un insieme nominato di destinazioni e blocca il resto — scrivi la regola con verdetto allow e metti le tue destinazioni nell’elenco allow. La polarità si inverte: allow diventa l’insieme nello scope e deny ne ricava eccezioni. Abbinala a un default_verdict della policy di deny così tutto ciò che la regola di allow non copre viene bloccato.

​
3. Le regole CIDR le scrivi tu — nessun preset le include

Non c’è alcun elenco CIDR preset. OrcaRouter non include una regola integrata che neghi 169.254.169.254, RFC-1918 o qualsiasi altro range. La regola di allow/deny CIDR è tua da scrivere — è l’esempio in §2, scritto da te contro la tua rete. Copiala, poi adatta i range e le eccezioni dell’allow-list al tuo ambiente.
Ciò che il livello di autonomia tight e il suo preset block_ssrf_egress includono è un insieme di deny sui nomi di tool a forma di fetch — http_fetch, web_search, fetch_url, request, più le loro varianti MCP <server>.<tool>. È una postura contundente: rifiuta del tutto i tool a forma di egress anziché dare scope a dove possono arrivare. Ricorrivi quando un agent non ha alcun motivo di fare chiamate di rete; ricorri a una regola sulla destinazione (§2) quando fa fetch ma solo da un insieme approvato di host.
ApproccioCosa vincolaAutore
Preset SSRF tightI nomi di tool a forma di fetch (li nega)Integrato
Regola egress CIDR/hostLa destinazione che un fetch può raggiungereTu

​
4. Com’è fatto un egress bloccato

Quando una destinazione corrisponde a una regola egress applicativa, la chiamata viene negata prima che lasci il gateway e la valutazione è registrata come un evento del firewall con superficie egress e verdetto deny. In shadow mode il deny viene declassato a audit con la motivazione prefissata [shadow] would …, così puoi misurare esattamente quali destinazioni una regola bloccherebbe contro il traffico reale prima di applicarla.
Un elenco egress malformato o senza voci è trattato in modo conservativo: una regola deny applicativa governa comunque (un refuso non può silenziosamente impedirle di bloccare), ma una regola allow con un elenco rotto non scatta — altrimenti un’allow-list digitata male diventerebbe allow-all e oscurerebbe un deny di default. Le nuove regole sono validate al salvataggio (l’elenco deve dichiarare almeno una voce di allow o deny), quindi questo protegge solo le righe legacy.

​
5. Scrivi dal traffico reale, poi fai il rollout

Il log degli eventi registra l’host di destinazione su ogni evento di superficie egress (egress_host/egress_url), quindi filtralo sulla superficie egress e scrivi il tuo elenco di deny dalle destinazioni che sono effettivamente comparse anziché tirare a indovinare. La scheda Discovered Tools è un’aggregazione per-nome-di-tool (nomi di tool e le superfici su cui hanno scattato) — ti dice quali tool a forma di fetch hanno girato, non gli host che hanno raggiunto. Vedi Analytics.
La scheda Test della console esegue un dry-run di una policy contro un tool_name + superficie (+ args opzionali) di esempio e restituisce il verdetto, la regola corrispondente e la motivazione — nulla viene dispatchato. Conferma quale regola una chiamata risolve; per confermare la tua matematica CIDR/host contro destinazioni reali, usa la shadow mode sotto (il payload di Test non porta una destinazione, quindi il matching dell’elenco egress è esercitato sul traffico egress live). Vedi Testa le regole.
Attiva la shadow mode e il deny egress viene loggato come scatterebbe senza bloccare. Osserva il log degli eventi filtrato sulla superficie egress, conferma che catturi le destinazioni che ti aspetti, poi disattiva lo shadow.
Lo scoping della destinazione al gateway è difesa in profondità, non l’ultima linea. L’IP a cui un hostname si risolve al momento della valutazione può differire da quello che un tool effettivamente compone (DNS rebinding). Mantieni un controllo di IP-deny anche al tuo livello di egress/dialer; la regola del gateway è la cattura economica pre-flight per i casi ovvi.

​
6. Collega la policy e chi può modificarla

Una policy non fa nulla finché una chiave non si risolve su di essa. Collegala nella console impostando firewall_policy_id sulla chiave, o rendi la policy il default del workspace. La risoluzione è: la policy collegata alla chiave (quando esiste ed è abilitata), altrimenti il default del workspace. Tutta la configurazione delle regole egress gira nella console sotto la tua sessione (/api/workspace/firewall/*):
AzioneRuolo
Leggere policy, preset, discovered tools, Simulate dell’autonomiaMember
Creare / modificare / eliminare regole egress e policyDeveloper+
Endpoint Test di dry-run (POST /test)Developer+
Leggere il log degli eventi e le aggregazioni delle esecuzioniDeveloper+

​
Correlati

Esfiltrazione di dati

La minaccia che il controllo dell’egress affronta.

Stage

Le quattro superfici, e dove si colloca l’egress.

Verdetti

Cosa fanno deny, audit e allow sul filo.

Blocca i tool

Nega un fetch tool per nome anziché per destinazione.

Chiamate a tool pericolose

La classe di rischio più ampia.

Riferimento del firewall

Il riferimento completo di regole + matching, inclusi gli elenchi egress.