Passer au contenu principal
Lorsque vous lisez un événement firewall ou une correspondance de guardrail, la ligne vous dit ce que la passerelle a décidé — deny, sanitize, [EMAIL]. Cette page est la table de consultation de ces mots : ce que chacun signifie, ce qu’il fait à l’appel, et où aller pour les mécanismes complets. Gardez-la ouverte pendant que vous rédigez des règles ou triez le flux d’événements. Deux plans de contrôle produisent deux vocabulaires. Le Firewall gouverne les actions d’outils et émet un verdict. Les Guardrails filtrent le texte des prompts et réponses et émettent une action plus, sur un mask, un tag de masquage typé. Ils ne partagent jamais un mot — un guardrail ne dit jamais deny, un firewall ne dit jamais mask.
C’est un index de référence, pas un guide pratique. Pour le cas d’usage derrière chaque contrôle, voir Guardrails vs Firewall ; pour les corps HTTP, voir Codes d’erreur de sécurité.

​
1. Le glossaire des verdicts firewall

Une règle firewall (ou le default_verdict de la politique) résout chaque appel d’outil en exactement un de ces six verdicts. Le moteur parcourt les règles dans l’ordre de priorité, la première correspondance gagne, et retombe sur le défaut si rien ne correspond.
L’appel procède jusqu’à l’outil. Toujours journalisé comme un événement firewall, donc il apparaît dans Runs et le flux d’événements. C’est ce que vous voulez pour les outils qu’un agent est explicitement de confiance pour utiliser.
Trafic identique à allow, mais marqué comme quelque chose que vous vouliez surveiller. C’est le default_verdict recommandé : tout observer, ne rien bloquer, jusqu’à ce que vos règles soient ajustées. Le niveau d’autonomie balanced livre le guardrail PII Shield en flag-only (audit), donc la PII est enregistrée sans mettre l’appel en attente.
L’appel n’atteint jamais l’outil. Sur la surface inbound, cela renvoie HTTP 400 firewall_blocked ; à travers la passerelle MCP, il revient comme une erreur d’outil (firewall deny: <reason>) afin que le modèle puisse réagir au lieu de planter. Marqué skip-retry. Ne coûte aucun token de modèle.
Remplace les sous-chaînes correspondantes (secrets, PII) dans les arguments de l’appel d’outil par un token [redacted:<preset>], puis transmet l’appel avec les arguments nettoyés. Il redacte uniquement les arguments — jamais le contenu qu’un outil renvoie. Sur la surface inbound, où il n’y a pas encore d’arguments au moment de l’appel, sanitize escalade en un deny.
L’appel est mis en file pour revue et l’agent reçoit une réponse held portant un id d’approbation (HTTP 400 firewall_approval_pending). Un relecteur le résout dans la console ou via un callback webhook HMAC ; l’agent interroge l’id et re-soumet une fois avec un en-tête d’approbation à usage unique. Voir Approbation humaine.
Rédigé comme une règle avec un plafond en centimes par règle. Il se résout en allow tant que l’exécution de l’agent est sous le budget et en deny dès que la dépense accumulée franchit le plafond — donc un événement affiche allow ou deny, pas le mot littéral cap_cost. Un disjoncteur pour les boucles emballées.
En mode shadow, deny / sanitize / pending_approval sont tous rétrogradés en audit et la raison est préfixée [shadow] would …. L’événement enregistre le verdict qui se serait déclenché, mais le trafic est inchangé — c’est tout l’intérêt d’un déploiement sûr.

​
Verdict par défaut

default_verdict n’accepte que les trois verdicts non-interactifs :
ValeurSignification quand aucune règle ne correspond
allowPermettre silencieusement les appels d’outils non couverts.
auditPermettre mais enregistrer — le défaut.
denyBloquer tout ce qu’aucune règle n’autorise explicitement (posture default-deny).
Le niveau d’autonomie tight définit default_verdict: deny ; balanced et le défaut livré utilisent audit.

​
2. Actions de guardrail

Une règle de guardrail déclenche l’une de cinq actions. Ce sont l’équivalent côté texte des verdicts — et une règle de guardrail ne produit jamais un verdict firewall.
ActionCe qu’elle faitQuota
blockRejeter toute la requête avec HTTP 400 guardrail_blocked.Aucun — les blocks d’entrée se déclenchent avant le décompte ; les blocks de sortie remboursent.
maskRedacter chaque correspondance en un tag typé (voir §3) et transmettre le texte nettoyé.Normal — l’appel procède.
flagJournaliser seulement. Enregistre une correspondance ; ne change rien au trafic.Normal.
annotateNon-bloquant. Attache une note lisible par un humain à la requête (injectée en amont comme une notice de sécurité) sans masquer ni bloquer le texte.Normal.
spotlightNon-bloquant. Encadre le texte (non fiable) correspondant dans des délimiteurs et dit au modèle de traiter la région délimitée comme des données, jamais des instructions — la défense « spotlighting » contre l’injection de prompt.Normal.
Une requête de guardrail bloquée est marquée skip-retry — ré-exécuter le même prompt contre un autre canal ne ferait que bloquer à nouveau.
Utilisez flag pour mesurer une nouvelle règle contre le trafic réel avant de la basculer en block ou mask. Le flux de correspondances montre ce qui aurait été attrapé avec zéro impact sur le trafic — le pendant guardrail du mode shadow du firewall.
Une seule règle pii peut appliquer différentes actions à différentes entités avec entity_actions — masquer les e-mails et les téléphones, mais bloquer sur credit_card et ssn, depuis une seule règle. Les clés doivent être une entité activée sur la règle ; les valeurs doivent être block / mask / flag / annotate.

​
3. Le glossaire des tags de masquage

Sur une action mask, chaque entité correspondante est remplacée en ligne par un tag typé — [<NOM_ENTITÉ_EN_MAJUSCULES>] — afin que le modèle (étape d’entrée) ou l’appelant (étape de sortie) voie la forme de la donnée sans la valeur. Le masquage s’exécute sur les deux étapes, y compris les réponses streamées : un scanner de flux token-aware masque les correspondances qui chevauchent les limites de chunk avant qu’elles n’atteignent le client.
EntitéTag
email[EMAIL]
phone[PHONE]
credit_card[CREDIT_CARD]
ssn[SSN]
ip[IP]
iban[IBAN]
mac_address[MAC_ADDRESS]
jwt[JWT]
aws_access_key[AWS_ACCESS_KEY]
api_key_openai[API_KEY_OPENAI]
bitcoin_address[BITCOIN_ADDRESS]
Trois identifiants régionaux s’ajoutent au-dessus de l’ensemble de base :
EntitéTagRégion
jp_mynumber[JP_MYNUMBER]Japon
kr_rrn[KR_RRN]Corée du Sud
cn_resident_id[CN_RESIDENT_ID]Chine
Les entités personnalisées suivent la même convention. Une entité personnalisée nommée employee_id masque en [EMPLOYEE_ID] sauf si vous définissez un remplacement mask_with explicite. Jusqu’à 25 entités personnalisées par règle, chacune un regex RE2 avec une somme de contrôle luhn optionnelle. Voir Détection PII.

​
4. Un exemple travaillé

Un seul appel d’outil db.query, lu de haut en bas, touche les deux vocabulaires : 
firewall verdict : sanitize        # secret stripped from the SQL argument
guardrail action : mask            # an email in the prompt redacted
masking tag      : [EMAIL]         # what the model actually receives
Le sanitize du firewall a nettoyé les arguments de l’outil ; le mask du guardrail a nettoyé le texte du prompt ; le tag [EMAIL] est ce que le modèle voit à la place de l’adresse. Même requête, trois couches différentes, trois mots de ce glossaire.

​
5. Mots de posture que vous verrez aux côtés des verdicts

Ce ne sont pas des verdicts ni des actions, mais ils décident si un verdict est appliqué du tout — donc ils apparaissent dans les mêmes vues d’événements et de réglages.
MotPlanSignification
Mode shadowFirewallFlag par politique. Rétrograde chaque verdict appliquant en audit, préfixe la raison [shadow] would ….
Mode observeFirewallRéglage d’espace de travail. Quand aucune politique ne se résout, autorise l’appel mais le journalise comme une lacune de couverture (Discovered tools).
EnforceFirewallShadow désactivé + une politique attachée : les verdicts prennent effet.
Fail-openGuardrailsDéfaut pour les règles avancées (llm_judge, grounding, external) — un timeout est observé, la requête continue. Basculez en fail-closed par règle.
Log raw contentGuardrailsDésactivé par défaut. Quand désactivé, une correspondance enregistre qu’une règle s’est déclenchée mais pas la sous-chaîne correspondante.
Pour la distinction deny-vs-audit-vs-shadow en profondeur, voir Modes d’application.

​
6. Où chaque mot est défini

SurfaceVocabulairePage de référence
Politique firewallallow audit deny sanitize pending_approval cap_costFirewall
Correspondance de règle firewalltool_name_glob, args_match, egress, sequenceRègles du Firewall
Règle de guardrailblock mask flag annotate spotlightGuardrails
PII de guardrailnoms d’entités + tags de masquageGuardrails
MCP & skillsbandes de risque de skill, modes quarantine / blockFirewall MCP, Firewall skills
Corps d’erreur HTTPguardrail_blocked, firewall_blocked, firewall_approval_pendingCodes d’erreur
Chaque terme ici apparaît aussi dans le Glossaire des concepts plus large, qui ajoute les termes d’identité, de portée et de menace. Cette page est la tranche étroite, centrée sur la décision — verdicts, actions, et tags de masquage uniquement.

​
7. Lectures associées

Pourquoi a-ce été bloqué ?

Tracez un seul appel refusé jusqu’à la règle et au verdict exacts qui l’ont arrêté.

Modes d'application

Comment audit, shadow, observe et enforce se relient — et comment déployer en toute sécurité.

Guardrails vs Firewall

Quel plan possède quelle décision, et pourquoi une requête peut traverser les deux.

Appels d'outils dangereux

La menace que les verdicts deny et sanitize existent pour arrêter.