Passer au contenu principal
Un serveur MCP tiers est un ensemble d’outils non revu, un credential en direct, et une nouvelle portée réseau. Dès qu’un agent en compose un directement, personne ne surveille l’appel — et « le serveur a changé ses outils après que vous l’avez approuvé » est une vraie attaque, pas une hypothèse. Avant de pointer un agent sur un serveur que quelqu’un d’autre opère, vous voulez un pré-vol reproductible. Cette page est ce pré-vol : une checklist courte et ordonnée pour passer en revue un serveur mcp sur OrcaRouter en utilisant des contrôles qui existent déjà — évaluation par appel, liste d’autorisation à refus par défaut, limites d’egress, credentials chiffrés, et quarantaine de skills. Chaque étape renvoie au guide ciblé pour la profondeur. Exécutez-la une fois par nouveau serveur ; ré-exécutez les étapes sensibles à la dérive chaque fois que le serveur change.
Chaque étape de configuration ici se fait depuis la console (ou l’API REST avec votre token de session/d’accès) et est soumise à des rôles. Seules les routes de la passerelle firewall et les appels relais /v1/* portent une clé de style sk-orca-....

​
1. La checklist pour passer en revue les connexions à un serveur mcp

Travaillez de haut en bas. Les trois premières étapes sont obligatoires pour tout serveur que vous n’opérez pas vous-même ; le reste le durcit.

1. Sondez avant de faire confiance

Découvrez la vraie liste d’outils et la joignabilité avant d’écrire une seule règle.

2. Refus par défaut, puis liste d'autorisation

Ne permettez que les outils que vous avez revus ; tout le reste est refusé.

3. Chiffrez le credential

Stockez l’auth de sorte qu’elle soit chiffrée au repos, masquée en lecture, jamais vue par le modèle.

4. Verrouillez l'egress

Contraignez où les outils du serveur peuvent atteindre sur le réseau.

5. Mettez en quarantaine les skills auto-installés

Retenez tout ce que l’agent installe de lui-même jusqu’à ce qu’un humain le revoie.

6. Shadow d'abord, puis surveillez

Déployez en audit-uniquement, puis lisez les événements et les anomalies avant d’appliquer.

​
2. Sondez avant de faire confiance

Vous ne pouvez pas revoir des outils que vous n’avez jamais vus, et la liste d’outils annoncée d’un serveur est la chose la plus susceptible de changer sous vous. Enregistrez le serveur, puis sondez-le — la passerelle exécute un MCP initialize + tools/list contre l’endpoint et renvoie les vrais outils avec leurs schémas d’entrée, plus un status de joignabilité ok, degraded, ou down. 
# Route console, appelée avec votre token de session/d'accès (UserAuth). Developer+.
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Lisez chaque nom d’outil et ce que ses arguments acceptent. Un serveur annonçant un shell.exec ou un http_fetch que vous n’attendiez pas est une constatation, pas un détail — c’est tout l’intérêt de sonder d’abord.
Re-sondez chaque fois qu’un serveur change de mains ou que vous soupçonnez une dérive. Un nouvel outil apparaissant dans la liste — le « rug pull » — est exactement ce que vous surveillez. Voir Défense contre le rug pull.
La référence complète d’enregistrement et de sondage se trouve dans Firewall : serveurs MCP ; le pas-à-pas de bout en bout est Connecter un serveur MCP.

​
3. Refus par défaut, puis liste d’autorisation des outils que vous avez revus

Une liste d’autorisation est la différence entre « le serveur peut faire six choses » et « le serveur peut faire ce que son opérateur décide demain ». Réglez le default_verdict de la politique sur deny, puis ajoutez une règle par outil que vous avez revu et en qui vous avez confiance. Parce que la passerelle met chaque outil en namespace <server>.<tool>, vous pouvez cadrer les règles à un serveur sans toucher aux autres. 
// Politique sur la surface mcp : deny par défaut, n'autoriser que ce que vous avez revu.
// tool_name_glob prend en charge un joker plein-segment : "github.*" (préfixe),
// "*.exec" (suffixe), ou "*.shell.*" (infixe). Les globs en milieu de segment
// comme "github.get_*" retombent sur une correspondance exacte et ne s'étendent pas.
{
  "default_verdict": "deny",
  "rules": [
    { "tool_name_glob": "github.create_issue", "verdict": "allow" },
    { "tool_name_glob": "github.get_issue",    "verdict": "allow" }
  ]
}
Maintenant github.create_issue s’exécute, github.get_issue s’exécute, et un github.delete_repo fraîchement introduit est refusé jusqu’à ce que vous l’ayez revu et permis. Un tools/call refusé revient au modèle comme une erreur d’outil (firewall deny: …) — l’agent s’adapte au lieu de planter. Voir Lister les outils MCP autorisés pour la recette complète, et Règles du firewall pour le DSL de correspondance.

​
4. Chiffrez le credential — ne bricolez jamais l’auth

Un serveur tiers a presque toujours besoin d’un credential, et un credential est la chose que vous voulez le moins voir traîner en clair ou atteindre le modèle. Enregistrez l’auth du serveur via OrcaRouter pour qu’elle soit chiffrée au repos, masquée en lecture, et injectée seulement au moment du dispatch. auth_mode est l’un de none, bearer, oauth, ou basic : 
# Route console, UserAuth, Developer+.
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\"}"
  }'
Le credential est chiffré et masqué dès qu’il est stocké — il n’atteint jamais le modèle ni le client, et en lecture vous ne voyez que le masque. Sur une mise à jour, renvoyez le masque tel quel pour conserver la valeur stockée ; envoyez un nouveau auth_json seulement quand vous faites la rotation. Voir S’authentifier et Rotation des credentials.

​
5. Verrouillez l’egress : où ses outils peuvent-ils atteindre ?

Les verdicts par appel décident quel outil s’exécute ; l’egress décide où il peut atteindre. Un outil qui « renvoie des données » et un outil qui « exfiltre vos secrets vers l’hôte d’un attaquant » peuvent être le même outil avec un argument différent — le contrôle d’egress est ce qui les distingue. La passerelle valide déjà chaque endpoint distant et son IP de connexion résolue contre une politique SSRF à chaque saut, refusant les plages intranet et l’adresse de métadonnées cloud et re-vérifiant l’IP pour déjouer le DNS rebinding. Par-dessus cela, rédigez votre propre règle de deny d’egress pour les hôtes et CIDR que ce serveur ne devrait jamais toucher : 
// Une règle de stage egress cadre son verdict sur la destination sortante.
// egress_json porte des listes allow + deny host/CIDR.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\"]}"
}
Il n’y a aucun preset qui livre des règles CIDR pour vous — vous rédigez la liste de deny host/CIDR vous-même, cadrée sur ce dont ce serveur a légitimement besoin. Voir Limites d’egress et Exfiltration de données.

​
6. Mettez en quarantaine ce que l’agent installe de lui-même

Le serveur que vous avez enregistré est un risque ; les skills, serveurs MCP BYO, et plugins qu’un agent auto-installe ensuite en sont un autre. OrcaRouter scanne chaque capacité installable, lui attribue une bande de risque, et en dérive un mode d’application — allow, quarantine, ou block — qui se superpose à chaque verdict de règle. Tout ce qui est auto-détecté à la première utilisation est mis en quarantaine jusqu’à ce qu’un humain le revoie : une capacité que personne n’a approuvée n’obtient pas de laissez-passer juste parce qu’elle a scanné bénin. Une capacité quarantine escalade tout ce qui n’est pas un deny en pending_approval, de sorte que ses outils ne s’exécutent qu’après que vous avez regardé.
N’essayez pas d’enregistrer chaque skill à la main. Pré-approuvez ceux en qui vous avez confiance et laissez le reste être auto-détecté et mis en quarantaine — puis revoyez à partir de données réelles. Le mode se resserre davantage à une re-scan, jamais plus lâche. Voir Firewall : skills et Empoisonnement d’outils MCP.

​
7. Shadow d’abord, puis surveillez la trace

Ne basculez pas un serveur tout neuf directement en enforcing. Mettez la politique en mode shadow — les verdicts enforcing sont rétrogradés en audit et journalisés comme [shadow] would … — pour que vous puissiez voir ce qui aurait été bloqué avant que ça ne le soit réellement. Quand la trace d’audit semble correcte, lâchez le mode shadow et appliquez. Une fois en service, les contrôles continuent de surveiller :
Chaque appel gouverné enregistre son verdict, sa surface, et sa règle correspondante. Lisez-les pour confirmer que la liste d’autorisation et les règles d’egress se comportent comme prévu. Voir Auditer les événements MCP.
Les pics de débit et de coût contre un référentiel appris, plus les boucles de réessai et les chemins d’outils inédits, font surface comme des anomalies — lisibles par tout Member.
Activez le mode observe pour journaliser les appels qu’une politique ne couvre pas encore comme des lacunes, de sorte que vous resserriez à partir de ce qu’un agent fait réellement, pas de conjectures.

​
8. Le chemin rapide : choisir un niveau d’autonomie

Si vous préférez ne pas construire à la main les étapes 3 à 5 pour un serveur en qui vous n’avez pas pleinement confiance, appliquez un niveau d’autonomie et éditez à partir de là. Les niveaux écrivent de vraies lignes de politique et de guardrail éditables — c’est un point de départ, pas une boîte noire :
NiveauCe qu’il définit
permissiveMode observe activé — journalise tout, n’applique rien.
balancedPolitique audit-par-défaut qui refuse le shell destructeur, plus le guardrail PII Shield en mode flag-uniquement.
tightPolitique de refus par défaut refusant le shell destructeur et les outils de forme fetch (http_fetch/web_search/fetch_url/request — le vecteur SSRF), plus les guardrails PII Shield et Secrets Blocker appliqués. Les secrets dans les arguments sont attrapés par le guardrail Secrets Blocker sur la requête, pas par une règle d’arg d’outil.
Pour un serveur tiers que vous êtes encore en train de passer en revue, commencez à tight, sondez, puis relâchez des outils spécifiques dans une liste d’autorisation. L’annulation en un clic restaure l’instantané d’avant l’application.
Les lectures des réglages, politiques, outils découverts, anomalies, serveurs MCP enregistrés, et skills sont ouvertes à tout Member ; les lectures d’événements, de runs et d’agrégats requièrent Developer+, et chaque écriture requiert Developer+. Révéler la clé en clair d’un token est aussi Developer+.

​
9. 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 d’un serveur et n’autoriser que les outils revus.

Défense contre le rug pull

Attraper un serveur ou un skill qui change après que vous l’avez approuvé.

Aperçu de la sécurité MCP

La carte complète de la surface de gouvernance MCP.
Nouveau sur le modèle ? Lisez Guardrails vs. firewall pour où s’inscrit la gouvernance MCP, puis Agence excessive et Appels d’outils dangereux pour les menaces que cette checklist ferme.