Firewall : Serveurs MCP

Le Model Context Protocol (MCP) permet aux agents d’appeler des outils hébergés par des serveurs externes. C’est puissant et dangereux à parts égales : chaque serveur MCP auquel un agent se connecte est un nouvel ensemble d’outils, de credentials et de portée réseau que personne n’a passé en revue. La passerelle MCP du Firewall place un unique point d’étranglement audité devant tous. Vous enregistrez chaque serveur MCP une fois ; la passerelle expose leurs outils à vos agents sous une seule connexion et fait passer chaque tools/call à travers le moteur de firewall avant qu’il n’atteigne le vrai serveur.

1. Ce que la gouvernance MCP vous apporte

Une passerelle, chaque serveur. Votre agent se connecte à un seul endpoint. La passerelle agrège les outils de chaque serveur enregistré joignable, sous le namespace <server>.<tool>, de sorte que github.create_issue et shell.exec apparaissent côte à côte sous une seule connexion MCP.
Une politique sur chaque appel. Chaque tools/call est d’abord évalué par votre politique. Un appel bloqué revient au modèle comme une erreur d’outil (firewall deny: …), pas comme une défaillance de transport, de sorte que l’agent peut réagir au lieu de planter. sanitize réécrit les arguments avant transmission ; pending_approval met l’appel en attente.
Protégé contre le SSRF. Les endpoints distants sont validés contre la politique SSRF de la passerelle — les plages intranet et les adresses de métadonnées cloud sont bloquées, et l’IP de connexion résolue est re-vérifiée pour déjouer le DNS rebinding, à chaque saut y compris les redirections.
Credentials chiffrés. Les secrets d’authentification des serveurs sont chiffrés au repos et masqués en lecture. La passerelle les injecte au moment du dispatch ; ils n’atteignent jamais le modèle ni le client.

2. Deux types de serveur

Type	`endpoint`	Comportement
BYO (bring-your-own)	Une URL streamable-HTTP	La passerelle relaie les `tools/call` vers votre serveur MCP distant.
Intégré	vide	Le serveur MCP in-process d’OrcaRouter. Enregistré pour qu’il soit visible et gouvernable ; pas sondable séparément.

3. Enregistrer un serveur

Un enregistrement de serveur porte :

Champ	Notes
`name`	Clé métier, unique par espace de travail, ≤ 128 caractères. Pas de `.` — c’est le séparateur de namespace `<server>.<tool>`.
`endpoint`	L’URL du serveur MCP (≤ 512 caractères). Vide pour le serveur intégré.
`auth_mode`	`none` (défaut), `bearer`, `oauth`, ou `basic`.
`auth_json`	Credentials spécifiques au mode (voir ci-dessous). Requis dès que `auth_mode` n’est pas `none`.
`enabled`	Vaut `true` par défaut. Un serveur désactivé est entièrement omis de la passerelle.
`status`	Joignabilité — `ok` (défaut), `degraded`, ou `down`. Défini par le sondage.

Formes des credentials par mode :

// bearer
{ "token": "ghp_…" }
// oauth
{ "client_id": "…", "client_secret": "…", "token_url": "…" }
// basic
{ "username": "…", "password": "…" }
// none
""

Une requête d’enregistrement ressemble à :

curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'

Un nom dupliqué dans le même espace de travail renvoie une HTTP 409 (le même nom dans un espace de travail différent est acceptable).

Les secrets ne sont jamais stockés en clair. auth_json est chiffré au repos avec une clé de secrets d’espace de travail. Si cette clé n’est pas configurée, l’écriture est rejetée plutôt que de persister un credential non chiffré. En lecture, les secrets et l’endpoint sont masqués ; renvoyez le masque tel quel sur une mise à jour pour conserver la valeur stockée. Passer d’un mode d’auth credentialé à un autre nécessite un nouveau auth_json (le chiffré est lié à la forme de son mode).

4. Probe — découvrir ses outils

Avant de pouvoir écrire des règles contre les outils d’un serveur, vous devez connaître leurs noms. Sondez le serveur :

curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer sk-orca-..."

La passerelle exécute un initialize MCP + tools/list contre l’endpoint (en utilisant les credentials déchiffrés, borné à 10s), enregistre le status de joignabilité et un horodatage, et renvoie les outils annoncés avec leurs schémas d’entrée :

{
  "status": "ok",
  "last_checked_at": 1700000000,
  "tools": [
    { "name": "create_issue", "description": "…", "input_schema": { } }
  ]
}

Maintenant vous pouvez rédiger des règles comme tool_name_glob: github.* en sachant exactement ce que github.create_issue accepte. Le serveur intégré (endpoint vide) n’est pas sondable et renvoie un 400.

5. Cycle de vie & application

Activé vs. désactivé. Un serveur désactivé est retiré du registre d’exécution — ses outils disparaissent de la passerelle et ses credentials ne sont jamais déchiffrés. C’est l’interrupteur d’arrêt.
Joignabilité. status (ok / degraded / down) reflète le dernier sondage ; un serveur injoignable est ignoré lorsque la passerelle construit son ensemble d’outils.
Verdict par appel. Au dispatch, le moteur renvoie un verdict pour l’appel <server>.<tool> spécifique avec ses arguments :
- allow / audit → transmis (audit journalise, autorise quand même).
- sanitize → transmis avec des arguments réécrits.
- deny / pending_approval / tout inconnu → bloqué comme une erreur d’outil. (À travers la passerelle unifiée, un appel mis en attente apparaît comme une erreur permanente plutôt que de faire transiter l’id d’approbation — utilisez le hook d’évaluation lorsque vous avez besoin du handshake d’approbation.)
La suppression est une suppression douce ; le créneau de nom est libéré immédiatement afin que vous puissiez ré-enregistrer sous le même nom.

Chaque changement invalide immédiatement le cache d’outils par espace de travail de la passerelle, de sorte qu’un serveur nouvellement enregistré, désactivé ou re-sondé prend effet à la prochaine connexion plutôt qu’après un TTL de cache.

6. Connecter un client

Pointez n’importe quel client MCP vers l’endpoint de la passerelle avec un token scopé à la passerelle firewall :

https://api.orcarouter.ai/api/v1/firewall/mcp

La passerelle parle le HTTP streamable (messages POST, GET pour le flux SSE, DELETE pour terminer une session) et s’identifie comme orcarouter-firewall-gateway. Elle annonce les outils de chaque serveur activé et joignable sous le namespace <server>.<tool>, en ré-exposant le schéma d’entrée de chaque outil verbatim. Un token sans la portée de passerelle firewall reçoit un 403 — frappez un token de passerelle dédié pour cela.

Référence API

Console (à portée d’espace de travail, RBAC)

Méthode & chemin	Rôle	Objectif
`GET /api/workspace/firewall/mcp_servers`	Member	Lister les serveurs (secrets masqués, endpoint redacté).
`GET /api/workspace/firewall/mcp_servers/:id`	Member	Un seul serveur, masqué.
`POST /api/workspace/firewall/mcp_servers`	Developer+	Enregistrer un serveur (409 sur nom dupliqué).
`PUT /api/workspace/firewall/mcp_servers`	Developer+	Mettre à jour un serveur (id dans le corps).
`DELETE /api/workspace/firewall/mcp_servers/:id`	Developer+	Suppression douce ; libère le nom.
`POST /api/workspace/firewall/mcp_servers/:id/probe`	Developer+	Sonder la joignabilité + découvrir les outils.

Passerelle (token scopé à la passerelle firewall)

Méthode & chemin	Objectif
`ANY /api/v1/firewall/mcp`	L’endpoint de dispatch unifié de la passerelle MCP.
`GET /api/v1/firewall/mcp_servers`	Registre d’exécution (auth déchiffrée, serveurs activés uniquement) pour un proxy SDK.
`POST /api/v1/firewall/evaluate`	Évaluer un seul `tools/call` avant de le dispatcher vous-même.

FAQ

Pourquoi router MCP à travers OrcaRouter ?

Pour qu’il y ait un seul endroit qui voit chaque appel d’outil. Sans passerelle, chaque agent se connecte directement à chaque serveur MCP — aucune politique partagée, aucune piste d’audit, aucune protection SSRF, et des credentials éparpillés dans les configs d’agents. La passerelle centralise tout cela : une connexion, une politique, un journal audité, des secrets chiffrés injectés au dispatch.

Que se passe-t-il quand un appel MCP bloqué revient ?

Le modèle le reçoit comme une erreur d’outil (firewall deny: <reason>), la même forme qu’il obtiendrait de n’importe quel outil défaillant. Cela permet à l’agent de s’adapter — essayer une autre approche, demander à l’utilisateur, ou s’arrêter — au lieu de le traiter comme un crash de transport.

Puis-je gouverner le même outil différemment selon le serveur ?

Oui — c’est à cela que sert le namespace <server>.<tool>. Une règle avec tool_name_glob: trusted.* peut allow tandis que community.* est audité ou en pending_approval. Combinez-la avec un glob de nom de skill pour une portée encore plus fine.

La passerelle protège-t-elle contre le SSRF ?

Oui. Les URL d’endpoint et leurs IP de connexion résolues sont validées contre la politique SSRF à l’enregistrement et à chaque saut de dispatch — les plages intranet et l’adresse de métadonnées cloud sont refusées, et l’IP résolue est re-vérifiée pour déjouer le DNS rebinding. Associez-la à une règle d’egress pour gouverner où les outils peuvent atteindre.

Voir aussi

Vous souhaitez approfondir la sécurité des agents ? Les guides Sécurisez vos agents (Zero Trust) replacent cette fonctionnalité dans un workflow zero-trust.

Sécuriser les serveurs MCP (Zero Trust)

Connectez, authentifiez et gouvernez les serveurs MCP dans une posture zero-trust.

Liste de contrôle de confiance MCP

Ce qu’il faut vérifier avant d’accorder votre confiance à un serveur MCP tiers.

​1. Ce que la gouvernance MCP vous apporte

​2. Deux types de serveur

​3. Enregistrer un serveur

​4. Probe — découvrir ses outils

​5. Cycle de vie & application

​6. Connecter un client

​Référence API

​Console (à portée d’espace de travail, RBAC)

​Passerelle (token scopé à la passerelle firewall)

​FAQ

​Voir aussi