Vai al contenuto principale
La risposta breve: i Guardrails governano il testo; il Firewall governa le azioni. Sono complementari — una singola richiesta scorre attraverso entrambi — e il modo più rapido per configurarli insieme è un livello di autonomia. Il resto di questa pagina è per i casi in cui hai bisogno di sapere quale layer possiede una minaccia specifica.
Ruolo richiesto. Qualsiasi membro del workspace può leggere policy e il feed Matches del guardrail; il feed Events del firewall richiede il ruolo Developer. Creare o modificare guardrail o policy del firewall richiede anche Developer o superiore.

​
1. La distinzione in una riga

LayerGovernaVede
GuardrailsTesto — cosa il modello legge e scriveContenuto del prompt, contenuto della risposta
Agent FirewallAzioni — cosa fa l’agentChiamate a tool, dispatch MCP, destinazioni di rete in uscita
I Guardrails scattano prima della chiamata upstream (sul prompt) e dopo di essa (sulla risposta). Il Firewall scatta su ogni chiamata a tool che il modello emette o che l’agent emette — indipendentemente dal modello o provider che ha servito il turno.

​
2. Confronto affiancato

DimensioneGuardrailsAgent Firewall
GovernaTesto del prompt e testo della risposta del modelloChiamate a tool, dispatch MCP, destinazioni egress, costo dell’agent
VedeIl messaggio utente, il system prompt e la risposta del modelloNome del tool, argomenti della chiamata, i tool call che il modello emette, host/IP in uscita
Si collega tramiteguardrail_id sulla chiave APIfirewall_policy_id sulla chiave API
Tipi di regolakeyword, regex, pii, max_chars, external, llm_judge, groundingGlob del nome del tool + clausole sugli argomenti + scope di egress + ownership della skill
Minacce di esempioPII nei prompt, segreti API nelle risposte, jailbreak, output fuori tema, contesto sovradimensionatoChiamata a tool pericolosa, SSRF, esfiltrazione di dati, loop di costo incontrollato dell’agent, MCP server non approvato
Verdetti / azioniblock (HTTP 400 guardrail_blocked), mask, flagallow, audit, deny (HTTP 400 firewall_blocked), sanitize, pending_approval, cap_cost
Quando scattaStage input: prima della chiamata al modello; stage output: dopo che il modello rispondeSu ogni chiamata a tool che il modello emette o che l’agent emette
Shadow / observe modeNo — i guardrail scattano oppure noSì — la shadow mode declassa i verdetti applicativi a audit per un rollout sicuro

​
3. Minaccia → quale layer

Usa questa tabella per instradare un nuovo requisito di sicurezza al controllo corretto:
MinacciaVai verso
PII in un messaggio utenteGuardrails — regola pii in input (mask / block)
Segreto nella risposta del modelloGuardrails — regola dei segreti in output
Chiamata a tool pericolosa (shell.exec rm -rf /)Firewall — deny su glob del tool + clausola sugli argomenti
SSRF / esfiltrazione di dati tramite URL in uscitaFirewall — allowlist/denylist egress
Prompt injection da contenuto non attendibileEntrambi — guardrail in input + allowlist del firewall
Segreto in un argomento del toolFirewall sanitize + regola dei segreti dei Guardrails
Jailbreak / bypass della policyGuardrails — llm_judge / keyword / regex
Prompt sovradimensionato o costo di tokenGuardrails — regola max_chars
Spesa incontrollata dell’agent (loop di costo)Firewall — verdetto cap_cost
MCP server non approvatoFirewall — deny superficie MCP / pending_approval
Dati sensibili dal risultato di un toolGuardrails — regola in output sulla risposta
Il “perché” approfondito per ogni abbinamento vive sulle pagine di approfondimento delle Minacce.

​
4. Usa entrambi — i livelli di autonomia li impostano insieme

I Guardrails e il Firewall sono progettati per comporsi, non competere. Una singola richiesta passa attraverso entrambi i piani:
  1. Il guardrail in input gira — il testo del prompt viene filtrato e opzionalmente mascherato.
  2. Chiamata al modello — il prompt (possibilmente sanitizzato) raggiunge il modello upstream.
  3. Firewall — ogni chiamata a tool che il modello emette viene valutata.
  4. Il guardrail in output gira — il testo della risposta del modello viene filtrato.
Il modo più rapido per configurare entrambi in una volta è un livello di autonomia — una singola impostazione che scrive atomicamente una policy del Firewall e una policy dei Guardrails per l’intero workspace, con undo a un clic:
Livello di autonomiaPostura del FirewallPostura dei Guardrails
tightDefault-deny; blocca shell distruttiva + egress SSRFPII Shield + Secrets Blocker attivi
balancedAudit di default; nega shell distruttivaPII Shield solo-audit (segnala PII)
permissiveNessuna regola applicativa; observe mode attivoNessuna applicazione
Applica un livello di autonomia dalla console del Firewall (POST /api/workspace/firewall/autonomy, Developer+), poi ottimizza ciascun piano indipendentemente da lì. I Guardrails possiedono il testo; il Firewall possiede le azioni — eseguili entrambi, lascia che il livello di autonomia li colleghi insieme, e irrigidisci ciascun piano indipendentemente una volta che puoi vedere il traffico reale dei tuoi agent.

Guardrails

Tipi di regola, rilevamento PII, LLM judge, harness di eval e riferimento API.

Agent Firewall

Verdetti, superfici, livelli di autonomia, approvazione HITL e riferimento API.