Passer au contenu principal
Le moyen le plus rapide d’empêcher un agent de faire quelque chose de dangereux est de nommer l’outil et de le refuser. Un verdict deny sur un glob de nom d’outil est la primitive de deny-list du firewall agent : une règle, un glob, le verdict deny, attaché à une clé — et dès lors la passerelle refuse cet outil à chaque appel, sans aucun changement de code dans votre agent. Cette page couvre le cas d’usage de la deny-list et la seule décision qu’elle impose : sur quelle surface bloquez-vous — les outils que vous annoncez (inbound) ou les appels d’outils que le modèle émet (response). Pour le vocabulaire de correspondance complet et la sémantique des verdicts, voir Schéma de règle et Verdicts.

​
1. Bloquer un appel d’outil qu’un agent IA effectue

Une règle de deny-list est la chose la plus simple qu’une politique firewall puisse exprimer : faire correspondre un outil par nom, renvoyer deny. Utilisez-la lorsqu’un outil ne devrait jamais se déclencher pour une clé donnée — shell.exec, *.delete, un plugin communautaire en lequel vous n’avez pas confiance — quels que soient les arguments. Dans la console de votre espace de travail, ouvrez une politique (ou créez-en une) et ajoutez une règle : 
{
  "label": "block destructive shell",
  "tool_name_glob": "*.exec",
  "verdict": "deny"
}
Le tool_name_glob est un petit glob sensible à la casse — shell.* attrape toute une famille, *.delete attrape un verbe à travers les serveurs, * attrape tout. Aucune clause d’argument n’est nécessaire : un glob nu + deny bloque l’outil sans condition. Ajoutez une clause d’argument seulement lorsque vous voulez autoriser l’outil en général mais refuser une forme d’appel.
Le moteur parcourt les règles d’une politique dans l’ordre de priorité et la première correspondance gagne. Placez les exceptions allow étroites à un numéro de priority plus bas (elles s’exécutent en premier) et votre deny large en-dessous — par ex. autoriser shell.exec depuis un skill builtin.* de confiance, le refuser partout ailleurs. Voir Priorité des règles.

​
2. Inbound vs response : choisir la surface

Un deny peut atterrir sur deux points différents du cycle de vie de la requête, et la différence compte. Épinglez la règle avec le champ stage, ou laissez-le vide pour couvrir les deux.

inbound

Les outils que votre agent annonce au modèle sur la requête (les définitions d’outils). Un deny ici retire l’outil avant que le modèle puisse même le choisir — le modèle ne le voit jamais comme une option.

response

Les tool_calls que le modèle émet dans sa réponse. Un deny ici attrape l’appel que le modèle a déjà décidé de faire, avant qu’il n’atteigne l’outil.
Préférez inbound lorsque vous voulez qu’un outil soit invisible — le modèle ne peut pas appeler ce qui ne lui a jamais été proposé, donc vous évitez les tours gaspillés où il choisit un outil pour se voir refuser. Utilisez response (ou laissez stage vide) lorsque l’outil apparaît légitimement dans certaines requêtes et que vous voulez attraper l’appel réellement émis, ou lorsque vous ne contrôlez que la boucle d’agent et pas l’ensemble d’outils annoncé.
Une règle sans stage s’applique à toutes les surfaces — le même deny couvre un outil qu’il soit annoncé, émis ou dispatché à travers MCP. C’est le défaut ceinture-et-bretelles ; n’épinglez une surface que lorsqu’un deny doit être scopé à une seule. Voir Stages.

​
3. Attacher la politique et la voir se déclencher

Une politique ne fait rien jusqu’à ce qu’une clé s’y résolve. Attachez dans la console en définissant firewall_policy_id sur la clé, ou faites de la politique le défaut de l’espace de travail. La résolution est : la politique attachée de la clé (lorsqu’elle existe et est activée), sinon le défaut de l’espace de travail. (Une politique attachée mais désactivée retombe sur le défaut — voir Gérer les politiques.) Une fois attachée, un appel refusé sur la surface inbound renvoie HTTP 400 avec le code d’erreur firewall_blocked et une raison nommant l’outil — par ex. tool "shell.exec" blocked by firewall. L’erreur est marquée skip-retry (ré-exécuter l’appel identique ne ferait que bloquer à nouveau) et ne coûte aucun token de modèle, puisqu’un block inbound se déclenche avant l’appel amont. Un deny dispatché à travers la passerelle MCP apparaît plutôt comme une erreur d’outil, de sorte que le modèle voit le rejet et peut réagir.
Un deny sur la surface inbound retire l’outil de ce qui est proposé au modèle. Si votre framework d’agent exige qu’un outil qu’il a annoncé soit appelable, le bloquer en inbound peut perturber la boucle — dans ce cas bloquez sur response à la place, de sorte que l’outil reste annoncé mais que l’appel réel est refusé. Testez la différence avant de déployer (voir §5).

​
4. Deny est l’un de plusieurs verdicts

Deny est l’outil le plus brutal de la deny-list. Quand un block dur est de trop, le même glob peut porter un verdict plus doux :
VerdictQuand y recourir au lieu de deny
auditVous voulez voir l’outil se déclencher mais pas encore le bloquer.
sanitizeL’outil est correct mais ses arguments peuvent porter des secrets/PII — redacte les args, jamais les résultats d’outils.
pending_approvalUn humain devrait approuver chaque appel hors-bande.
cap_costAutorise jusqu’à ce que la dépense d’une exécution d’agent franchisse un plafond en centimes.
Tous ceux-ci sont documentés dans Verdicts. Une deny-list n’est que le sous-ensemble où le verdict est deny. Pour une posture de liste blanche (refuser tout, permettre un ensemble nommé), passez le default_verdict de la politique à deny et ajoutez des règles allow étroites — voir Liste blanche d’outils.

​
5. Le déployer en toute sécurité

L’onglet Test de la console exécute une politique en dry-run contre un appel d’outil d’échantillon et renvoie le verdict, la règle correspondante et la raison — rien n’est dispatché, rien n’est persisté. Confirmez que votre glob correspond à l’outil que vous visiez (et seulement cet outil) avant d’attacher une clé. Voir Tester les règles.
Activez le mode shadow sur la politique et chaque verdict appliquant — y compris votre deny — est rétrogradé en audit, raison préfixée [shadow] would …. Vous mesurez exactement ce que le deny bloquerait contre le trafic réel, puis désactivez le shadow pour appliquer.
Pas sûr du nom d’outil exact à globber ? La vue Discovered Tools liste chaque outil que l’espace de travail a vu, marqué covered ou gap. Rédigez votre deny directement à partir des noms qui sont réellement apparus. Voir Analytics.
Chaque évaluation écrit un événement firewall avec le verdict, la surface, l’outil et la règle correspondante. Après avoir appliqué, filtrez le journal d’événements par verdict deny pour voir la règle se déclencher sur les appels que vous attendiez.

​
6. Qui peut faire quoi

Toute la configuration de deny-list s’exécute dans la console sous votre session (/api/workspace/firewall/*) :
ActionRôle
Lire les politiques, presets, outils découverts, SimulateMember
Dry-run d’une politique (Test)Developer+
Créer / éditer / supprimer des règles et des politiquesDeveloper+
Lire le journal d’événements et les agrégations d’exécutionsDeveloper+
Rédiger ou modifier une règle deny est une écriture Developer+, tout comme le dry-run Test de la console. Lire une politique et la vue Simulate (« what-if ») en lecture seule sont ouvertes à chaque membre.

​
Connexe

Syntaxe glob

Exactement comment shell.*, *.exec et *.shell.* correspondent.

Liste blanche d'outils

La posture inverse : default-deny, permettre un ensemble nommé.

Valider les arguments

Refuser une seule forme d’appel, pas tout l’outil.

Appels d'outils dangereux

La menace qu’une deny-list traite.

Verdicts

Ce que font deny et ses frères plus doux sur le fil.

Référence du Firewall

La référence complète des règles + correspondance.