Passer au contenu principal
Une règle de firewall se déclenche à un point précis du cycle de vie d’un appel d’outil. Ce point est son stage — l’une de quatre surfaces d’application, chacune voyant une tranche différente de l’appel. Épinglez une règle au mauvais stage et elle voit les mauvaises données : une allowlist d’egress sur la surface inbound n’a aucune destination à vérifier ; une clause d’argument sur inbound n’a pas encore d’arguments au moment de l’appel. Cette page est le guide ciblé sur les quatre stages du firewall agent : ce que chaque surface observe, quand une règle devrait la cibler, et la façon concrète dont une même intention s’exprime à différents stages. Pour le vocabulaire complet des règles, voir Règles du Firewall ; pour le modèle de politique qui l’entoure, Firewall.

​
1. Les quatre stages en un coup d’œil

Chaque évaluation est estampillée d’exactement un stage. Une règle sans stage ("") s’applique à tous ; une règle épinglée à un stage ne se déclenche que là.
StageCe que la surface voit
inboundLes outils que l’agent annonce sur la requête
responseLes tool_calls que le modèle émet dans sa réponse
mcpUn tools/call dispatché à travers la passerelle MCP
egressUn host / IP / CIDR sortant qu’un outil atteint
Les noms de stage sont des valeurs enum stables — vous les définissez verbatim dans le champ stage de l’éditeur de règles, ou comme propriété stage lors de la rédaction via l’API.
Le stage gouverne quelles données sont en portée, pas à quel point le verdict est strict. Un deny est un deny sur n’importe quel stage ; ce qui change, c’est si la règle dispose des arguments, du nom d’outil ou de la destination dont elle a besoin pour correspondre.

​
2. inbound — les outils qu’un agent annonce

La surface la plus précoce. Avant même que le modèle ne s’exécute, votre agent envoie une liste de définitions d’outils qu’il accepte de laisser le modèle appeler. Le stage inbound voit cet ensemble d’outils annoncé et peut bloquer un outil dangereux avant même que le modèle puisse le choisir. Il n’y a pas d’arguments au moment de l’appel à ce stage — le modèle n’a pas encore décidé comment appeler quoi que ce soit — donc les règles inbound correspondent sur le nom d’outil (et optionnellement son skill propriétaire), pas sur args_match_json.
Un verdict sanitize sur inbound n’a rien à redacter (aucun argument n’existe encore), donc il escalade en un block. Rédigez les règles inbound comme des allow / deny explicites, et réservez sanitize pour les stages d’exécution.
Un appel refusé ici renvoie HTTP 400 avec le code firewall_blocked, nommé d’après l’outil et la raison, et marqué skip-retry.

​
3. response — les appels d’outils que le modèle émet

Une fois que le modèle a répondu, il peut émettre un ou plusieurs tool_calls — des invocations concrètes avec des arguments réels. Le stage response les voit, donc c’est là que les règles au niveau des arguments ont leur place : non pas « bloquer shell.exec » mais « bloquer shell.exec uniquement quand la commande est rm -rf ». 
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
Parce que les arguments choisis par le modèle sont présents, sanitize fonctionne ici — il redacte les sous-chaînes correspondantes des arguments de l’appel et transmet l’appel nettoyé. (Sanitize redacte les arguments de l’appel d’outil seulement ; il ne touche jamais au contenu qu’un outil renvoie.)

​
4. mcp — les appels dispatchés à travers la passerelle

Lorsqu’un agent atteint un outil via la passerelle MCP d’OrcaRouter, chaque tools/call est évalué sur le stage mcp avant d’être dispatché vers le serveur enregistré. C’est la surface qui gouverne le trafic Model Context Protocol — le même vocabulaire glob / argument / verdict que response, appliqué au dispatch MCP. Un block ici apparaît comme une erreur d’outil (firewall deny: <reason>) plutôt qu’une défaillance de transport, de sorte que le modèle voit le rejet et peut réagir — choisir un autre outil, demander à l’utilisateur, ou s’arrêter.
Le stage mcp s’associe à la gouvernance par serveur : chaque serveur MCP enregistré a sa propre sonde de santé et des identifiants chiffrés, et les skills chargés à travers lui portent une bande de risque et un mode d’application. Voir Firewall MCP et Firewall skills.

​
5. egress — la destination sortante qu’un outil atteint

La dernière surface. Lorsqu’un outil rapporte une destination réseau sortante, le stage egress correspond dessus — la surface de SSRF et d’exfiltration de données. Les règles d’egress ne correspondent pas sur un motif de nom d’outil seul ; elles correspondent sur une liste host / IP / CIDR : 
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\"],\"allow\":[\"api.openai.com\"]}"
}
Les entrées correspondent comme un CIDR, un littéral d’IP ou un nom d’hôte insensible à la casse. Vous rédigez vous-même les règles de refus de host et de CIDR — l’endpoint cloud-metadata (169.254.169.254) et les plages RFC-1918 sont les choses canoniques à refuser. Voir Règles du Firewall §6 pour la polarité allow/deny.
Aucun preset n’embarque de règles CIDR. La posture SSRF du niveau d’autonomie tight refuse les noms d’outils de forme fetch (par ex. http_fetch, web_search, fetch_url) ; un refus d’egress basé sur la destination est quelque chose que vous rédigez pour les hôtes et les plages que vos agents ne doivent jamais atteindre.

​
6. Choisir le bon stage

Un même objectif de sécurité a souvent un meilleur stage. Faites correspondre l’intention à la surface qui porte réellement les données dont vous avez besoin :
Si le modèle ne devrait même jamais voir un outil, refusez-le sur inbound. Le block atterrit avant l’appel au modèle, donc il ne coûte aucun token de modèle.
Les clauses d’arguments ont besoin des arguments choisis par le modèle, qui n’existent que sur response et mcp. Refusez sur un argument dangereux, ou sanitize pour retirer une valeur de secret ou de PII que l’agent a mise dans un argument.
Les appels routés à travers la passerelle MCP sont évalués sur mcp avant dispatch — le point d’étranglement pour les outils de chaque serveur enregistré.
Les règles basées sur la destination — bloquer l’IP cloud-metadata, refuser un CIDR, mettre en allowlist vos hôtes approuvés — n’ont de sens que sur egress.
Une règle sans stage s’exécute sur les quatre. Utilisez-la pour une règle générale de style default_verdict, ou un outil que vous refusez partout où il apparaît.

​
7. Stages et mode shadow

Le flag shadow_mode d’une politique est indépendant du stage. Activez-le et chaque verdict appliquant — sur n’importe quel stage — est rétrogradé en audit et la raison est préfixée [shadow] would …, de sorte que vous pouvez confirmer qu’une règle se déclenche sur la bonne surface avant qu’elle ne change le trafic réel. Voir Mode shadow et Modes d’application.

​
8. Où les stages s’insèrent dans la vue d’ensemble

Les quatre stages sont le où de l’application ; le reste du modèle est le quoi et le qui.

Verdicts

Ce que chaque stage peut faire une fois qu’il correspond — allow, audit, deny, sanitize, mise en attente d’approbation, plafonnement du coût.

Liste blanche d'outils

Utilisez inbound pour contraindre l’ensemble d’outils qu’un agent annonce.

Valider les arguments

Rédigez des clauses d’arguments response / mcp qui filtrent un outil par la façon dont il est appelé.

Contrôle d'egress

Bloquez les destinations sortantes sur la surface egress — la frontière d’exfiltration.
Pour la façon dont ces surfaces se placent sur le chemin d’inspection, voir Comment OrcaRouter inspecte et les notes sur la latence du chemin d’application. Pour les menaces que chaque stage traite, voir Appels d’outils dangereux, Exfiltration de données, et Empoisonnement d’outils MCP.