Passer au contenu principal
Une politique firewall est une liste ordonnée de règles, et une règle n’est qu’un petit sac de champs : quels appels d’outils elle correspond, sur quelle surface, et quoi en faire. Quand vous avez besoin de lire une règle écrite par quelqu’un d’autre — ou de raisonner précisément sur une que vous construisez — vous voulez la liste des champs en un seul endroit. C’est cette page. Vous rédigez les règles dans l’éditeur de règles de la console (les écritures requièrent Developer+) ; l’éditeur écrit les champs structurés ci-dessous. Cette page est la carte au niveau des champs ; le moteur de correspondance en profondeur vit dans Règles Firewall.

​
1. Le schéma de règle firewall en un coup d’œil

Chaque règle porte les mêmes champs. Seul verdict est toujours requis — tout le reste restreint ce que la règle correspond ou configure le verdict choisi, et un matcher absent est vacuement vrai.
ChampObjectif
priorityOrdre d’évaluation — la plus basse s’exécute d’abord.
verdictL’action lorsque la règle correspond (requis).
stageLa surface à laquelle se scoper ; vide = toutes.
tool_name_globGlob sur le nom de l’outil.
args_match_jsonPrédicat d’argument JSONPath, sous forme de chaîne encodée en JSON.
egress_jsonListe host / CIDR d’autorisation-refus (règles d’egress), sous forme de chaîne encodée en JSON.
sanitize_jsonConfiguration de rédaction (quand verdict = sanitize), sous forme de chaîne encodée en JSON.
cap_cost_centsPlafond de coût d’exécution en centimes USD (quand verdict = cap_cost).
sequence_jsonPrédicat de chaîne multi-étapes ordonnée (règles de séquence), sous forme de chaîne encodée en JSON.
label / notesNom humain et justification — affichés dans les événements, ignorés par le moteur.
Une règle se déclenche lorsque tous ses matchers déclarés tiennent à la fois — la surface correspond (ou est vide), le glob d’outil correspond, les clauses d’arguments correspondent (ou sont absentes), et la portée d’egress correspond (règles d’egress seulement). Le moteur parcourt les règles dans l’ordre de priorité et la première correspondance gagne ; si rien ne correspond, le default_verdict de la politique s’applique.

​
2. priority — l’ordre d’évaluation

Un ordinal entier. La plus basse s’exécute d’abord ; deux règles de même priorité sont départagées par l’id de règle (ordre d’insertion). Placez vos exceptions spécifiques au-dessus de vos attrape-tout larges — un allow pour un outil de confiance à la priorité 10 bat un deny * à la priorité 100.
Laissez des espaces (10, 20, 30) pour pouvoir insérer une nouvelle règle entre deux existantes plus tard sans renuméroter toute la politique. Voir Priorité des règles pour la stratégie d’ordonnancement.

​
3. verdict — l’action

Le seul champ requis. Quand une règle correspond, son verdict décide ce qui arrive à l’appel :
VerdictEffet
allowLaisse passer l’appel, journalisé.
auditAutorise et enregistre pour revue — le default_verdict habituel.
denyBloque l’appel.
sanitizeRedacte les sous-chaînes correspondantes des arguments de l’outil, puis transmet.
pending_approvalMet l’appel en attente d’un relecteur humain.
cap_costRefuse dès que la dépense accumulée d’une exécution d’agent dépasse un plafond.
Un deny renvoie une HTTP 400 firewall_blocked sur la surface inbound, ou une erreur d’outil sur la surface mcp. Un appel mis en attente renvoie une HTTP 400 firewall_approval_pending avec un id sur lequel l’agent interroge. En mode shadow, chaque verdict appliquant est rétrogradé en audit et la raison est préfixée [shadow] would …. Voir Verdicts pour la table complète et les formes de block.

​
4. stage — la surface d’application

Épingle la règle à l’une des surfaces du firewall. Laissez-le vide et la règle s’applique à toutes les surfaces :
Les outils qu’un agent annonce au modèle sur la requête. Bloquez un outil dangereux avant même que le modèle puisse le choisir.
Les tool_calls que le modèle émet dans sa réponse.
Un tools/call routé à travers la passerelle MCP du Firewall.
Un host / IP / CIDR sortant qu’un outil atteint — la surface de SSRF et d’exfiltration de données.
Certaines combinaisons verdict + stage sont rejetées à l’enregistrement parce que le verdict ne peut s’y déclencher : cap_cost est un plafond de coût d’exécution pré-dispatch, inerte sur response et egress ; pending_approval ne met jamais en attente qu’à inbound, donc un épinglage explicite response/egress est refusé. L’éditeur masque ces combinaisons ; l’API les rejette. Voir Surfaces.

​
5. tool_name_glob — quel outil

Un petit glob sensible à la casse sur le nom de l’outil — shell.* pour toute une famille, *.delete pour un verbe à travers les serveurs, http_fetch pour un outil exact. Vide ou * correspond à chaque outil. Un glob de nom de skill optionnel (même grammaire) ajoute en AND une seconde condition sur le skill propriétaire, de sorte que vous pouvez faire confiance à un outil d’un skill intégré et le restreindre depuis un skill communautaire. La grammaire complète — préfixe, suffixe, infixe, exact, et les cas limites qui piègent — a sa propre référence : Syntaxe des motifs glob.

​
6. args_match_json — avec quels arguments

Le glob répond quel outil ; args_match_json répond avec quels arguments — la différence entre « bloquer shell.exec » et « bloquer shell.exec seulement quand la commande est rm -rf ». Sa valeur est une chaîne encodée en JSON portant un ensemble de clauses JSONPath, toutes combinées en AND. Décodé, l’objet de clause ressemble à : 
{
  "clauses": [
    { "path": "$.command",    "op": "regex",      "value": "rm -rf|drop table" },
    { "path": "$.connection", "op": "in",         "value": ["prod", "replica"] },
    { "path": "$.ip",         "op": "cidr_match", "value": "10.0.0.0/8" }
  ]
}
Dans un corps de requête, le champ porte cet objet sous forme de chaîne échappée, par exemple "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf\"}]}". Les opérateurs sont eq, contains, regex, in, cidr_match, gt et lt. Un args_match_json absent est vacuement vrai — la règle correspond sur le glob seul. Le langage de prédicat complet, la syntaxe des chemins et le comportement fail-closed d’une clause cassée sont dans Valider les arguments et le livre de recettes d’arguments.

​
7. egress_json — quelles destinations

Utilisé sur la surface egress : une chaîne encodée en JSON contenant une liste host / CIDR d’autorisation-et-refus, mise en correspondance avec une destination sortante qu’un outil atteint. Décodé, l’objet ressemble à : 
{
  "deny":  ["169.254.169.254", "10.0.0.0/8"],
  "allow": ["api.openai.com"]
}
Les entrées correspondent comme un CIDR, un littéral IP ou un nom d’hôte insensible à la casse. La polarité suit le verdict — avec un verdict appliquant, la liste deny définit ce qui est bloqué et allow y découpe des exceptions.
Le template firewall Baseline livre une règle d’egress deny avec une denylist SSRF / métadonnées cloud prête à l’emploi (l’IP de métadonnées 169.254.169.254, les plages RFC-1918, loopback, link-local et metadata.google.internal), de sorte que vous n’avez pas à les rédiger à la main. Ajoutez vos propres destinations par-dessus pour tout autre élément que vous voulez restreindre. Voir Contrôle d’egress pour la recette complète et Exfiltration de données pour comprendre pourquoi cela compte.

​
8. sanitize_json — redacter les arguments

Utilisé quand verdict = sanitize : une chaîne encodée en JSON nommant quels presets / regex personnalisées redactent les sous-chaînes correspondantes des arguments de l’outil avant que l’appel nettoyé ne soit transmis — utile pour retirer un secret ou une valeur PII qu’un agent a déposé dans un argument sans bloquer toute l’action. Décodé, l’objet ressemble à : 
{ "presets": ["email", "ssn_us"], "custom": ["foo-\\d+"] }
Sanitize redacte les arguments uniquement — jamais le contenu qu’un outil retourne. Une règle sanitize doit nommer au moins un preset ou motif personnalisé (un assainisseur vide est rejeté). Sur la surface inbound, il n’y a pas d’arguments au moment de l’appel à redacter, donc un verdict sanitize y escalade en un deny.
Voir Assainir les réponses pour la bibliothèque de presets et les formes de rédaction.

​
9. cap_cost_cents — un plafond de dépense

Utilisé quand verdict = cap_cost : un plafond de coût d’exécution par règle, un entier en centimes USD. Quand la règle correspond, l’appel est refusé dès que la dépense accumulée de l’exécution d’agent dépasse le plafond — un disjoncteur pour une boucle emballée, se résolvant en allow ou deny dans les événements. Le plafond doit être explicite et non négatif, et la règle ne peut être épinglée à response ou egress (où le verdict est inerte). Comportement complet dans Plafonner le coût.

​
10. Une règle complète

En assemblant les champs — refuser shell.exec, mais seulement quand la commande paraît destructrice, scopée aux appels d’outils émis par le modèle : 
{
  "priority": 10,
  "label": "block destructive shell",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|:\\\\(\\\\)\\\\{\"}]}",
  "verdict": "deny",
  "notes": "fork bombs and recursive deletes only — plain shell.exec audits"
}
La surface correspond à la surface response, le glob choisit shell.exec, la clause unique restreint à une commande destructrice, et le verdict refuse. Tout shell.exec dont la commande ne correspond pas à la regex retombe sur la règle suivante ou le défaut de la politique. Attachez une clé à la politique (firewall_policy_id sur la clé) et elle est en vigueur au prochain appel — aucun redéploiement.
Confirmez qu’une règle se déclenche sur exactement ce que vous attendez avant d’en dépendre : Tester les règles exécute en dry-run une politique contre un appel d’outil d’échantillon et renvoie le verdict, la règle correspondante et la raison sans rien dispatcher.

​
11. Comment les champs se combinent

Un verdict. Tout le reste est optionnel : un stage vide correspond à toutes les surfaces, un tool_name_glob vide (ou *) correspond à chaque outil, et un args_match_json absent correspond à n’importe quels arguments. Un simple { "verdict": "audit" } est un attrape-tout valide.
Ils font un AND. Une règle se déclenche seulement quand sa surface, son glob d’outil, son glob de skill, ses clauses d’arguments et sa portée d’egress tiennent tous. Pour exprimer un OR, écrivez des règles séparées.
sanitize_json n’est lu que pour le verdict sanitize ; cap_cost_cents seulement pour cap_cost ; egress_json seulement sur la surface egress. La console valide ces appariements à l’enregistrement, de sorte qu’une règle qui affiche un comportement mais ne peut jamais l’appliquer ne peut être persistée.
La priority la plus basse gagne (égalités départagées par l’id de règle) — la première correspondance gagne, et l’évaluation s’arrête là. Voir Priorité des règles.

​
Connexe

Créer une politique

Rédigez votre première politique et attachez une clé.

Syntaxe des globs

La grammaire complète des globs de nom d’outil.

Verdicts

Chaque verdict et à quoi ressemble un block.

Valider les arguments

Les clauses d’arguments JSONPath en profondeur.

Gérer les politiques

Éditer, versionner et annuler des politiques.

Règles Firewall

La référence complète du moteur de correspondance.
Nouveau sur le plan d’action ? Commencez par la Vue d’ensemble du Firewall, ou voyez comment il s’apparie avec le filtrage de texte dans Guardrails vs Firewall.