Vai al contenuto principale
Quando un modello risponde, non restituisce solo testo — emette tool_calls: invocazioni concrete con argomenti reali, scelti dal modello. La superficie response dell’agent firewall ispeziona esattamente quelli, nel momento in cui lasciano il modello e prima che raggiungano il tuo loop di agent. È la superficie dove filtri ciò che il modello ha effettivamente deciso di fare, con gli argomenti che ha effettivamente scelto. Questa pagina copre il caso d’uso del filtraggio sulla superficie response — quando ricorrervi al posto di inbound, l’unica sfumatura di verdetto che aggiunge, e come si comporta su uno stream. Per il vocabolario completo delle regole e la semantica dei verdetti, vedi Schema delle regole e Verdetti.

​
1. Filtra le chiamate a tool nelle risposte LLM, con gli argomenti nello scope

Lo stage inbound vede i tool che pubblicizzi — solo nomi, ancora nessun argomento al momento della chiamata. Lo stage response vede i tool_calls che il modello emette, che portano gli argomenti che il modello ha scelto. È l’intero motivo per filtrare qui: è l’unica superficie che vede la chiamata effettiva + gli argomenti per un tool eseguito dal client (non-MCP), quindi le clausole sugli argomenti, le sequenze e le regole sullo stato dell’esecuzione atterrano tutte su response. La distinzione in una riga:
StageVedeUsalo per
inboundLe definizioni di tool pubblicizzateRendere un tool invisibile al modello
responseI tool_calls emessi + gli argomentiFiltrare la chiamata che il modello ha effettivamente fatto
Quindi inbound risponde a quali tool esistono; response risponde a cosa il modello ne ha fatto. Ricorri a response (o lascia stage vuoto per coprire entrambi) quando un tool compare legittimamente in alcune richieste ma una particolare chiamata di esso è pericolosa — o quando controlli solo il loop dell’agent, non l’insieme di tool pubblicizzato.
Una regola senza stage gira su ogni superficie, inclusa response. Fissa a response solo quando una regola dovrebbe ispezionare solo le chiamate emesse — per esempio una clausola sugli argomenti che comunque non ha nulla su cui fare match sulla superficie inbound. Vedi Stage.

​
2. Un esempio concreto

Consenti shell.exec in generale, ma rimuovilo dalla risposta del modello nel momento in cui il suo argomento command appare distruttivo. Nella console del tuo workspace, apri una policy (o creane una) e aggiungi una regola fissata alla superficie response: 
{
  "label": "block destructive shell calls",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
Il matcher degli argomenti vive in args_match_json — una stringa JSON che contiene {"clauses":[…]}, ogni clausola una tripla path / op / value (op è uno tra eq, contains, regex, gt, lt). Il form della console lo costruisce per te; la forma grezza è mostrata qui così il nome del campo è inequivocabile. Il tool rimane pubblicizzato — il modello può comunque proporre shell.exec — ma quando la chiamata emessa porta un command distruttivo, il firewall rimuove quel tool_call dalla risposta prima che il tuo agent lo veda. Un shell.exec benigno (diciamo, ls -la) scorre intatto. Questo è il pattern “consenti il tool, governa la chiamata” per cui la superficie response esiste; la clausola sugli argomenti è ciò che lo rende possibile.
Le regole valutano in ordine di priorità, vince il primo match. Metti un’eccezione di allow stretta a un numero di priority più basso di un deny ampio così l’eccezione gira per prima. Vedi Priorità delle regole.

​
3. Cosa fa un verdetto sulla superficie response

La superficie response ispeziona ogni tool_call emesso e riscrive la risposta sul posto. Le chiamate mantenute vengono inoltrate byte per byte; cambia solo una chiamata corrisposta:
Il tool_call corrisposto viene rimosso dalla risposta del modello prima che raggiunga il tuo agent. A differenza di un deny inbound — che restituisce HTTP 400 con codice firewall_blocked — un deny sulla superficie response non fa fallire la richiesta; il resto della risposta (altre chiamate a tool, eventuale testo) scorre con la chiamata incriminata semplicemente assente.
Le sottostringhe corrispondenti negli argomenti della chiamata vengono sostituite con gli argomenti redatti dal motore e la chiamata ripulita viene inoltrata — utile quando il tool va bene ma il modello ha messo un segreto o un valore PII in un argomento. Sanitize redige solo gli argomenti della chiamata a tool; non tocca mai il contenuto che un tool restituisce. Se il motore non ha nulla da sostituire, la chiamata viene rimossa (fail-closed). Vedi Sanitizza le risposte.
L’hold human-in-the-loop si apre sulla superficie inbound, non response. Una regola pending_approval che corrisponde per prima su una chiamata emessa viene quindi rimossa (fail-closed) — mantenerla inoltrerebbe una chiamata non revisionata senza alcuna decisione umana. Scrivi gli hold HITL perché scattino inbound; vedi Approvazioni.
allow e audit inoltrano entrambi la chiamata; audit è il default_verdict abituale — registra tutto, blocca nulla, finché non sei pronto ad applicare.
cap_cost e pending_approval sono concetti inbound su questa superficie. cap_cost è inerte su response (il modello ha già girato), e pending_approval si risolve in una rimozione anziché in un hold. Metti i tetti di costo e gli hold HITL sulla superficie inbound — vedi Tetto di costo e Approvazioni.

​
4. Streaming: mantenuto, poi filtrato

Su una risposta non in stream l’intera risposta viene parsata e filtrata in una volta. Su uno stream, i tool_calls di un modello arrivano come delta per indice attraverso molti frame SSE — e una volta che un delta è inoltrato, il tuo agent ce l’ha già e non può essere ritrattato. Quindi il gateway trattiene i frame delle chiamate a tool: non vengono mai inoltrati a metà stream. Alla fine dello stream il firewall assembla ogni chiamata (nome + argomenti completi), la valuta ed emette solo le chiamate sopravvissute.
I frame di contenuto continuano a fare stream normalmente — i token di testo raggiungono il tuo client man mano che arrivano. Solo i frame tool_call vengono trattenuti per la valutazione, così una chiamata negata o sanitizzata viene filtrata prima che la chiamata a tool assemblata venga consegnata. La semantica del verdetto e delle regole è identica alla superficie non in stream. Per i dettagli a livello di frame, vedi Internals dello streaming e Streaming dei provider.

​
5. Fai il rollout in sicurezza

La scheda Test della console fa girare una policy contro una chiamata a tool di esempio e restituisce il verdetto, la regola corrispondente e la motivazione — nulla viene dispatchato, nulla viene persistito. Conferma che il tuo glob e la clausola sugli argomenti corrispondano alla chiamata che intendevi prima di collegare una chiave. Vedi Testa le regole.
Attiva la shadow mode e ogni verdetto applicativo — incluso un deny sulla superficie response — viene declassato a audit, con la motivazione prefissata [shadow] would …. Misuri esattamente cosa la regola rimuoverebbe contro il traffico reale prima che modifichi una singola risposta.
Ogni valutazione scrive un evento del firewall con il verdetto, la superficie, il tool e la regola corrispondente. Filtra il log degli eventi per superficie response per vedere la tua regola scattare sulle chiamate emesse che ti aspettavi. Vedi Analytics.

​
6. Collega la policy e chi può configurarla

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 — e una policy collegata disabilitata ricade sul default del workspace. Vedi Gestisci le policy. Tutta la configurazione gira nella console sotto la tua sessione (/api/workspace/firewall/*):
AzioneRuolo
Leggere policy, preset, discovered tools, SimulateMember
Dry-run (Test), leggere il log degli eventi e le aggregazioni delle esecuzioniDeveloper+
Creare / modificare / eliminare regole e policyDeveloper+

​
Correlati

Valida gli argomenti

Le clausole sugli argomenti che rendono preciso il filtraggio sulla superficie response.

Sanitizza le risposte

Redige i segreti dagli argomenti di una chiamata invece di rimuoverla.

Stage del firewall

Come response si confronta con inbound, mcp ed egress.

Blocca i tool

Il corrispettivo inbound: nega un tool prima che venga offerto al modello.

Chiamate a tool pericolose

La minaccia che il filtraggio della response affronta.

Riferimento del firewall

Il riferimento completo di regole + matching.