Vai al contenuto principale
Una regola del firewall scatta in un punto specifico del ciclo di vita di una chiamata a tool. Quel punto è il suo stage — una di quattro superfici di applicazione, ognuna delle quali vede una fetta diversa della chiamata. Fissa una regola allo stage sbagliato e vede i dati sbagliati: una allowlist di egress sulla superficie inbound non ha alcuna destinazione da controllare; una clausola sugli argomenti su inbound non ha ancora argomenti al momento della chiamata. Questa pagina è la guida focalizzata ai quattro stage dell’agent firewall: cosa osserva ciascuna superficie, quando una regola dovrebbe puntarvi, e l’unico modo concreto in cui lo stesso intento viene espresso a stage diversi. Per il vocabolario completo delle regole, vedi Regole del Firewall; per il modello di policy che lo circonda, Firewall.

​
1. I quattro stage in breve

Ogni valutazione è marcata con esattamente uno stage. Una regola senza stage ("") si applica a tutti; una regola fissata a uno stage scatta solo lì.
StageCosa vede la superficie
inboundI tool che l’agent pubblicizza sulla richiesta
responseI tool_calls che il modello emette nella sua risposta
mcpUn tools/call dispatchato attraverso il gateway MCP
egressUn host / IP / CIDR in uscita che un tool raggiunge
I nomi degli stage sono valori enum stabili — li imposti verbatim nel campo stage dell’editor delle regole, o come proprietà stage quando scrivi tramite l’API.
Lo stage governa quali dati sono nello scope, non quanto è severo il verdetto. Un deny è un deny su qualsiasi stage; ciò che cambia è se la regola ha gli argomenti, il nome del tool o la destinazione su cui deve fare matching.

​
2. inbound — i tool che un agent pubblicizza

La superficie più precoce. Prima ancora che il modello giri, il tuo agent invia un elenco di definizioni di tool che è disposto a far chiamare al modello. Lo stage inbound vede quell’insieme di tool pubblicizzato e può bloccare un tool pericoloso prima ancora che il modello possa sceglierlo. Non ci sono argomenti al momento della chiamata a questo stage — il modello non ha ancora deciso come chiamare nulla — quindi le regole inbound fanno matching sul nome del tool (e opzionalmente sulla skill proprietaria), non su args_match_json.
Un verdetto sanitize su inbound non ha nulla da redigere (non esistono ancora argomenti), quindi escala a un block. Scrivi le regole inbound come allow / deny espliciti, e riserva sanitize per gli stage di esecuzione.
Una chiamata negata qui restituisce HTTP 400 con codice firewall_blocked, nominata in base al tool e alla motivazione, e marcata skip-retry.

​
3. response — le chiamate a tool che il modello emette

Una volta che il modello risponde, può emettere uno o più tool_calls — invocazioni concrete con argomenti reali. Lo stage response li vede, quindi è qui che appartengono le regole a livello di argomento: non “blocca shell.exec” ma “blocca shell.exec solo quando il comando è rm -rf.” 
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
Poiché gli argomenti scelti dal modello sono presenti, sanitize funziona qui — redige le sottostringhe corrispondenti dagli argomenti della chiamata e inoltra la chiamata ripulita. (Sanitize redige solo gli argomenti della chiamata a tool; non tocca mai il contenuto che un tool restituisce.)

​
4. mcp — chiamate dispatchate attraverso il gateway

Quando un agent raggiunge un tool attraverso il gateway MCP di OrcaRouter, ogni tools/call viene valutato sullo stage mcp prima di essere dispatchato al server registrato. Questa è la superficie che governa il traffico Model Context Protocol — lo stesso vocabolario di glob / argomenti / verdetto di response, applicato al dispatch MCP. Un block qui compare come un errore di tool (firewall deny: <reason>) anziché un fallimento di trasporto, così il modello vede il rifiuto e può reagire — scegliere un altro tool, chiedere all’utente o fermarsi.
Lo stage mcp si abbina alla governance per-server: ogni MCP server registrato ha la propria health probe e credenziali cifrate, e le skill caricate attraverso di esso portano una fascia di rischio e una modalità di applicazione. Vedi Firewall MCP e Skill del firewall.

​
5. egress — la destinazione in uscita che un tool raggiunge

L’ultima superficie. Quando un tool riporta una destinazione di rete in uscita, lo stage egress vi fa matching — la superficie di SSRF ed esfiltrazione di dati. Le regole egress non fanno matching solo su un pattern del nome di un tool; fanno matching su un elenco di host / IP / CIDR: 
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\"],\"allow\":[\"api.openai.com\"]}"
}
Le voci fanno match come un CIDR, un IP letterale o un hostname case-insensitive. Scrivi tu stesso le regole di deny per host e CIDR — l’endpoint cloud-metadata (169.254.169.254) e i range RFC-1918 sono le cose canoniche da negare. Vedi Regole del Firewall §6 per la polarità allow/deny.
Nessun preset include regole CIDR. La postura SSRF del livello di autonomia tight livello di autonomia nega nomi di tool a forma di fetch (es. http_fetch, web_search, fetch_url); un deny di egress basato sulla destinazione è qualcosa che scrivi tu per gli host e i range che i tuoi agent non devono mai raggiungere.

​
6. Scegliere lo stage giusto

Lo stesso obiettivo di sicurezza ha spesso uno stage migliore. Abbina l’intento alla superficie che porta effettivamente i dati che ti servono:
Se il modello non dovrebbe nemmeno vedere un tool, negalo su inbound. Il block atterra prima della chiamata al modello, quindi non costa token del modello.
Le clausole sugli argomenti hanno bisogno degli argomenti scelti dal modello, che esistono solo su response e mcp. Nega su un argomento pericoloso, o sanitize per rimuovere un segreto o un valore PII che l’agent ha messo in un argomento.
Le chiamate instradate attraverso il gateway MCP vengono valutate su mcp prima del dispatch — il punto di strozzatura per i tool di ogni server registrato.
Le regole basate sulla destinazione — blocca l’IP cloud-metadata, nega un CIDR, metti in allowlist i tuoi host approvati — hanno senso solo su egress.
Una regola senza stage gira su tutte e quattro. Usala per una regola in stile default_verdict su tutto, o per un tool che neghi ovunque compaia.

​
7. Stage e shadow mode

Il flag shadow_mode di una policy è indipendente dallo stage. Attivalo e ogni verdetto applicativo — su qualsiasi stage — viene declassato a audit e la motivazione è prefissata [shadow] would …, così puoi confermare che una regola scatti sulla superficie giusta prima che modifichi il traffico live. Vedi Shadow mode e Modalità di applicazione.

​
8. Dove gli stage si inseriscono nel quadro più ampio

I quattro stage sono il dove dell’applicazione; il resto del modello è il cosa e il chi.

Verdetti

Cosa può fare ogni stage una volta che corrisponde — allow, audit, deny, sanitize, mettere in attesa di approvazione, limitare il costo.

Allow-listing dei tool

Usa inbound per vincolare l’insieme di tool che un agent pubblicizza.

Valida gli argomenti

Scrivi clausole sugli argomenti response / mcp che governano un tool in base a come viene chiamato.

Controllo dell'egress

Blocca le destinazioni in uscita sulla superficie egress — il confine di esfiltrazione.
Per come queste superfici si collocano sul percorso di ispezione, vedi Come OrcaRouter ispeziona e le note sulla latenza del percorso di applicazione. Per le minacce affrontate da ciascuno stage, vedi Chiamate a tool pericolose, Esfiltrazione di dati e MCP tool poisoning.