Passer au contenu principal
Vous voulez que vos agents utilisent un serveur Model Context Protocol (MCP) — votre propre serveur distant, ou celui intégré — mais vous voulez que chaque appel d’outil qu’il expose s’exécute derrière un unique point d’étranglement audité. La première étape est d’enregistrer le serveur dans votre espace de travail : un nom, un endpoint, un mode d’auth, et ses credentials. Une fois enregistré, la passerelle MCP annonce ses outils sous une seule connexion et évalue chaque tools/call à travers votre politique firewall avant qu’il n’atteigne le vrai serveur. Cette page couvre cette unique tâche — connecter et configurer un enregistrement de serveur. Pour le comportement d’exécution de la passerelle et les verdicts par appel, voir la référence MCP ; pour la vue d’ensemble, commencez à l’aperçu de la sécurité MCP.
L’enregistrement est une action console (les routes /api/workspace/firewall/* s’authentifient avec votre token de session / d’accès, pas une clé relais sk-orca-…). Les écritures requièrent le rôle Developer+ ; tout membre peut lister les serveurs.

​
1. Comment connecter un serveur MCP

Ouvrez Firewall → MCP Servers dans la console et ajoutez un serveur, ou appelez directement l’API d’espace de travail. Un enregistrement porte quatre choses qui comptent :

name

Unique par espace de travail. Il devient le préfixe de namespace <server>.<tool>, donc un nom dupliqué dans le même espace de travail est rejeté avec HTTP 409.

endpoint

L’URL de votre serveur MCP distant. Laissez-le vide pour enregistrer le serveur in-process intégré afin qu’il soit visible et gouvernable.

auth_mode

Comment la passerelle s’authentifie auprès de votre serveur : none, bearer, oauth, ou basic.

credentials

Le secret spécifique au mode. Stocké chiffré au repos et masqué en lecture — il n’atteint jamais le modèle ni le client.
Un serveur démarre enabled et est entièrement retiré de la passerelle dès que vous le désactivez — c’est l’interrupteur d’arrêt, et les credentials d’un serveur désactivé ne sont jamais déchiffrés.

​
2. Un exemple concret

Enregistrez un serveur MCP GitHub distant avec un bearer token. Ceci est un appel REST équivalent à la console ; les noms de champs sont exactement ce que le formulaire écrit. 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-or-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'
La forme du credential dépend de auth_mode :
{"token":"…"} — envoyé comme bearer token à votre serveur.
{"access_token":"…"} — un access token statique que la passerelle envoie comme en-tête bearer. L’échange automatique de client-credentials n’est pas encore pris en charge ; sans access_token stocké, un sondage en mode oauth échoue plutôt que de se connecter non authentifié.
{"username":"…","password":"…"}.
Une chaîne vide. Aucun credential n’est attaché.
En lecture, le credential et l’endpoint sont tous deux masqués — l’API renvoie des placeholders sentinelles, pas les valeurs brutes. Lorsque vous mettez à jour un serveur, renvoyez ces placeholders inchangés pour conserver les valeurs stockées ; envoyez un nouveau auth_json seulement quand vous faites réellement la rotation du secret. Voir rotation des credentials.

​
3. Sonder sa santé

Avant de pouvoir rédiger des règles firewall contre les outils d’un serveur, vous devez savoir qu’ils sont joignables et comment ils s’appellent. Sondez le serveur — la passerelle exécute un handshake MCP initialize + tools/list en utilisant les credentials déchiffrés, enregistre la joignabilité et renvoie les outils annoncés : 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-or-access-token>"

{
  "status": "ok",
  "last_checked_at": 1700000000,
  "tools": [
    { "name": "create_issue", "description": "…", "input_schema": {} }
  ]
}
Le status atterrit dans l’enregistrement du serveur et pilote l’indicateur de santé :
statusSignification
okJoignable ; les outils sont servis par la passerelle.
degradedJoignable, mais le handshake était partiel.
downInjoignable au dernier sondage ; le serveur est ignoré.
Un serveur down est laissé de côté lorsque la passerelle construit son ensemble d’outils, de sorte qu’une panne transitoire se dégrade gracieusement au lieu de casser le dispatch. Un sondage renvoie son résultat quel que soit le résultat — un sondage échoué revient en 200 avec status: down et une raison nettoyée, pas une erreur de transport.
Le serveur in-process intégré (endpoint vide) dispatche localement et n’est pas sondable — le sonder est rejeté avec une erreur expliquant que l’enregistrement n’a pas d’endpoint. Vous ne sondez que les serveurs BYO qui ont une URL.
Chaque changement d’enregistrement invalide immédiatement le cache d’outils par espace de travail de la passerelle, de sorte qu’un serveur nouvellement connecté, désactivé ou re-sondé prend effet à la prochaine connexion plutôt qu’après une fenêtre de cache.

​
4. Une fois connecté

Une fois un serveur enregistré et sondant ok, ses outils sont gouvernés :
  • Chaque appel est évalué. Chaque tools/call passe par votre politique firewall sur la surface mcp avant d’atteindre votre serveur. Cadrez les règles avec tool_name_glob: github.* maintenant que vous connaissez les noms d’outils.
  • Verrouillez la surface. Refusez par défaut les outils que vous n’avez pas explicitement autorisés — voir lister les outils MCP autorisés.
  • Gouvernez où il atteint. Rédigez une règle d’egress pour qu’un outil ne puisse pas récupérer des hôtes arbitraires.
  • Surveillez les changements. Un serveur en qui vous aviez confiance peut changer ses définitions d’outils après coup ; la défense contre le rug pull signale cette dérive.

​
5. Référence API

Toutes les routes console sont à portée d’espace de travail et s’authentifient avec votre token de session / d’accès. Les lectures de listes sont ouvertes à tout Member (secrets masqués) ; chaque écriture requiert Developer+.
Méthode & cheminRôleObjectif
GET /api/workspace/firewall/mcp_serversMemberLister les serveurs (secrets + endpoint masqués).
GET /api/workspace/firewall/mcp_servers/:idMemberUn seul serveur, masqué.
POST /api/workspace/firewall/mcp_serversDeveloper+Enregistrer un serveur (409 sur nom dupliqué).
PUT /api/workspace/firewall/mcp_serversDeveloper+Mettre à jour un serveur (id dans le corps).
DELETE /api/workspace/firewall/mcp_servers/:idDeveloper+Suppression douce ; libère le nom.
POST /api/workspace/firewall/mcp_servers/:id/probeDeveloper+Sonder la joignabilité + découvrir les outils.
Le proxy SDK d’un agent lit le registre d’exécution via le token scopé à la passerelle à GET /api/v1/firewall/mcp_servers (serveurs activés uniquement). Pour savoir comment authentifier ce côté, voir authentifier la passerelle MCP.
Pourquoi se connecter à travers OrcaRouter ? Pour qu’un seul endroit voie chaque appel d’outil — une connexion, une politique, un journal audité, et des credentials injectés au dispatch au lieu d’être éparpillés dans les configs d’agents. Lisez sécuriser les agents IA et la menace d’empoisonnement d’outils MCP pour la motivation.

​
Connexe

Aperçu de la sécurité MCP

Le modèle complet de gouvernance MCP, de bout en bout.

Firewall : serveurs MCP

Le comportement d’exécution de la passerelle et les verdicts par appel.

Authentifier la passerelle

Émettre et cadrer le token avec lequel votre agent se connecte.

Checklist de confiance

Tout à vérifier avant de faire confiance à un nouveau serveur.