Passer au contenu principal
Un agent qui parle le Model Context Protocol (MCP) n’est aussi sûr que les serveurs auxquels il se connecte. Chaque serveur MCP est un nouvel ensemble d’outils, un nouveau credential, et une nouvelle portée réseau — et dès qu’un agent en compose un directement, personne ne surveille l’appel. C’est tout le problème que la sécurité mcp doit résoudre : non pas « cet outil-ci est-il sûr » mais « qui gouverne tous les outils, sur chaque appel, avec une seule piste d’audit ». La réponse d’OrcaRouter est un unique point d’étranglement audité. Vous enregistrez chaque serveur MCP une fois ; les agents se connectent à une seule passerelle ; et chaque tools/call passe par le moteur de firewall avant d’atteindre le vrai serveur. Cette page est la carte de cette surface — la passerelle, le verdict par appel, la gouvernance des skills, l’egress, et les credentials chiffrés — avec des liens vers le guide ciblé pour chacun.
Chaque action de gestion ici se configure depuis la console (ou l’API REST avec votre token de session/d’accès) et est soumise à des rôles. Seuls les appels relais /v1/* et les routes de la passerelle firewall portent une clé de style sk-orca-....

​
1. Pourquoi la sécurité mcp a besoin d’une passerelle

Pointez dix agents directement sur cinq serveurs MCP communautaires et vous obtenez le pire de tous les mondes : aucune politique partagée, aucune piste d’audit, des credentials copiés dans dix configs d’agents, et un outil nommé shell.exec à une redirection de votre endpoint de métadonnées cloud. La passerelle réduit tout cela à une seule connexion gouvernée.

Une connexion, chaque serveur

Les agents se connectent à un seul endpoint. La passerelle agrège les outils de chaque serveur activé et joignable sous un namespace <server>.<tool>.

Une politique sur chaque appel

Chaque tools/call est évalué par votre politique firewall avant le dispatch.

Credentials chiffrés

Les secrets d’authentification des serveurs sont chiffrés au repos, masqués en lecture, et injectés au dispatch — ils n’atteignent jamais le modèle ni le client.

Egress sous contrôle

L’endpoint d’un serveur enregistré est validé par défaut contre les plages d’IP privées et de métadonnées cloud. Pour les destinations par outil, appliquez la denylist d’egress SSRF du référentiel ou rédigez vos propres règles host/CIDR.
Pour les fondations derrière tout cela, voir Sécuriser les agents IA et Pourquoi le zero trust.

​
2. Les quatre briques de base

La gouvernance MCP sur OrcaRouter est constituée de quatre pièces coopérantes. Choisissez celle qui correspond à la question à laquelle vous essayez de répondre.
Un seul endpoint auquel vos agents se connectent au lieu de composer les serveurs directement. Elle agrège les outils de chaque serveur enregistré, sous le namespace <server>.<tool>, et ré-expose le schéma d’entrée de chaque outil verbatim. Commencez à Connecter un serveur MCP et S’authentifier ; la référence complète se trouve dans Firewall : serveurs MCP.
La passerelle fait passer chaque tools/call à travers le firewall sur la surface mcp et renvoie un verdict — allow, audit, deny, sanitize, ou pending_approval — avant le dispatch. Voir Lister les outils MCP autorisés et Assainir les arguments d’outils.
Les capacités qu’un agent auto-installe — skills, serveurs MCP BYO, plugins — sont scannées, classées dans une bande de risque, et dotées d’un mode d’application (allow / quarantine / block) qui se superpose à chaque verdict de règle. Voir Firewall : skills et Défense contre le rug pull.
Le secret d’authentification de chaque serveur est chiffré au repos et masqué en lecture. Voir S’authentifier et Rotation des credentials.

​
3. Comment un tools/call est évalué

Quand un agent appelle un outil à travers la passerelle, l’appel ne va pas directement au serveur. Il est confronté à la politique de votre espace de travail, le mode d’application du skill propriétaire est appliqué par-dessus, et seul un verdict allow / audit / sanitize atteint le vrai serveur.
VerdictCe que voit l’agent
allow / auditTransmis. audit journalise aussi un événement.
sanitizeTransmis avec les arguments redactés (jamais le résultat).
deny / pending_approvalRenvoyé comme une erreur d’outil, de sorte que l’agent peut s’adapter au lieu de planter.
Un appel MCP bloqué revient comme une erreur d’outil (firewall deny: …), la même forme que renvoie n’importe quel outil défaillant — l’agent peut réessayer différemment, demander à l’utilisateur, ou s’arrêter. Ce n’est pas un crash de transport.
Le vocabulaire des verdicts, les surfaces et la correspondance des règles sont documentés en intégralité sous Firewall et Règles du firewall ; le modèle conceptuel se trouve dans Modes d’application et Comment OrcaRouter inspecte.

​
4. Enregistrer un serveur (un exemple concret)

Vous enregistrez chaque serveur une fois. Un enregistrement de serveur porte un name (unique par espace de travail, pas de .), un endpoint, un auth_mode (none / bearer / oauth / basic), et ses credentials chiffrés. Faites-le depuis la console — l’écriture requiert Developer+. 
# Route console, appelée avec votre token de session/d'accès (UserAuth).
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-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
  }'
Ensuite sondez-le pour découvrir ses outils et enregistrer la joignabilité (ok / degraded / down) : 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Maintenant vous pouvez rédiger des règles contre github.* en sachant exactement ce que github.create_issue accepte. Le pas-à-pas de bout en bout se trouve dans Connecter un serveur MCP.
Les secrets ne sont jamais stockés en clair. auth_json est chiffré au repos et masqué en lecture ; sur une mise à jour, renvoyez le masque tel quel pour conserver la valeur stockée. Voir Rotation des credentials.

​
5. Connecter un agent à la passerelle

Une fois les serveurs enregistrés, pointez n’importe quel client MCP vers la passerelle avec une clé scopée à la passerelle firewall (un token sans cette portée reçoit un 403) : 
https://api.orcarouter.ai/api/v1/firewall/mcp
La passerelle parle le HTTP streamable et annonce les outils de chaque serveur activé et joignable sous le namespace <server>.<tool>. Un SDK qui relaie les appels lui-même peut lire le registre d’exécution depuis GET /api/v1/firewall/mcp_servers avec le même token de passerelle.

​
6. Verrouiller ce que les outils peuvent atteindre

Les verdicts par appel gouvernent quel outil s’exécute ; les contrôles d’egress gouvernent où il peut atteindre. Deux couches coopèrent. D’abord, quand la passerelle se connecte à l’endpoint d’un serveur enregistré, cette URL est validée par défaut contre les plages privées (RFC1918), loopback, link-local et de métadonnées cloud — et l’hôte est résolu par DNS de sorte qu’un nom qui se résout dans une plage bloquée est refusé lui aussi. Donc un serveur BYO pointé vers 169.254.169.254 ou une adresse intranet est rejeté à moins de l’avoir explicitement mis en liste blanche. Ensuite, pour les destinations par outil, une règle d’egress porte une liste allow/deny host/CIDR confrontée à la destination sortante de l’appel sur la surface egress. Le modèle de cas d’usage du référentiel livre une règle de refus d’egress prête à l’emploi dont la liste couvre déjà les plages privées, loopback, link-local et de métadonnées cloud (y compris 169.254.169.254 et metadata.google.internal), de sorte que l’appliquer vous donne une défense SSRF/métadonnées sans rédiger de CIDR à la main.
Le SSRF et l’egress sont la différence entre « cet outil a renvoyé des données » et « cet outil a exfiltré vos secrets vers l’hôte d’un attaquant ». Appliquez la denylist d’egress du référentiel et ajoutez vos propres règles host/CIDR — voir Limites d’egress et Exfiltration de données.

​
7. Surveillez : événements, runs et anomalies

Chaque appel gouverné laisse une trace. Les événements firewall enregistrent le verdict, la surface et la règle correspondante ; les runs regroupent les appels d’une session ; et le flux d’anomalies signale les pics de débit et de coût contre un référentiel appris. Les lectures des réglages, des politiques et des outils découverts sont ouvertes à tout Member ; les lectures d’événements/runs/agrégats requièrent Developer+.

​
8. Où aller ensuite

Connecter un serveur MCP

Enregistrer, sonder et exposer un serveur à travers la passerelle.

Lister les outils MCP autorisés

Refus par défaut sur un serveur et n’autoriser que les outils que vous avez revus.

Défense contre le rug pull

Gouverner les serveurs et skills qui changent après que vous les avez approuvés.

Firewall : serveurs MCP

La référence complète des champs et des routes.
Nouveau sur le modèle ? Lisez Guardrails vs. firewall pour voir où s’inscrit la gouvernance MCP, puis Empoisonnement d’outils MCP et Agence excessive pour les menaces qu’elle ferme.