Passer au contenu principal
Quand un agent appelle un outil, les arguments qu’il passe sont aussi risqués que le prompt qui les a produits — une clé sk-… déposée dans un champ command, un numéro de sécurité sociale client collé dans un body, un token interne dans un en-tête de requête. Le verdict sanitize du firewall attrape ce matériel dans les arguments de l’appel d’outil, le remplace par un token de redaction typé, et transmet l’appel nettoyé — de sorte que l’action s’exécute quand même, mais le secret ne quitte jamais la passerelle.
« Assainir la sortie d’outil » signifie les arguments de l’appel, pas le résultat de l’outil. Les gens cherchent assainir la sortie d’outil en s’attendant à ce que le firewall nettoie ce qu’un outil renvoie. Le verdict sanitize ne touche pas aux résultats d’outils — il redacte les arguments que votre agent envoie dans un appel d’outil. Si vous devez filtrer le texte qu’un outil ou un modèle renvoie, c’est un travail de stage de sortie des Guardrails, pas une règle sanitize du firewall.
C’est un verdict dans le langage de correspondance du firewall. Pour l’ensemble complet voir Verdicts et la référence des règles ; cette page est le guide ciblé sur la rédaction et le raisonnement autour de sanitize.

​
1. Ce que fait sanitize — et ce qu’il ne touche jamais

Une règle avec verdict: sanitize exécute un moteur de redaction sur les arguments de l’appel d’outil avant que l’appel ne soit dispatché. Chaque correspondance est remplacée par un token canonique et l’appel se poursuit avec les arguments nettoyés — l’outil s’exécute quand même, juste sans le secret brut dedans.

Redacte

Les arguments JSON d’un tool_call émis par le modèle ou d’un tools/call MCP — command, body, headers, tout champ de chaîne où un secret ou de la PII a atterri.

Ne redacte jamais

Le contenu qu’un outil renvoie, le prompt, le texte de réponse du modèle. Sanitize est un redacteur d’arguments uniquement. Le filtrage de texte est une affaire de Guardrail.
Le redacteur remplace chaque correspondance par un token typé : une correspondance de preset devient [redacted:<preset>] (par ex. [redacted:openai_key]), et une correspondance de motif custom devient [redacted:custom]. La forme de l’argument est préservée — seule la sous-chaîne sensible change — de sorte qu’un outil qui attend du JSON valide reçoit quand même du JSON valide.

​
2. Les presets de détecteurs intégrés

Une règle sanitize nomme un ou plusieurs presets (formes de secret/PII bien connues) et/ou des motifs custom de regex. Les presets intégrés :
PresetAttrape
aws_access_keyId de clé d’accès AWS (AKIA… / ASIA… + 16 caractères)
aws_secret_keyUn secret AWS de 40 caractères (sensible aux limites)
openai_keysk- + ≥32 caractères
anthropic_keysk-ant- + ≥40 caractères
bearer_tokenBearer + un token de ≥16 caractères (mot-clé conservé)
emailUne adresse e-mail
ssn_usUn SSN américain sous la forme 3-2-4
credit_cardUne suite de 13 à 19 chiffres qui passe une vérification de Luhn
Une règle sanitize doit déclarer au moins un preset ou motif custom — un assainisseur vide est rejeté quand vous enregistrez la règle. Une correspondance credit_card est de plus vérifiée par Luhn, de sorte qu’un nombre de même longueur qui n’est pas une carte valide est laissé intact plutôt que sur-redacté.

​
3. Un exemple concret

Rédigez ceci dans l’éditeur de règles de la console. L’exemple redacte une clé OpenAI et tout e-mail des arguments de tout appel d’outil http.* que votre agent émet, puis transmet l’appel nettoyé : 
{
  "label": "strip secrets from http tool args",
  "stage": "response",
  "tool_name_glob": "http.*",
  "verdict": "sanitize",
  "sanitize_json": "{\"presets\":[\"openai_key\",\"email\"],\"custom\":[]}"
}
Si le modèle émet un appel comme : 
{ "name": "http.post", "arguments": { "url": "…", "body": "key=sk-AAAA…BBBB user=jo@acme.com" } }
la passerelle le transmet avec le body réécrit en key=[redacted:openai_key] user=[redacted:email] — la requête s’exécute quand même, le secret et l’adresse ne quittent jamais la passerelle.
Épinglez la règle au stage response (tool_calls émis par le modèle) ou laissez le stage vide pour couvrir aussi la surface mcp. Ce sont les surfaces qui portent les arguments au moment de l’appel, ce que sanitize redacte.

​
4. Sur la surface inbound, sanitize escalade en deny

La surface inbound évalue les outils qu’un agent annonce sur une requête — des définitions d’outils, qui ne portent pas encore d’arguments au moment de l’appel. Il n’y a rien à redacter là, donc un verdict sanitize sur la surface inbound escalade en un deny (fail-closed) : la requête est bloquée avec firewall_blocked plutôt que transmise non redactée.
Ne rédigez pas une règle sanitize en vous attendant à ce qu’elle nettoie une annonce d’outil inbound — elle la bloquera. Si vous voulez qu’une définition d’outil disparaisse de la requête, utilisez un deny explicite. Réservez sanitize pour les surfaces response et mcp, où de vrais arguments existent.

​
5. Sanitize vs. les autres façons de gérer un secret

Trois couches peuvent agir sur un secret qu’un agent est sur le point de fuiter — choisissez selon quoi et où :
Retire le secret des arguments d’un appel d’outil et exécute quand même l’appel. Utilisez-le quand l’action est légitime mais que l’agent a mis quelque chose de sensible dans un champ. Couche des arguments uniquement.
Arrête l’appel entièrement. Utilisez-le quand l’action elle-même est dangereuse, pas seulement un argument. C’est aussi ce que sanitize devient sur la surface inbound. Voir bloquer des outils.
Les guardrails Secrets Blocker et PII filtrent le texte d’une requête ou d’une réponse (y compris, sur le stage de sortie, le contenu généré par le modèle). C’est la couche pour « ce qu’un outil ou un modèle renvoie » — la chose que sanitize ne fait pas.
Testez avant d’appliquer. Sanitize réécrit les arguments d’un appel en live sur les surfaces response et mcp. Rédigez d’abord vos règles sanitize sous le mode shadow et surveillez le flux d’événements pour confirmer qu’elles correspondent à ce que vous attendez avant qu’aucun argument ne soit réellement réécrit.

​
6. Où sanitize apparaît dans votre trace

Comme chaque verdict, une évaluation sanitize est enregistrée comme un événement firewall — filtrable par verdict, surface, outil et exécution dans le journal d’événements et agrégé dans analytics. En mode shadow, un verdict sanitize (comme chaque verdict appliquant) est rétrogradé en audit et la raison est préfixée [shadow] would …, de sorte que vous pouvez mesurer l’impact avant qu’aucun argument ne soit réellement réécrit.

​
Où aller ensuite

Tous les verdicts

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

Valider les arguments

Faire correspondre un appel par ce qui est dans ses arguments — la grammaire des clauses JSONPath.

Bloquer des outils

Quand l’action elle-même est le problème, refusez tout l’appel.

Firewall + Guardrails

Filtrer le texte qu’un outil ou un modèle renvoie — la couche que sanitize ne couvre pas.
Pour les menaces que sanitize aide à contenir, voir exfiltration de données et appels d’outils dangereux. Pour la grammaire complète des règles derrière le verdict, voir la référence des règles du firewall.