Passer au contenu principal
Mettre un outil en liste blanche répond à quel outil un agent peut appeler. Cela ne peut pas répondre à avec quels arguments. shell.exec va bien pour ls ; c’est un désastre pour rm -rf /. db.query va bien contre un replica ; contre prod c’est un risque. La différence vit dans les arguments, et une règle de nom d’outil ne peut pas la voir. Les clauses d’arguments (args_match_json) du Firewall comblent cette lacune. Elles inspectent les arguments concrets que le modèle a choisis pour un appel d’outil et décident le verdict à partir de leurs valeurs — de sorte que vous pouvez permettre un outil largement tout en refusant la seule forme dangereuse qu’il peut prendre. Cette page est le guide ciblé sur la rédaction de ces clauses ; pour le vocabulaire complet des règles voir Règles du Firewall, et pour le modèle de politique qui les entoure, Firewall.
Les valeurs d’arguments n’existent qu’une fois que le modèle a choisi comment appeler un outil, donc les clauses d’arguments ont leur place sur les stages response et mcp. Sur inbound — où l’agent n’annonce que des définitions d’outils — il n’y a pas d’arguments au moment de l’appel à vérifier.

​
1. Quand valider les arguments d’appel d’outil

Recourez à une clause d’argument chaque fois qu’un outil est sûr en général mais dangereux dans une forme spécifique :

Commandes destructrices

Autorisez shell.exec, mais refusez quand la commande correspond à rm -rf, mkfs ou dd if=.

Rayon d'impact en production

Autorisez db.query, mais refusez (ou mettez en attente d’approbation) quand la cible de connexion est prod.

Destinations internes

Autorisez un outil de fetch, mais refusez quand son argument url/ip tombe dans une plage RFC-1918 ou l’IP cloud-metadata.

Opérations surdimensionnées

Autorisez un outil de masse, mais refusez quand un argument limit ou count dépasse un plafond numérique.
La règle correspond toujours d’abord sur le nom d’outil ; les clauses la restreignent de quel outil à quel appel.

​
2. La forme d’un ensemble de clauses

args_match_json est une chaîne encodée en JSON dont la valeur décodée est un objet contenant une liste de clauses. Chaque clause est un triplet { path, op, value }, et toutes les clauses se combinent par AND — la règle ne se déclenche que lorsque chaque clause est vraie. Décodée, la valeur 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 règle, le champ porte ce JSON comme une seule chaîne échappée — par ex. "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf\"}]}". Un args_match_json vide ou absent est vacueusement vrai — la règle correspond sur son glob de nom d’outil seul, exactement comme le fait une règle uniquement basée sur le nom.

​
3. Opérateurs

Sept opérateurs constituent le vocabulaire fermé. La console valide l’opérateur et la forme de sa valeur lorsque vous enregistrez, de sorte qu’une clause malformée ne persiste jamais.
OpérateurCorrespond quand
eqÉgalité scalaire (les nombres sont comparés numériquement ; une incompatibilité de type est une non-correspondance).
containsSous-chaîne — les deux opérandes doivent être des chaînes.
regexUn motif Go RE2 correspond à la valeur de chaîne (temps linéaire, pas de backreferences).
inLa valeur est un élément du tableau JSON donné.
cidr_matchL’IP de chaîne tombe dans le CIDR donné.
gt / ltSupérieur-à / inférieur-à numérique (les chaînes ne sont pas coercées).

​
4. Syntaxe des chemins

Le path d’une clause est un petit sous-ensemble JSONPath sur l’objet d’arguments de l’outil :
Lire un champ d’objet de premier niveau ou imbriqué par son nom.
Indexer dans un tableau, en continuant optionnellement dans les champs de l’élément.
Faire correspondre contre le blob d’arguments entier (utile avec contains ou regex pour un scan grossier).
Il n’y a pas de wildcards, de filtres, de slices ou de descente récursive — la grammaire est délibérément petite pour que la correspondance reste en temps linéaire et prévisible sur le chemin critique.

​
5. Un exemple détaillé

Vous laissez vos agents exécuter shell.exec librement, mais une suppression forcée récursive ne devrait jamais atteindre le shell. Rédigez une règle de stage response qui refuse shell.exec uniquement quand l’argument de commande paraît destructeur.
1

Ouvrir l'éditeur de règles

Dans la console, ouvrez la politique firewall attachée à la clé de votre agent (ou le défaut de l’espace de travail) et ajoutez une règle. Éditer les politiques est une action Developer+ — les Members peuvent lire les politiques mais pas les écrire.
2

Faire correspondre l'outil sur le stage response

Définissez le stage sur response et le glob d’outil sur shell.exec. Le stage response porte les arguments choisis par le modèle, dont la clause a besoin.
3

Ajouter la clause d'argument

Ajoutez une clause regex sur $.command, puis définissez le verdict sur deny :
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm\\\\s+-rf|mkfs|dd\\\\s+if=\"}]}"
}
args_match_json est une chaîne encodée en JSON ; sa valeur décodée est l’objet { "clauses": [ … ] } montré dans §2.
4

L'exécuter en dry-run avant de vous y fier

Utilisez l’onglet Test pour évaluer la règle contre un appel shell.exec d’échantillon. Il renvoie le verdict, la règle correspondante et la raison — rien n’est dispatché et rien n’est persisté.
Désormais, shell.exec avec "command": "ls -la" passe comme auparavant, tandis que "command": "rm -rf /var" est refusé. Un deny sur response laisse le modèle voir une erreur d’outil et réagir — choisir un autre outil, demander à l’utilisateur, ou s’arrêter — plutôt que de planter.
Vous voulez permettre l’appel mais retirer une valeur fuitée au lieu de bloquer ? Remplacez le verdict par sanitize. Sanitize ne redacte pas ce que la clause a fait correspondre — il exécute un redacteur séparé (presets nommés comme openai_key, anthropic_key, ssn_us, plus vos propres regex custom) sur les chaînes d’arguments, remplace chaque occurrence par un token [redacted:…], et transmet l’appel nettoyé. La clause args_match_json décide toujours si la règle se déclenche ; l’assainisseur décide ce qui est nettoyé. Voir Assainir les arguments. Sanitize redacte les arguments de l’appel d’outil seulement — jamais le contenu qu’un outil renvoie.

​
6. Les clauses fail closed — la règle, pas la requête

Si une clause ne peut pas être évaluée — le chemin ne se résout pas, les arguments sont malformés, ou une regex / un CIDR est invalide — la clause s’évalue à false et la règle simplement ne se déclenche pas. L’appel retombe sur la règle suivante ou le default_verdict de la politique. Une clause cassée ne refuse jamais automatiquement et ne perturbe jamais le relais.
Parce qu’une clause qui ne peut pas s’évaluer fait que sa règle ne correspond pas, ne comptez jamais sur une clause pour échouer d’une façon particulière. Rédigez votre règle « tout attraper de dangereux » comme un deny explicite avec son propre glob d’outil, et utilisez les clauses d’arguments pour restreindre une autorisation — pas comme votre dernière ligne de défense.

​
7. Combiner les clauses avec le reste d’une règle

Les clauses d’arguments s’empilent avec tout le reste qu’une règle exprime — elles sont une condition combinée par AND parmi plusieurs :
Combiner avecEffet
tool_name_globLa clause ne s’exécute qu’une fois que le nom d’outil correspond — le nom d’abord, les arguments ensuite.
skill_name_globFiltrer différemment les arguments du même outil par skill propriétaire (par ex. plus strict sur community.*).
verdictAssocier les clauses à deny, sanitize, pending_approval ou cap_cost, pas seulement deny.
Plusieurs clausesToutes doivent tenir — combiner une vérification de commande regex avec une vérification d’environnement in pour scoper un deny étroitement.
Pour la sémantique exacte des verdicts que chaque association produit, voir Verdicts ; pour savoir comment un appel mis en attente se résout, voir Approbations.

​
8. Où cela s’insère

Règles du Firewall

La référence complète des règles — globs, clauses, assainisseurs, egress et séquences.

Recettes d'arguments

Des recettes args_match_json à copier-coller pour les formes dangereuses courantes.

Stages du firewall

Pourquoi les clauses d’arguments vivent sur response et mcp, pas inbound.

Bloquer des outils

Refuser un outil purement et simplement quand aucun argument n’est sûr.
Pour la vue d’ensemble, voir Appels d’outils dangereux et Comment OrcaRouter inspecte.