Vai al contenuto principale
Quando un agent chiama un tool, gli argomenti che passa sono rischiosi quanto il prompt che li ha prodotti — una chiave sk-… lasciata in un campo command, un SSN di un cliente incollato in un body, un token interno in un header di richiesta. Il verdetto sanitize del firewall cattura quel materiale negli argomenti della chiamata a tool, lo sostituisce con un token di redazione tipizzato e inoltra la chiamata ripulita — così l’azione gira comunque, ma il segreto non lascia mai il gateway.
“Sanitizza l’output dei tool” significa gli argomenti della chiamata, non il risultato del tool. Le persone cercano sanitize tool output aspettandosi che il firewall ripulisca ciò che un tool restituisce. Il verdetto sanitize non tocca i risultati dei tool — redige gli argomenti che il tuo agent invia in una chiamata a tool. Se devi filtrare il testo che un tool o un modello restituisce, quello è un compito dello stage di output dei Guardrails, non una regola di sanitize del firewall.
Questo è un verdetto nel linguaggio di matching del firewall. Per l’insieme completo vedi Verdetti e il riferimento delle regole; questa pagina è la guida focalizzata alla scrittura e al ragionamento su sanitize.

​
1. Cosa fa sanitize — e cosa non tocca mai

Una regola con verdict: sanitize esegue un motore di redazione sugli argomenti della chiamata a tool prima che la chiamata venga dispatchata. Ogni match viene sostituito con un token canonico e la chiamata prosegue con gli argomenti ripuliti — il tool gira comunque, solo senza il segreto grezzo al suo interno.

Redige

Gli argomenti JSON di un tool_call emesso dal modello o di un tools/call MCP — command, body, headers, qualsiasi campo stringa dove è atterrato un segreto o una PII.

Non redige mai

Il contenuto che un tool restituisce, il prompt, il testo di risposta del modello. Sanitize è un redactor solo-argomenti. Il filtraggio del testo è una questione dei Guardrail.
Il redactor sostituisce ogni match con un token tipizzato: un match su preset diventa [redacted:<preset>] (es. [redacted:openai_key]), e un match su pattern custom diventa [redacted:custom]. La forma dell’argomento è preservata — cambia solo la sottostringa sensibile — così un tool che si aspetta JSON valido riceve comunque JSON valido.

​
2. I preset di detector integrati

Una regola sanitize nomina uno o più preset (forme note di segreto/PII) e/o pattern custom regex. I preset integrati:
PresetCattura
aws_access_keyAWS access key id (AKIA… / ASIA… + 16 caratteri)
aws_secret_keyUn secret AWS di 40 caratteri (consapevole dei confini)
openai_keysk- + ≥32 caratteri
anthropic_keysk-ant- + ≥40 caratteri
bearer_tokenBearer + un token di ≥16 caratteri (keyword mantenuta)
emailUn indirizzo email
ssn_usUn SSN US nella forma 3-2-4
credit_cardUna sequenza di 13–19 cifre che passa un controllo Luhn
Una regola sanitize deve dichiarare almeno un preset o pattern custom — un sanitizer vuoto viene rifiutato quando salvi la regola. Un match credit_card è inoltre verificato con Luhn, così un numero della stessa lunghezza che non è una carta valida viene lasciato intatto anziché redatto in eccesso.

​
3. Un esempio concreto

Scrivi questo nell’editor delle regole della console. L’esempio redige una chiave OpenAI e qualsiasi email dagli argomenti di qualsiasi chiamata a tool http.* che il tuo agent emette, poi inoltra la chiamata ripulita: 
{
  "label": "strip secrets from http tool args",
  "stage": "response",
  "tool_name_glob": "http.*",
  "verdict": "sanitize",
  "sanitize_json": "{\"presets\":[\"openai_key\",\"email\"],\"custom\":[]}"
}
Se il modello emette una chiamata come: 
{ "name": "http.post", "arguments": { "url": "…", "body": "key=sk-AAAA…BBBB user=jo@acme.com" } }
il gateway la inoltra con il body riscritto in key=[redacted:openai_key] user=[redacted:email] — la richiesta gira comunque, il segreto e l’indirizzo non lasciano mai il gateway.
Fissa la regola allo stage response (i tool_calls emessi dal modello) o lascia lo stage vuoto per coprire anche la superficie mcp. Quelle sono le superfici che portano gli argomenti al momento della chiamata, che è ciò che sanitize redige.

​
4. Sulla superficie inbound, sanitize escala a deny

La superficie inbound valuta i tool che un agent pubblicizza su una richiesta — definizioni di tool, che non portano ancora alcun argomento al momento della chiamata. Non c’è nulla da redigere lì, quindi un verdetto sanitize sulla superficie inbound escala a un deny (fail-closed): la richiesta viene bloccata con firewall_blocked anziché inoltrata non redatta.
Non scrivere una regola sanitize aspettandoti che pulisca una pubblicità di tool inbound — la bloccherà. Se vuoi che una definizione di tool sparisca dalla richiesta, usa un deny esplicito. Riserva sanitize per le superfici response e mcp, dove esistono argomenti reali.

​
5. Sanitize vs. gli altri modi per gestire un segreto

Tre layer possono agire su un segreto che un agent sta per far trapelare — scegli in base a cosa e dove:
Rimuove il segreto dagli argomenti di una chiamata a tool e fa girare comunque la chiamata. Usalo quando l’azione è legittima ma l’agent ha messo qualcosa di sensibile in un campo. Solo a livello di argomenti.
Ferma del tutto la chiamata. Usalo quando l’azione stessa è pericolosa, non solo un argomento. È anche ciò che sanitize diventa sulla superficie inbound. Vedi blocca i tool.
I guardrail Secrets Blocker e PII filtrano il testo di una richiesta o risposta (incluso, sullo stage di output, il contenuto generato dal modello). Quello è il layer per “ciò che un tool o un modello restituisce” — la cosa che sanitize non fa.
Testa prima di applicare. Sanitize riscrive gli argomenti di una chiamata live sulle superfici response e mcp. Scrivi le tue regole sanitize sotto shadow mode prima e osserva il feed degli eventi per confermare che facciano match su ciò che ti aspetti prima che un argomento venga effettivamente riscritto.

​
6. Dove sanitize compare nella tua traccia

Come ogni verdetto, una valutazione sanitize è registrata come un evento del firewall — filtrabile per verdetto, superficie, tool ed esecuzione nel log degli eventi e aggregata in analytics. In shadow mode un verdetto sanitize (come ogni verdetto applicativo) viene declassato a audit e la motivazione è prefissata [shadow] would …, così puoi misurare l’impatto prima che un argomento venga effettivamente riscritto.

​
Dove andare dopo

Tutti i verdetti

allow, audit, deny, sanitize, pending_approval, cap_cost.

Valida gli argomenti

Fai match su una chiamata in base a cosa c’è nei suoi argomenti — la grammatica delle clausole JSONPath.

Blocca i tool

Quando l’azione stessa è il problema, nega l’intera chiamata.

Firewall + Guardrails

Filtra il testo che un tool o un modello restituisce — il layer che sanitize non copre.
Per le minacce che sanitize aiuta a contenere, vedi esfiltrazione di dati e chiamate a tool pericolose. Per la grammatica completa delle regole dietro il verdetto, vedi il riferimento delle regole del firewall.