Passer au contenu principal
Quand un modèle répond, il ne renvoie pas que du texte — il émet des tool_calls : des invocations concrètes avec des arguments réels, choisis par le modèle. La surface response du firewall agent inspecte exactement ceux-là, au moment où ils quittent le modèle et avant qu’ils n’atteignent votre boucle d’agent. C’est la surface où vous filtrez ce que le modèle a réellement décidé de faire, avec les arguments qu’il a réellement choisis. Cette page couvre le cas d’usage du filtrage sur la surface response — quand y recourir plutôt qu’à inbound, la seule torsion de verdict qu’elle ajoute, et comment elle se comporte sur un stream. Pour le vocabulaire complet des règles et la sémantique des verdicts, voir Schéma de règle et Verdicts.

​
1. Filtrer les appels de réponse d’outil llm, avec les arguments en portée

Le stage inbound voit les outils que vous annoncez — des noms seulement, pas encore d’arguments au moment de l’appel. Le stage response voit les tool_calls que le modèle émet, qui portent les arguments que le modèle a choisis. C’est toute la raison de filtrer ici : c’est la seule surface qui voit l’appel réel + les arguments pour un outil exécuté par le client (non-MCP), de sorte que les clauses d’arguments, les séquences et les règles d’état d’exécution atterrissent toutes sur response. La distinction en une ligne :
StageVoitUtilisez-le pour
inboundLes définitions d’outils annoncéesRendre un outil invisible au modèle
responseLes tool_calls émis + argumentsFiltrer l’appel que le modèle a réellement fait
Donc inbound répond à quels outils existent ; response répond à ce que le modèle a fait avec l’un d’eux. Recourez à response (ou laissez stage vide pour couvrir les deux) quand un outil apparaît légitimement dans certaines requêtes mais qu’un appel particulier de celui-ci est dangereux — ou quand vous ne contrôlez que la boucle d’agent, pas l’ensemble d’outils annoncé.
Une règle sans stage s’exécute sur chaque surface, y compris response. Épinglez à response uniquement quand une règle ne devrait inspecter que les appels émis — par exemple une clause d’argument qui n’a de toute façon rien à faire correspondre sur la surface inbound. Voir Stages.

​
2. Un exemple concret

Autorisez shell.exec en général, mais retirez-le de la réponse du modèle au moment où son argument command paraît destructeur. Dans la console de votre espace de travail, ouvrez une politique (ou créez-en une) et ajoutez une règle épinglée à la surface response : 
{
  "label": "block destructive shell calls",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
Le matcher d’arguments vit dans args_match_json — une chaîne JSON contenant {"clauses":[…]}, chaque clause un triplet path / op / value (op est l’une des valeurs eq, contains, regex, gt, lt). Le formulaire de la console le construit pour vous ; la forme brute est montrée ici pour que le nom du champ soit sans ambiguïté. L’outil reste annoncé — le modèle peut toujours proposer shell.exec — mais quand l’appel émis porte un command destructeur, le firewall retire ce tool_call de la réponse avant que votre agent ne le voie jamais. Un shell.exec bénin (disons ls -la) passe intact. C’est le pattern « autoriser l’outil, filtrer l’appel » pour lequel la surface response existe ; la clause d’argument est ce qui le rend possible.
Les règles s’évaluent dans l’ordre de priorité, la première correspondance gagne. Placez une exception allow étroite à un numéro de priority plus bas qu’un deny large pour que l’exception s’exécute en premier. Voir Priorité des règles.

​
3. Ce que fait un verdict sur la surface response

La surface response inspecte chaque tool_call émis et réécrit la réponse sur place. Les appels conservés sont transmis octet pour octet ; seul un appel correspondant change :
Le tool_call correspondant est retiré de la réponse du modèle avant qu’il n’atteigne votre agent. Contrairement à un deny inbound — qui renvoie HTTP 400 avec le code firewall_blocked — un deny de surface response ne fait pas échouer la requête ; le reste de la réponse (autres appels d’outils, tout texte) circule avec l’appel fautif simplement absent.
Les sous-chaînes correspondantes dans les arguments de l’appel sont remplacées par les arguments redactés du moteur et l’appel nettoyé est transmis — utile quand l’outil va bien mais que le modèle a mis une valeur de secret ou de PII dans un argument. Sanitize redacte les arguments de l’appel d’outil uniquement ; il ne touche jamais au contenu qu’un outil renvoie. Si le moteur n’a rien à substituer, l’appel est retiré (fail-closed). Voir Assainir les réponses.
Le human-in-the-loop met en attente sur la surface inbound, pas response. Une règle pending_approval qui correspond en premier sur un appel émis est donc retirée (fail-closed) — la conserver transmettrait un appel non revu sans décision humaine. Rédigez les mises en attente HITL pour qu’elles se déclenchent en inbound ; voir Approbations.
allow et audit transmettent tous deux l’appel ; audit est le default_verdict habituel — tout enregistrer, ne rien bloquer, jusqu’à ce que vous soyez prêt à appliquer.
cap_cost et pending_approval sont des concepts inbound sur cette surface. cap_cost est inerte sur response (le modèle s’est déjà exécuté), et pending_approval se résout en un retrait plutôt qu’une mise en attente. Placez les plafonds de coût et les mises en attente HITL sur la surface inbound — voir Plafonner le coût et Approbations.

​
4. Streaming : mis en attente, puis filtré

Sur une réponse non-stream, toute la réponse est parsée et filtrée d’un coup. Sur un stream, les tool_calls d’un modèle arrivent comme des deltas par index à travers de nombreuses frames SSE — et une fois qu’un delta est transmis, votre agent l’a déjà et il ne peut pas être rétracté. Donc la passerelle retient les frames d’appel d’outil : elles ne sont jamais transmises en milieu de stream. À la fin du stream, le firewall assemble chaque appel (nom + arguments complets), l’évalue, et n’émet que les appels survivants.
Les frames de contenu streament quand même normalement — les tokens de texte atteignent votre client au fur et à mesure. Seules les frames tool_call sont retenues pour évaluation, de sorte qu’un appel refusé ou assaini est filtré avant que l’appel d’outil assemblé ne soit livré. Le verdict et la sémantique des règles sont identiques à la surface non-stream. Pour les détails au niveau des frames, voir Rouages du streaming et Streaming par fournisseur.

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

L’onglet Test de la console exécute une politique 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 et votre clause d’argument correspondent à l’appel que vous visiez avant d’attacher une clé. Voir Tester les règles.
Activez le mode shadow et chaque verdict appliquant — y compris un deny de surface response — est rétrogradé en audit, raison préfixée [shadow] would …. Vous mesurez exactement ce que la règle retirerait contre le trafic réel avant qu’elle ne change une seule réponse.
Chaque évaluation écrit un événement firewall avec le verdict, la surface, l’outil et la règle correspondante. Filtrez le journal d’événements par surface response pour voir votre règle se déclencher sur les appels émis que vous attendiez. Voir Analytics.

​
6. Attacher la politique et qui peut la configurer

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. Résolution : la politique attachée de la clé (lorsqu’elle existe et est activée), sinon le défaut de l’espace de travail — et une politique attachée mais désactivée retombe sur le défaut de l’espace de travail. Voir Gérer les politiques. Toute la configuration s’exécute dans la console sous votre session (/api/workspace/firewall/*) :
ActionRôle
Lire les politiques, presets, outils découverts, SimulateMember
Dry-run (Test), lire le journal d’événements et les agrégations d’exécutionsDeveloper+
Créer / éditer / supprimer des règles et des politiquesDeveloper+

​
Connexe

Valider les arguments

Les clauses d’arguments qui rendent le filtrage de surface response précis.

Assainir les réponses

Redacter les secrets des arguments d’un appel au lieu de le retirer.

Stages du firewall

Comment response se compare à inbound, mcp et egress.

Bloquer des outils

Le pendant inbound : refuser un outil avant qu’il ne soit proposé au modèle.

Appels d'outils dangereux

La menace que le filtrage des réponses traite.

Référence du Firewall

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