Passer au contenu principal
Une politique firewall décide d’une seule chose à propos de chaque appel d’outil que votre agent effectue : un verdict. Soit une règle correspond et produit un verdict, soit aucune règle ne correspond et le verdict par défaut de la politique prend le relais. Cette page couvre les deux — ce que fait chaque verdict de firewall, comment cap_cost se résout, et pourquoi audit est le défaut à partir duquel vous commencez. Pour savoir où vivent les verdicts dans la grammaire des règles, voir Règles du Firewall ; pour choisir un verdict par défaut lors de la création d’une politique, voir Créer et attacher.

​
1. Les six verdicts de règle

Une règle produit exactement l’un des six verdicts. Rédigez-les dans l’éditeur de règles de la console ; le moteur parcourt les règles dans l’ordre de priorité et la première correspondance gagne.
L’appel se poursuit intact. Il atterrit quand même dans le flux d’événements comme un allow, de sorte que vous conservez une piste d’audit sans rien bloquer. Utilisez-le comme une autorisation explicite dans une politique default-deny.
Résultat de trafic identique à allow, mais l’appel est marqué comme quelque chose que vous vouliez surveiller. C’est aussi la valeur sur laquelle le verdict par défaut atterrit par défaut — tout observer, ne rien bloquer, jusqu’à ce que vous soyez prêt à appliquer.
L’appel n’atteint jamais l’outil. Sur la surface inbound, le relais renvoie HTTP 400 avec le code d’erreur firewall_blocked, nommant l’outil et la raison ; sur la surface mcp il revient comme une erreur d’outil afin que le modèle puisse réagir. Voir à quoi ressemble un block.
Redacte les sous-chaînes correspondantes des arguments de l’appel d’outil (un secret ou de la PII que l’agent a mis dans un champ command ou body) et transmet l’appel nettoyé. Il redacte les arguments seulement — jamais le contenu qu’un outil renvoie. Sur la surface inbound, il n’y a pas encore d’arguments au moment de l’appel, donc sanitize escalade en un deny. Voir assainir les réponses.
Transforme l’appel en une revue hors-bande. Le relais renvoie HTTP 400 avec le code firewall_approval_pending et un id d’approbation ; l’appel n’atteint pas l’outil. Un relecteur le résout dans la console ou via un callback webhook, et l’agent re-soumet avec un en-tête d’approbation à usage unique. Voir approbations.
Un disjoncteur de coût — rédigé comme une règle mais résolu en allow ou deny au moment de l’évaluation. Voir §3 et plafonner le coût.
Le mode shadow aplatit l’application. En mode shadow, chaque verdict appliquant (deny, sanitize, pending_approval, et un cap_cost qui s’est résolu en deny) est rétrogradé en audit et la raison est préfixée [shadow] would …. Déployez une politique appliquante de cette façon et surveillez le flux d’événements avant de la passer en live.

​
2. Le verdict par défaut

Le verdict par défaut (default_verdict sur la politique) est ce que fait la politique lorsqu’aucune règle ne correspond à un appel d’outil. C’est le plancher de votre posture, et contrairement à un verdict de règle, il n’accepte que trois valeurs :
default_verdictQuand aucune règle ne correspond…
audit (défaut)Autorise l’appel, mais l’enregistre. L’endroit sûr pour commencer.
allowAutorise et journalise, sans enregistrement de revue.
denyBloque tout ce qu’une règle ne permet pas explicitement — une posture default-deny.
Une nouvelle politique a pour défaut audit : elle observe chaque appel d’outil et ne bloque rien jusqu’à ce que vous ajoutiez des règles appliquantes. Les trois verdicts réservés aux règles — sanitize, pending_approval et cap_cost — ne peuvent pas être un défaut ; un verdict par défaut est un fallback général, et ces verdicts n’ont de sens que scopés à une correspondance spécifique.
deny comme verdict par défaut est default-deny : tout appel d’outil que vos règles n’allowent pas explicitement est bloqué. Puissant pour un agent verrouillé, mais il arrêtera les appels que vous avez oublié de mettre en liste blanche. Associez-le à des règles allow explicites (liste blanche d’outils) et déployez-le d’abord sous le mode shadow.

​
3. cap_cost se résout en allow ou deny

cap_cost est le seul verdict qui n’est pas ce qui apparaît dans vos événements. Vous rédigez une règle avec un plafond cap_cost_cents, mais au moment de l’évaluation le moteur le résout en un allow ou deny concret avant que l’événement ne soit enregistré — de sorte que le flux d’événements ne porte jamais un verdict cap_cost littéral, seulement l’allow/deny que l’agent a réellement vu. Le plafond est par exécution d’agent : le moteur compare la dépense accumulée de l’exécution à votre plafond.
  • Sous le plafond → se résout en allow. (En interne, c’est traité comme non-correspondant, de sorte que l’évaluation continue vers la règle suivante plutôt que de laisser cap_cost gagner en première correspondance comme une autorisation.)
  • Au-dessus du plafond → se résout en deny, avec une raison nommant le total de l’exécution par rapport au plafond. C’est le résultat terminal de disjoncteur.
// A rule that caps a run at $5.00 of accumulated spend.
{
  "label": "run cost ceiling",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
cap_cost ne se déclenche que sur les surfaces de pré-dispatch (inbound, mcp) — les points où bloquer un appel empêche encore la dépense. Sur les surfaces de post-dispatch response et egress, il est inerte (il n’y a plus rien à arrêter), donc le moteur le saute là.

​
4. Comment un verdict est choisi

Pour tout appel d’outil, la résolution est la même quel que soit le verdict qui gagne :
La passerelle choisit la politique attachée à la clé appelante (firewall_policy_id), ou le défaut de l’espace de travail — voir résolution.
Les règles s’exécutent dans l’ordre priority ASC. La première règle dont la surface, le glob d’outil, les clauses d’arguments optionnelles et la portée d’egress optionnelle correspondent toutes produit le verdict.
Si aucune règle ne correspond, le default_verdict de la politique s’applique — audit sauf si vous l’avez changé.
Si l’appel appartient à un skill gouverné, un skill en mode block force un deny et un skill en mode quarantine escalade tout ce qui est en-deçà d’un deny vers pending_approval.

​
5. Comportement de coût et de retry d’un deny

Un verdict de firewall sur la surface inbound se déclenche avant l’appel au modèle amont, donc un deny là ne coûte aucun token de modèle. L’erreur est marquée skip-retry — ré-exécuter le même appel bloqué ne ferait que bloquer à nouveau, donc la passerelle indique au client de ne pas le réessayer. Ceci est distinct d’un block de guardrail, qui filtre le texte des prompts/réponses (PII, secrets) plutôt que les actions d’outils, et renvoie sa propre erreur guardrail_blocked. Une requête peut traverser les deux plans.
Chaque verdict laisse une trace. Chaque évaluation — allow, audit, deny, le cap_cost résolu, l’approbation mise en attente — est enregistrée comme un événement firewall, filtrable par verdict, surface, outil et exécution. Le flux d’événements est votre moyen de confirmer qu’une politique produit les verdicts que vous attendez. Voir journal d’événements et analytics.

​
Où aller ensuite

Créer et attacher une politique

Choisissez un verdict par défaut et liez une politique à une clé.

Plafonner le coût

Rédigez un plafond de dépense et la façon dont il se résout par exécution.

Mode shadow

Rétrogradez chaque verdict appliquant en audit pendant que vous mesurez l’impact.

Référence des règles

Le langage de correspondance complet derrière un verdict.
Pour les menaces que ces verdicts sont censés arrêter, voir appels d’outils dangereux et agence excessive.