Vai al contenuto principale
I controlli di sicurezza contano solo se effettivamente girano — ma non dovresti dover scambiare throughput per sicurezza. Questa pagina risponde alla domanda che gli sviluppatori fanno più spesso: l’applicazione rallenterà il mio agent, e di quanto? La risposta breve: le regole integrate non costano nulla di misurabile. Le regole avanzate costano al massimo una singola chiamata al modello, limitata, concorrente e fail-open. Ecco perché, e come controllarla.

​
1. Due classi di controllo

Ogni regola del guardrail e ogni valutazione del firewall rientra in una di due classi.

​
Controlli integrati / deterministici

Le regole del guardrail keyword denylist (keyword), regular expression (regex), rilevamento PII (pii) e lunghezza massima (max_chars) sono pure operazioni locali su stringhe e regex — nessuna chiamata al modello, nessun hop di rete, niente che possa andare in timeout. La valutazione delle regole del firewall (glob del nome del tool, predicati sugli argomenti, scope di egress) è la stessa: deterministica e locale. A fini pratici, questi controlli aggiungono latenza trascurabile alla tua richiesta. Sono sicuri da eseguire sull’hot path e sono ciò di cui sono fatti i template integrati del guardrail.

​
Controlli avanzati / semantici

Le regole llm_judge, grounding e del vendor external delegano il controllo a un modello o un vendor. Costano un round-trip. Tre proprietà limitano quel costo:
  1. Dispatch concorrente. Se la tua policy ha più regole avanzate, vengono dispatchate in parallelo — un controllo lento non si serializza mai dietro un altro.
  2. Timeout per regola. Ogni regola avanzata ha un timeout (judge_timeout_ms / grounding_timeout_ms / timeout_ms). Il controllo di grounding ha come default ~3 000 ms; il judge usa un valore configurabile (0 → default del motore). La regola è limitata — non può rimanere appesa indefinitamente.
  3. Fail-open di default. Quando una regola va in timeout o il suo vendor restituisce un errore, l’evento viene registrato ma la richiesta continua. Imposta judge_fail_open: false (judge) o fail_open: false (external) per passare a fail-closed invece.
Quindi il caso peggiore per qualsiasi numero di regole avanzate è il singolo timeout più lungo, non la somma di tutti i timeout.

​
2. A colpo d’occhio

Tipo di controlloAggiunge latenza?Come è limitato
Denylist keywordTrascurabile — scansione locale di stringheNessuna rete; nessun timeout necessario
regexTrascurabile — match RE2 localeNessuna rete; nessun timeout necessario
Rilevamento piiTrascurabile — scansione locale regex/entitàNessuna rete; nessun timeout necessario
max_charsTrascurabile — conteggio caratteriNessuna rete; nessun timeout necessario
Valutazione regola del firewallTrascurabile — matching glob + predicatoNessuna rete; nessun timeout necessario
llm_judgeUna singola chiamata al modello limitatajudge_timeout_ms; fail-open di default
groundingUna singola chiamata al modello limitatagrounding_timeout_ms (default ~3 000 ms); fail-open di default
Vendor externalUna singola chiamata al vendor limitatatimeout_ms; fail_open di default
Più regole avanzateUn singolo round-trip limitato (dispatch concorrente)Caso peggiore = max singolo timeout, non la somma

​
3. Dove nel ciclo di vita della richiesta girano i controlli

L’applicazione non avviene tutta nello stesso punto. Il filtraggio in input e in output aggiungono tempo in posti diversi: 
Client
  │
  ▼
[Filtraggio guardrail in input]     ← aggiunge tempo QUI, prima dell'upstream
  │
  ▼
Chiamata al modello upstream
  │
  ▼
[Filtraggio guardrail in output]    ← aggiunge tempo QUI, dopo che il modello risponde
  │
  ▼
Client
I guardrails in input girano prima della chiamata al modello upstream. Una regola integrata in input aggiunge overhead trascurabile all’inizio. Una regola avanzata in input (es. un llm_judge che verifica la prompt injection) aggiunge una chiamata al modello limitata prima che la chiamata al modello principale inizi. I guardrails in output girano dopo che il modello risponde. Una regola integrata in output aggiunge overhead trascurabile alla coda. Una regola avanzata in output (es. grounding che verifica la fedeltà RAG) aggiunge una chiamata limitata dopo che hai già la risposta del modello. La valutazione delle regole del Firewall è deterministica e avviene inline sul routing delle chiamate a tool — trascurabile, come notato sopra.
Una richiesta bloccata non costa token del modello e non aggiunge latenza upstream per i block di stage input. Un block di input scatta prima della misurazione e prima della chiamata upstream, quindi non paghi né quota né tempo di round-trip upstream. Un block di stage output rimborsa la quota pre-consumata dopo che la risposta viene rifiutata.

​
4. Come timeout e fail-open limitano il caso peggiore

Le regole avanzate hanno due controlli: Timeout — il tempo massimo di parete che il controllo può impiegare. La richiesta attende al massimo questo lungo per quella regola. Il dispatch concorrente significa che questo limite si applica per regola, non per policy. Se hai tre regole llm_judge ciascuna con un timeout di 2 000 ms, tutte e tre girano contemporaneamente e l’attesa totale è ~2 000 ms, non ~6 000 ms. Fail-open vs fail-closed — cosa fare quando la regola non si completa in tempo (o il vendor restituisce un errore):
ImpostazioneComportamento su timeout / errore
fail_open: true (default)Registra l’evento; lascia continuare la richiesta come se il controllo fosse passato
fail_open: falseTratta il timeout / errore come un block; restituisce HTTP 400 guardrail_blocked
Fail-open preserva la disponibilità al costo di un controllo mancato. Fail-closed preserva la garanzia della policy al costo della disponibilità se il judge è lento o irraggiungibile. Scegli in base a cosa conta di più per il tuo caso d’uso.

​
5. Guida pratica

Mantieni le regole hot-path integrate. Se il tuo problema principale è PII, perdita di credenziali, lunghezza del prompt o keyword denylist — tutte queste sono regole integrate. Non aggiungono latenza misurabile e dovrebbero essere la tua scelta predefinita per qualsiasi controllo che il text matching può gestire. Usa llm_judge e grounding dove hai bisogno di semantica. Tossicità, molestie, rilevamento fuori tema, intento di prompt injection e fedeltà RAG sono genuinamente fuzzy — nessuna regex li cattura in modo affidabile. Questi sono i casi giusti per una regola avanzata. Accetta che ognuna aggiunge una chiamata al modello extra limitata. Ottimizza i timeout in base al tuo budget di latenza. Se il tuo target end-to-end è 1 000 ms, imposta judge_timeout_ms: 800 (o meno) così il judge non può consumare l’intero budget. Il timeout default del motore è un buon punto di partenza; abbassalo se hai requisiti stringenti. Per il grounding dell’output, la chiamata al modello è già fatta. Il controllo grounding gira dopo che il modello upstream risponde — la latenza extra è solo nella coda, non sul percorso critico per il time-to-first-token. Questo lo rende un posto a basso rischio per aggiungere applicazione semantica. Più regole avanzate? Distribuisci il lavoro. Poiché le regole avanzate girano concorrentemente, impilare tre regole llm_judge costa approssimativamente come una — il singolo timeout più lungo determina il tempo di parete, non il conteggio. Usa questo per sovrapporre controlli semantici senza costo additivo.

Modalità di applicazione

Fail-open vs fail-closed — il riferimento completo per ottimizzare il comportamento della tua policy sotto timeout e condizioni di errore.

Guardrails

Tipi di regola, campi del judge, soglie di grounding e il riferimento completo della configurazione del guardrail.
Le regole integrate sono trascurabili su ogni percorso; le regole avanzate costano una singola chiamata limitata, concorrente e fail-open — ottimizza il timeout e la modalità di fail, e l’applicazione non aggiunge latenza incontrollata ai tuoi agent.