Vai al contenuto principale
Una policy del firewall decide una cosa su ogni chiamata a tool che il tuo agent fa: un verdetto. O una regola corrisponde e produce un verdetto, oppure nessuna regola corrisponde e subentra il verdetto di default della policy. Questa pagina copre entrambi — cosa fa ogni verdetto del firewall, come si risolve cap_cost, e perché audit è il default da cui parti. Per dove i verdetti vivono nella grammatica delle regole vedi Regole del Firewall; per scegliere un verdetto di default durante la creazione di una policy vedi Crea e collega.

​
1. I sei verdetti delle regole

Una regola produce esattamente uno tra sei verdetti. Scrivili nell’editor delle regole della console; il motore percorre le regole in ordine di priorità e vince il primo match.
La chiamata prosegue intatta. Atterra comunque nel feed degli eventi come un allow, così mantieni una traccia di audit senza bloccare nulla. Usalo come un permesso esplicito in una policy default-deny.
Esito di traffico identico a allow, ma la chiamata è segnalata come qualcosa che volevi osservare. È anche il valore su cui atterra il verdetto di default di base — osserva tutto, blocca nulla, finché non sei pronto ad applicare.
La chiamata non raggiunge mai il tool. Sulla superficie inbound il relay restituisce HTTP 400 con codice di errore firewall_blocked, nominando il tool e la motivazione; sulla superficie mcp torna come un errore di tool così il modello può reagire. Vedi com’è fatto un block.
Redige le sottostringhe corrispondenti dagli argomenti della chiamata a tool (un segreto o una PII che l’agent ha messo in un campo command o body) e inoltra la chiamata ripulita. Redige solo gli argomenti — mai il contenuto che un tool restituisce. Sulla superficie inbound non ci sono ancora argomenti al momento della chiamata, quindi sanitize escala a un deny. Vedi sanitizza le risposte.
Trasforma la chiamata in una revisione fuori banda. Il relay restituisce HTTP 400 con codice firewall_approval_pending e un id di approvazione; la chiamata non raggiunge il tool. Un revisore la risolve nella console o tramite webhook callback, e l’agent ri-invia con un header di approvazione monouso. Vedi approvazioni.
Un interruttore di sicurezza per il costo — scritto come una regola ma risolto in allow o deny al momento della valutazione. Vedi §3 e tetto di costo.
La shadow mode appiattisce l’applicazione. In shadow mode, ogni verdetto applicativo (deny, sanitize, pending_approval, e un cap_cost che si è risolto in deny) viene declassato a audit e la motivazione è prefissata [shadow] would …. Fai il rollout di una policy applicativa in questo modo e osserva il feed degli eventi prima di renderla live.

​
2. Il verdetto di default

Il verdetto di default (default_verdict sulla policy) è ciò che la policy fa quando nessuna regola corrisponde a una chiamata a tool. È il pavimento della tua postura, e a differenza di un verdetto di regola accetta solo tre valori:
default_verdictQuando nessuna regola corrisponde…
audit (default)Consenti la chiamata, ma registrala. Il punto di partenza sicuro.
allowConsenti e logga, nessun record di revisione.
denyBlocca tutto ciò che una regola non permette esplicitamente — una postura default-deny.
Una nuova policy ha come default audit: osserva ogni chiamata a tool e blocca nulla finché non aggiungi regole applicative. I tre verdetti solo-regola — sanitize, pending_approval e cap_cost — non possono essere un default; un verdetto di default è un fallback su tutto, e quei verdetti hanno senso solo se hanno scope su un match specifico.
deny come verdetto di default è default-deny: ogni chiamata a tool che le tue regole non allow-ano esplicitamente viene bloccata. Potente per un agent blindato, ma fermerà chiamate che hai dimenticato di mettere in allowlist. Abbinalo a regole di allow esplicite (allow-listing dei tool) e fai il rollout sotto shadow mode prima.

​
3. cap_cost si risolve in allow o deny

cap_cost è l’unico verdetto che non è ciò che compare nei tuoi eventi. Scrivi una regola con un tetto cap_cost_cents, ma al momento della valutazione il motore lo risolve in un concreto allow o deny prima che l’evento sia registrato — quindi il feed degli eventi non porta mai un verdetto cap_cost letterale, solo l’allow/deny che l’agent ha effettivamente visto. Il tetto è per esecuzione dell’agent: il motore confronta la spesa accumulata dell’esecuzione con il tuo tetto.
  • Sotto il tetto → si risolve in allow. (Internamente questo è trattato come non corrispondente, quindi la valutazione continua alla regola successiva anziché far vincere cap_cost come primo-match concedendo un grant.)
  • Sopra il tetto → si risolve in deny, con una motivazione che nomina il totale dell’esecuzione rispetto al tetto. Questo è l’esito terminale, da interruttore di sicurezza.
// A rule that caps a run at $5.00 of accumulated spend.
{
  "label": "run cost ceiling",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
cap_cost scatta solo sulle superfici pre-dispatch (inbound, mcp) — i punti dove bloccare una chiamata previene ancora la spesa. Sulle superfici post-dispatch response ed egress è inerte (non c’è più nulla da fermare), quindi il motore lo salta lì.

​
4. Come viene scelto un verdetto

Per ogni chiamata a tool, la risoluzione è la stessa indipendentemente da quale verdetto vince:
Il gateway sceglie la policy collegata alla chiave chiamante (firewall_policy_id), o il default del workspace — vedi risoluzione.
Le regole girano in ordine priority ASC. La prima regola la cui superficie, glob sul tool, clausole opzionali sugli argomenti e scope opzionale di egress tutti corrispondono produce il verdetto.
Se nessuna regola corrisponde, si applica il default_verdict della policy — audit a meno che tu non l’abbia cambiato.
Se la chiamata è di proprietà di una skill governata, una skill in modalità block forza un deny e una skill in modalità quarantine escala qualsiasi cosa al di sotto di deny a pending_approval.

​
5. Comportamento di costo e retry di un deny

Un verdetto del firewall sulla superficie inbound scatta prima della chiamata al modello upstream, quindi un deny lì non costa token del modello. L’errore è marcato skip-retry — rieseguire la stessa chiamata bloccata si limiterebbe a bloccarla di nuovo, quindi il gateway dice al client di non riprovarla. Questo è distinto da un block dei guardrail, che filtra il testo di prompt/risposta (PII, segreti) anziché le azioni dei tool, e restituisce il proprio errore guardrail_blocked. Una richiesta può attraversare entrambi i piani.
Ogni verdetto lascia una traccia. Ogni valutazione — allow, audit, deny, il cap_cost risolto, l’approvazione messa in attesa — è registrata come un evento del firewall, filtrabile per verdetto, superficie, tool ed esecuzione. Il feed degli eventi è come confermi che una policy stia producendo i verdetti che ti aspetti. Vedi log degli eventi e analytics.

​
Dove andare dopo

Crea e collega una policy

Scegli un verdetto di default e lega una policy a una chiave.

Tetto di costo

Scrivi un tetto di spesa e come si risolve per esecuzione.

Shadow mode

Declassa ogni verdetto applicativo ad audit mentre misuri l’impatto.

Riferimento delle regole

Il linguaggio di matching completo dietro un verdetto.
Per le minacce che questi verdetti sono pensati per fermare, vedi chiamate a tool pericolose e agenzia eccessiva.