Limites d'egress pour les serveurs MCP

Un serveur MCP que vous connectez livre des outils qui atteignent le réseau — un fetch, un web_search, un posteur de webhook. Le nom de l’outil peut être sur votre liste d’autorisation, les arguments peuvent paraître propres, et l’appel finit quand même par poster vos données vers un hôte contrôlé par un attaquant ou par tirer des credentials de l’endpoint de métadonnées 169.254.169.254. La destination est la partie de l’appel que vos règles de nom d’outil ne voient jamais. Le contrôle d’egress mcp ferme cette lacune. Une règle d’egress cadre un verdict firewall sur l’endroit qu’un outil atteint — un hôte, une IP, ou une plage CIDR — de sorte que le même http_fetch qui est autorisé à api.openai.com est refusé à tout le reste. Elle s’exécute sur la surface egress du firewall, par-dessus l’évaluation par appel par laquelle chaque tools/call passe déjà.

Ceci est une tâche console. Les règles firewall vivent sur les routes /api/workspace/firewall/*, qui s’authentifient avec votre token de session / d’accès — pas une clé relais sk-orca-…. Rédiger une règle requiert le rôle Developer+.

1. Ce qu’une règle d’egress contrôle

Une règle normale fait correspondre sur le nom de l’outil et ses arguments. Une règle d’egress ajoute une troisième dimension : la destination vers laquelle l’appel se résout. Vous réglez le stage de la règle sur egress et attachez une liste egress_json d’entrées allow / deny. Le moteur extrait l’hôte de destination de l’appel et ne déclenche la règle que quand cet hôte est dans la portée. Les entrées sont mises en correspondance de trois façons :

Nom d'hôte

Correspondance exacte insensible à la casse, p. ex. api.openai.com. Un point final est rogné des deux côtés.

Littéral IP

Correspondance exacte contre l’IP de connexion résolue, p. ex. 169.254.169.254.

Plage CIDR

L’IP de destination — littérale ou résolue par DNS — doit tomber à l’intérieur du bloc, p. ex. 10.0.0.0/8.

Quand une destination est un nom d’hôte mais que votre liste porte des entrées IP/CIDR, le nom est résolu et ses IP sont re-vérifiées — de sorte que metadata.internal correspond à un deny 169.254.0.0/16 même s’il n’est pas listé par nom. C’est une défense-en-profondeur best-effort contre un nom qui se résout dans une plage refusée ; le garde SSRF faisant autorité s’exécute encore à la couche de connexion de la passerelle.

2. Un exemple concret

Refusez à chaque outil de forme fetch d’atteindre l’endpoint de métadonnées cloud et les plages RFC-1918. C’est la coupe canonique de la jambe d’exfil SSRF : un verdict deny sur le stage egress, cadré par une denylist egress_json.

curl https://api.orcarouter.ai/api/workspace/firewall/rules \
  -H "Authorization: Bearer <your-session-or-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "policy_id": 12,
    "priority": 10,
    "label": "Deny SSRF / metadata egress",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny",
    "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"]}"
  }'

Un tools/call dont la destination se résout dans l’une de ces plages revient au modèle comme une erreur d’outil ; un appel vers un hôte public que la denylist ne couvre pas passe.

Les listes allow/deny inversent leur signification avec le verdict. Sur une règle deny (ou autre enforcing), la liste deny est l’ensemble en portée et allow taille des exemptions — « refuser ceux-ci, sauf ceux-là ». Sur une règle allow les rôles s’inversent : la liste allow est l’ensemble en portée et deny taille des exemptions — « n’autoriser que ceux-ci ». Un egress_json non vide doit déclarer au moins une entrée allow ou deny, sinon l’écriture est rejetée.

3. N’autoriser qu’une seule destination

L’inverse de l’exemple ci-dessus : épinglez un outil fetch à un unique hôte sanctionné et laissez le default_verdict de la politique (ou un catch-all ultérieur) gérer le reste. Parce que c’est un verdict allow, la liste allow est l’ensemble en portée.

// egress_json sur une règle verdict-allow, stage=egress
{ "allow": ["api.openai.com", "api.anthropic.com"] }

La règle ne se déclenche (autorise) maintenant que lorsque la destination est l’un de ces deux hôtes. Tout le reste retombe sur la règle suivante — associez-la à une politique de refus par défaut pour qu’une destination non listée soit refusée plutôt que laissée passer.

Testez-la avant de lui faire confiance. L’onglet Test de la console et l’endpoint POST /api/workspace/firewall/test (Developer+) rejouent un appel d’exemple contre votre politique brouillon afin que vous puissiez confirmer le verdict sur une destination connue sans envoyer de trafic en direct.

4. Comment elle se compose avec le reste du firewall

Une règle d’egress est une règle parmi tant d’autres dans une politique firewall d’espace de travail. Le moteur parcourt les règles par ordre de priorité (la plus basse d’abord) et la première correspondance gagne, donc placez un deny d’egress serré au-dessus de tout allow large.

Verdict sur une règle d’egress	Effet
`deny`	Bloque l’appel vers les destinations en portée — enregistré sur la surface `egress` et renvoyé à l’outil comme une erreur.
`audit`	Journalise l’appel correspondant comme un événement firewall ; se dispatche quand même.
`allow`	Permet les destinations en portée ; s’associe à un plancher de refus par défaut.

pending_approval et cap_cost ne sont pas appliqués sur la surface egress — l’egress est une vérification de destination, pas une attente ni un plafond de dépense. Utilisez ces verdicts sur les surfaces mcp ou inbound à la place. Voir la référence des verdicts.

Deux contrôles connexes valent la peine d’être câblés aux côtés d’une règle d’egress :

Garde SSRF intégré (aucune règle requise)

Indépendamment de toute règle que vous rédigez, la passerelle MCP valide chaque endpoint de serveur et son IP de connexion résolue contre une politique SSRF — les plages intranet et l’adresse de métadonnées cloud sont refusées, et l’IP est re-vérifiée à chaque saut pour déjouer le DNS rebinding. Votre règle d’egress superpose une politique de destination spécifique à l’espace de travail par-dessus ce référentiel.

Règles de séquence pour la chaîne d'exfil

Un seul deny d’egress empêche un outil d’atteindre un hôte. Une règle de séquence arrête la chaîne — p. ex. « lire un fichier, puis egress dans la fenêtre » — en signalant la jambe d’egress seulement quand elle suit une lecture sensible. C’est le briseur de la trifecta létale ; le cadrage d’egress est le contrôle par appel.

5. Mettez-la en shadow d’abord, puis appliquez

Rouler un deny d’egress directement en application sur un espace de travail chargé risque de casser une intégration légitime que vous avez oubliée. Deux filets de sécurité :

Mode shadow. Une politique en mode shadow rétrograde chaque verdict enforcing en audit — votre deny d’egress journalise [shadow] would deny … au lieu de bloquer, de sorte que vous voyez le rayon d’impact avant qu’il ne morde.
Mode observe. Le réglage d’espace de travail firewall_observe_mode journalise les appels non couverts comme Outils Découverts, faisant remonter les destinations réelles que vos agents atteignent déjà afin que vous puissiez écrire une liste d’autorisation précise à partir de données plutôt que de conjectures.

La correspondance de destination d’egress se cale sur l’hôte vers lequel l’appel se résout au moment de l’évaluation. Un serveur hostile peut encore rebinder le DNS entre la vérification de politique et la connexion réelle (TOCTOU) — c’est exactement pourquoi le garde IP de la couche socket de la passerelle est le contrôle faisant autorité et que cette règle est défense-en-profondeur, pas la seule ligne.

6. Rôles et routes

Toutes les routes console sont à portée d’espace de travail et s’authentifient avec votre token de session / d’accès. Les lectures sont ouvertes à tout Member ; rédiger ou éditer une règle requiert Developer+.

Méthode & chemin	Rôle	Objectif
`GET /api/workspace/firewall/policies/:id`	Member	Lire une politique et ses règles.
`POST /api/workspace/firewall/rules`	Developer+	Ajouter une règle (régler `stage: egress`).
`PUT /api/workspace/firewall/rules`	Developer+	Mettre à jour une règle (id dans le corps).
`DELETE /api/workspace/firewall/rules/:id`	Developer+	Supprimer une règle.
`POST /api/workspace/firewall/test`	Developer+	Rejouer un appel d’exemple contre une politique brouillon.

Connexe

Référence des règles du firewall

Le DSL de règle complet — globs d’outils, correspondance d’args, listes d’egress, séquences.

Connecter un serveur MCP

Enregistrer un serveur pour que ses appels d’outils s’exécutent derrière le firewall.

Lister les outils MCP autorisés

Refus par défaut des outils que vous n’avez pas explicitement approuvés.

Exfiltration de données

La menace que le contrôle d’egress est conçu pour stopper.

​1. Ce qu’une règle d’egress contrôle

Nom d'hôte

Littéral IP

Plage CIDR

​2. Un exemple concret

​3. N’autoriser qu’une seule destination

​4. Comment elle se compose avec le reste du firewall

​5. Mettez-la en shadow d’abord, puis appliquez

​6. Rôles et routes

​Connexe

Référence des règles du firewall

Connecter un serveur MCP

Lister les outils MCP autorisés

Exfiltration de données

1. Ce qu’une règle d’egress contrôle

2. Un exemple concret

3. N’autoriser qu’une seule destination

4. Comment elle se compose avec le reste du firewall

5. Mettez-la en shadow d’abord, puis appliquez

6. Rôles et routes

Connexe