Passer au contenu principal
Un agent MCP est un agent doté d’une portée. Chaque serveur Model Context Protocol auquel il se connecte est un nouvel ensemble d’outils, d’identifiants et de destinations réseau que personne n’a revu — et l’agent peut en tirer un nouveau en plein milieu d’une exécution. Cette recette montre les quatre mouvements qui transforment une installation MCP tentaculaire en une installation gouvernée sur la passerelle hébergée : une seule passerelle MCP auditée, la quarantaine de skills, le refus d’egress, et l’auth de serveur chiffrée. Vous configurez tout cela depuis la console (ou l’API REST) contre votre espace de travail. Votre agent continue de parler MCP exactement comme avant.

​
1. Pourquoi sécuriser un agent MCP

Pointez un agent directement vers cinq serveurs MCP et vous avez cinq frontières de confiance, cinq stores d’identifiants et zéro piste d’audit partagée. Le tools/call qui lit un dossier client et celui qui exécute une commande shell sont identiques aux yeux du modèle, et un serveur communautaire peut discrètement demander shell.exec et une portée réseau externe la première fois qu’il se charge. La solution est de faire d’OrcaRouter l’unique point d’étranglement que chaque appel franchit. Pour sécuriser le trafic d’un agent MCP de bout en bout, vous routez tout le dispatch MCP à travers la passerelle MCP du Firewall, de sorte que chaque tools/call soit évalué par la politique avant qu’il n’atteigne le vrai serveur — avec les skills scorés en risque, l’egress gouverné, et les identifiants chiffrés au repos.
C’est une recette — elle assemble des fonctionnalités existantes en une passe de durcissement concrète. Pour la référence complète, suivez les liens vers Firewall, Serveurs MCP, et Skills.

​
2. Partez du référentiel Secure Agents

Avant de rédiger quoi que ce soit de sur-mesure, définissez une posture. Dans la console, ouvrez Firewall → Posture et appliquez le niveau d’autonomie balanced (rôle Developer). En une seule transaction, il audite les appels d’outils et signale la PII tout en refusant les actions les plus destructrices — vous observez avant d’appliquer largement, avec annulation en un clic. Quand les flux Events et Runs semblent corrects, passez à tight : deny par défaut, shell destructeur refusé, egress de forme SSRF refusé, plus les guardrails PII Shield et Secrets Blocker appliqués. Cet unique interrupteur est le plancher sur lequel cette recette se construit.
Vous préférez monter en puissance sans basculer tout l’espace de travail ? Rédigez les règles ci-dessous dans une politique nommée et activez son mode shadow — il évalue et journalise mais rétrograde chaque verdict appliquant en audit (raison préfixée [shadow] would …) jusqu’à ce que vous soyez sûr. Voir modes d’application.

​
3. Routez chaque tools/call à travers une seule passerelle MCP

Enregistrez chaque serveur MCP une fois ; la passerelle agrège leurs outils sous une seule connexion (namespacés <server>.<tool>) et exécute chaque tools/call à travers le moteur du firewall. Enregistrez un serveur depuis la console (ou l’API REST, Developer+) : 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-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
  }'
Puis pointez votre client MCP vers la passerelle — pas vers les serveurs amont — en utilisant une clé dédiée scopée à la passerelle firewall : 
https://api.orcarouter.ai/api/v1/firewall/mcp
Désormais github.create_issue et shell.exec apparaissent côte à côte sous une seule connexion, et chaque dispatch est évalué avant de s’exécuter. Un appel bloqué revient au modèle comme une erreur d’outil (firewall deny: …), pas un plantage de transport, donc l’agent peut s’adapter.
Une clé de relais ordinaire reçoit un 403 sur la route de passerelle /api/v1/firewall/mcp. Frappez un token de passerelle dédié (is_firewall_gateway) pour la connexion MCP ; lire le texte en clair de cette clé de passerelle nécessite Admin+.
Avant de pouvoir écrire des règles contre les outils d’un serveur, sondez-le pour découvrir leurs noms et schémas : 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-token>"

​
4. Mettez en quarantaine les skills que l’agent tire

La passerelle MCP gouverne les appels ; la gouvernance de skills gouverne les capacités qu’un agent charge. Chaque skill installable, serveur MCP BYO, ou plugin est scanné dans une bande de risque et un mode d’application qui se superpose à chaque verdict de règle :
ModeEffet à l’exécution
allowLes verdicts de règle décident ; le skill n’ajoute rien.
quarantineTout ce qui est en-deçà d’un deny est mis en attente pour pending_approval.
blockLes outils du skill sont refusés de force.
L’enjeu pour un agent MCP : une capacité que personne n’a approuvée n’a pas de laissez-passer. Quand un agent s’auto-installe quelque chose et que ses outils franchissent la passerelle pour la première fois, le Firewall l’auto-détecte et le met en quarantaine jusqu’à ce qu’un humain le revoie — même s’il a été scanné comme propre. Pré-approuvez les serveurs auxquels vous faites confiance ; laissez le reste atterrir dans la file d’attente de revue.
Gardez balanced/observe activé pendant que vous apprenez ce que votre agent installe réellement, puis promouvez les skills de confiance en allow et laissez la longue traîne en quarantaine. Voir Skills.

​
5. Refusez l’egress de forme SSRF

Un outil MCP compromis ou confus qui tend la main vers le cloud-metadata ou un hôte intranet est le chemin d’exfiltration classique. Deux couches le couvrent. D’abord, la passerelle valide chaque endpoint MCP distant et son IP de composition résolue contre une politique SSRF à l’enregistrement et à chaque saut de dispatch — les plages intranet et l’adresse cloud-metadata sont refusées, re-vérifiées pour déjouer le DNS rebinding. C’est intégré ; vous ne le configurez pas. Ensuite, le niveau d’autonomie tight livre un preset d’egress SSRF qui refuse les noms d’outils de forme « fetch » — http_fetch, web_search, fetch_url, request, et leurs formes namespacées <server>.* — de sorte qu’un outil dont tout le travail est « va chercher cette URL » est stoppé avant de composer. Pour gouverner où les outils peuvent atteindre par destination, rédigez votre propre règle egress avec une liste de deny host/CIDR — c’est la surface pour épingler la portée sortante : 
// firewall rule, egress stage — deny outbound to an internal range.
// egress_json is a JSON *string*: {"deny":[…],"allow":[…]} of hosts/CIDRs.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\",\"169.254.169.254\"]}"
}
Aucun preset ne livre de règles d’egress CIDR — le preset SSRF correspond aux noms d’outils, pas aux destinations. Rédigez vous-même la denylist host/CIDR quand vous avez besoin d’un contrôle au niveau de la destination. Voir listes d’egress et arrêter l’exfiltration.

​
6. Gardez les identifiants de serveur chiffrés

Le auth_json de chaque serveur MCP est chiffré au repos et masqué à la lecture ; la passerelle injecte les identifiants au moment du dispatch, de sorte qu’ils n’atteignent jamais le modèle ni le client. Valeurs auth_mode supportées :
{ "token": "…" } — un token bearer statique, envoyé comme Authorization: Bearer.
{ "client_id": "…", "client_secret": "…", "token_url": "…" } — OAuth client-credentials ; la passerelle récupère et rafraîchit le token.
{ "username": "…", "password": "…" } — auth HTTP Basic.
"" — un serveur non authentifié. Le défaut.
À la lecture, le secret est masqué ; renvoyez le masque tel quel à la mise à jour pour conserver la valeur stockée. Le status du serveur (ok / degraded / down) de la dernière sonde vous indique s’il est joignable avant que vous n’en dépendiez.

​
7. Ajoutez un guardrail de contenu sur la requête

Le Firewall gouverne les actions ; associez-le à un Guardrail pour que le texte qui circule à travers votre agent MCP soit filtré aussi. Le preset Secrets Blocker attrape les identifiants dans une requête avant que le modèle — ou tout outil — ne les voie jamais, et un PII Shield masque les identifiants à l’entrée. Les deux s’activent avec le niveau d’autonomie tight, ou attachez un guardrail nommé à la clé de relais de l’agent via guardrail_id.
Le verdict sanitize du firewall redacte les arguments d’appel d’outil, jamais le contenu qu’un outil renvoie. Retirez les secrets de la requête avec le guardrail Secrets Blocker ; assainissez les arguments qu’un agent émet avec une règle de firewall. Ils couvrent des moitiés différentes du flux.

​
8. Vérifiez et surveillez

Confirmez que la politique fait ce que vous attendez avant de lui faire confiance, puis gardez un œil sur les flux :

Tester un appel d'outil

Exécutez en dry-run un tools/call d’échantillon contre votre politique et voyez le verdict, la règle correspondante et la raison — rien de dispatché, rien de journalisé.

Outils découverts

Chaque outil que l’espace de travail a vu, marqué covered ou gap — rédigez des règles directement à partir du trafic MCP réel.

Events & Runs

Chaque dispatch, son verdict, et la surface qu’il a touchée, agrégés par exécution d’agent.

Flux d'anomalies

Pics de débit/coût, boucles de retry, et chemins d’outils inédits contre une baseline apprise.

​
9. Où aller ensuite

Empoisonnement d'outil MCP

Le modèle de menace derrière la quarantaine et la passerelle MCP.

Agence excessive

Pourquoi deny par défaut et HITL importent pour l’usage d’outils autonome.

Recette agent autonome

Durcissez de bout en bout un agent à haute autonomie.

Arrêter l'exfiltration

Verrouillez l’egress sortant en profondeur.