Le langage de correspondance derrière une politique de firewall. Faites correspondre les appels d’outils par nom, skill, arguments et destination — puis allow, audit, deny, sanitize, hold for approval, ou cap cost. Déterministe, fail-closed et sûr sur le chemin à chaud.
Une politique de firewall est une liste ordonnée
de règles. Cette page est la référence complète de ce qu’une règle peut
exprimer — le langage de correspondance, les verdicts, et comment le moteur
les évalue.Les règles sont rédigées dans l’éditeur de règles de la console, qui écrit
des objets de correspondance JSON structurés. Tout ce qui suit décrit ce
vocabulaire afin que vous puissiez lire, raisonner et vérifier une règle
précisément — que vous la construisiez dans l’UI ou que vous la postiez via
l’API.
Justification de l’auteur ; ignorée par le moteur.
Une règle correspond à un appel d’outil lorsque toutes ses conditions
déclarées sont vérifiées : le stage correspond (ou est vide), le glob
d’outil correspond, le glob de skill correspond (ou est vide), les clauses
d’arguments correspondent (ou sont absentes), et la portée d’egress
correspond (règles egress uniquement). Le moteur parcourt les règles dans
l’ordre de priorité et la première correspondance gagne.
Une grammaire délibérément petite, sensible à la casse — pas de surprises
de regex, temps linéaire, sûre sur le chemin à chaud du relais :
Motif
Correspond à
"" ou *
Tous les outils.
foo.*
Préfixe — foo.bar, foo.exec (pas foo seul).
*.exec
Suffixe — shell.exec, db.exec (pas exec seul).
*.shell.*
Infixe — local.shell.exec (nécessite ≥1 caractère de chaque côté).
tout le reste
Correspondance de chaîne exacte (y compris foo.*.bar).
Les outils sont conventionnellement nommés en namespace server.tool ou
category.action, donc shell.* attrape une famille entière et *.delete
attrape un verbe à travers les serveurs.
La même grammaire de glob, mise en correspondance avec le skill
propriétaire de l’appel d’outil (par exemple community.*,
builtin.send). Il est AND-é avec tool_name_glob, donc :
correspond à http.fetchseulement lorsqu’il appartient à un skill
community.* — faites confiance au même outil depuis un skill intégré,
verrouillez-le depuis un skill communautaire. Un glob de skill vide
correspond à n’importe quel propriétaire. La façon dont un appel d’outil est
attribué à un skill est couverte dans
Skills.
La correspondance par nom d’outil répond quel outil ; les clauses
d’arguments répondent avec quels arguments — la différence entre « bloquer
shell.exec » et « bloquer shell.exec seulement quand la commande est
rm -rf ».args_match est un ensemble de clauses, toutes AND-ées ensemble :
Un petit sous-ensemble de JSONPath sur l’objet d’arguments de l’outil :
$.foo, $.foo.bar — accès à un champ
$.foo[0], $.arr[1].k — indexation de tableau
$ — l’objet d’arguments entier
Pas de wildcards, de filtres, de slices ni de descente récursive.
Les clauses d’arguments fail closed — la règle, pas la requête. Si un
chemin ne se résout pas, que les arguments sont malformés, ou qu’une
regex/CIDR est invalide, la clause s’évalue à false et la règle ne se
déclenche tout simplement pas — l’appel retombe sur la règle suivante ou le
verdict par défaut. Une clause cassée ne refuse jamais automatiquement et ne
fait jamais planter le relais. Rédigez votre règle « attraper tout ce qui
est dangereux » comme un deny explicite avec son propre glob plutôt que de
compter sur une clause pour échouer d’une manière particulière.
La console valide les clauses strictement à l’enregistrement (opérateurs
inconnus, mauvais chemins, valeurs in non-tableau, regexes
non-compilables et CIDR invalides sont tous rejetés) afin qu’une clause
malformée ne puisse pas être persistée en premier lieu.
Un verdict sanitize redacte les sous-chaînes correspondantes des
arguments de l’outil et transmet l’appel nettoyé — utile pour retirer des
secrets ou de la PII qu’un agent a mis dans un argument d’outil sans bloquer
toute l’action.
Les correspondances de preset sont remplacées par [redacted:<preset>] ;
les correspondances de regex personnalisée par [redacted:custom]. La
bibliothèque de presets intégrée :aws_access_key, aws_secret_key, openai_key, anthropic_key,
bearer_token, email, ssn_us, credit_card (avec une vérification de
Luhn).Une règle sanitize doit déclarer au moins un preset ou un motif
personnalisé — un assainisseur vide est rejeté à l’enregistrement. 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 block.
Les entrées correspondent comme un CIDR, un littéral IP, ou un nom d’hôte
insensible à la casse ; les noms d’hôtes sont résolus au mieux et
re-vérifiés contre les entrées IP/CIDR. La polarité suit le verdict : avec
un verdict allow, la liste allow définit ce qui est dans la portée et
deny y découpe des exceptions ; avec un verdict appliquant (deny), la
liste deny définit ce qui est bloqué et allow y découpe des exceptions.169.254.169.254 (l’endpoint de métadonnées cloud) et les plages RFC-1918
sont les choses canoniques à refuser — le preset block_ssrf_egress et le
niveau d’autonomietight livrent exactement cela.
Certains risques ne sont visibles qu’à travers plusieurs appels — lire 50
enregistrements CRM, puis exporter, puis atteindre un hôte externe. Une
règle sequence correspond à une chaîne ordonnée plutôt qu’à un seul
appel :
Chaque étape est un glob d’outil avec un min_count optionnel (défaut 1) et
un egress: true optionnel (l’étape doit être un appel d’egress). Les
étapes doivent se produire dans l’ordre — l’entrelacement avec d’autres
appels est acceptable — et toute la chaîne doit se compléter dans
window_seconds (0 = pas de borne).
Les séquences sont appliquées réactivement par un matcher asynchrone,
pas en ligne sur chaque appel — une séquence avec une étape *
correspondrait sinon à chaque appel d’outil. Elles éclairent le flux des
événements et peuvent déclencher une action de suivi, mais elles ne bloquent
pas en temps réel l’appel individuel qui complète la chaîne.
Partez d’un preset plutôt que d’une règle vierge. Ils sont rédigés côté
serveur afin que la console et cette documentation décrivent un comportement
identique :
Preset
Ce qu’il fait
block_destructive_shell
Refuse les commandes shell destructrices (rm -rf, mkfs, dd, fork bombs, …) via un ensemble de règles deny-par-glob.
block_ssrf_egress
Audite l’egress vers l’endpoint de métadonnées et les plages RFC-1918.
block_secrets_in_args
Orienté détection — signale les credentials apparaissant dans les arguments d’outils.
block_pii_in_tool_results
Orienté détection — fait remonter la PII dans les résultats d’outils.
Appliquez un preset comme une graine, puis modifiez librement — un preset
est un point de départ, pas un verrou.
La première correspondance gagne. Les règles s’exécutent dans l’ordre
priority ASC, id ASC ; la première règle dont toutes les conditions sont
vérifiées décide du verdict. Aucune règle ne correspond → le
default_verdict de la politique.
Déterministe et sans dépendance. La correspondance de glob et de
clause sont de pures opérations sur chaînes/JSON sans appel réseau, sûres
à exécuter sur chaque appel d’outil. Les regexes sont RE2 — temps
linéaire, sans backtracking catastrophique.
Clauses fail-closed. Une clause qui ne peut pas être évaluée fait que
sa règle ne se déclenche pas plutôt que de refuser automatiquement
(§4).
Validation stricte à l’enregistrement. Les appariements
verdict/stage, la non-vacuité de l’assainisseur, la présence de
cap_cost_cents, la forme des clauses et la résolution des références
sont tous vérifiés lorsque vous enregistrez — les règles invalides ne
peuvent pas être persistées.
Audité. Chaque création/mise à jour/suppression de règle écrit une
ligne d’audit après le commit du changement ; les blobs de règles et les
secrets ne sont jamais écrits dans le journal d’audit.
Vous souhaitez approfondir la sécurité des agents ? Les guides Sécurisez vos agents (Zero Trust) replacent cette fonctionnalité dans un workflow zero-trust.
Construire une politique de pare-feu
Rédigez une politique zero-trust étape par étape, puis testez-la en mode observation avant de l’appliquer.
Référence du schéma de règles
Chaque champ de règle — globs, prédicats d’arguments, sorties et plafonds de coût.
