Lister les outils MCP autorisés par politique

Un serveur MCP enregistré annonce les outils qu’il veut — et un agent en appellera volontiers n’importe lequel. La posture sûre est l’inverse : décidez la courte liste d’outils dont vous avez réellement besoin, autorisez exactement ceux-là, et refusez le reste. C’est une liste d’autorisation, et sur OrcaRouter vous la construisez à partir de règles tool_name_glob évaluées sur la surface mcp. Chaque tools/call qui traverse la passerelle MCP passe par votre politique firewall avant d’atteindre le vrai serveur. Donc la liste d’autorisation n’est pas consultative — un appel à un outil que vous n’avez pas autorisé ne se dispatche jamais.

​

1. Pourquoi une liste d’autorisation à refus par défaut pour des outils mcp sécurisés

Une liste de refus — « bloquer les outils dangereux » — échoue à l’instant où un serveur ajoute un nouvel outil, en renomme un, ou que vous connectez un second serveur. L’ensemble des outils dangereux est ouvert ; l’ensemble que vous vouliez utiliser est petit et connu. Une liste d’autorisation inverse le défaut de sorte que l’inconnu est refusé, pas admis :

• Les nouveaux outils sont refusés par défaut. Un serveur qui se dote d’un outil delete_repo après que vous l’avez connecté ne peut pas être appelé tant que vous ne l’avez pas ajouté à la liste d’autorisation.
• La portée est par serveur. Le namespace <server>.<tool> vous laisse autoriser github.create_issue tout en refusant tout le reste sous github.*.
• Un seul point d’étranglement. La même politique gouverne le serveur intégré et chaque serveur BYO derrière la passerelle, donc il y a un seul endroit pour lire la liste d’autorisation.

​

2. Les deux pièces

Une liste d’autorisation est un default_verdict plus un ensemble ordonné de règles. Le glob est confronté au nom d’outil avec namespace — github.create_issue, shell.exec. * correspond à n’importe quel outil (utilisez-le avec parcimonie ; une règle d’autorisation avec * défait toute la liste d’autorisation). Un <server>. en tête cadre le glob à un seul serveur.

​

3. Un exemple concret

Vous avez connecté un serveur github et vous voulez seulement que les agents lisent et ouvrent des issues — jamais supprimer ni administrer quoi que ce soit. Dans la console, ouvrez Firewall → Policies, réglez le verdict par défaut de la politique sur deny, et ajoutez deux règles d’autorisation : C’est toute la liste d’autorisation. Avec le défaut à deny :

• github.create_issue → correspond à la règle 1 → allow, se dispatche.
• github.delete_repo → ne correspond à rien → deny par défaut.

Un appel MCP refusé revient au modèle comme une erreur d’outil (firewall deny: …) — la même forme que renvoie n’importe quel outil défaillant — de sorte que l’agent peut s’adapter au lieu de planter. (Sur la surface inbound un deny est plutôt un HTTP 400 avec le code d’erreur firewall_blocked.)

​

4. Resserrer avec les arguments

Un nom d’outil sur la liste d’autorisation peut quand même être appelé avec de mauvais arguments. Resserrez davantage en ajoutant une clause args_match (JSONPath + un opérateur comme eq, contains, regex, in, ou cidr_match) à la règle, ou en superposant une règle deny au-dessus de l’allow pour une forme d’argument spécifique — par exemple, autorisez github.create_issue mais deny-le quand le dépôt cible n’est pas sur une liste approuvée. Voir la référence des règles du firewall pour l’ensemble complet des opérateurs.

​

5. Le déployer en sécurité

Basculez un refus par défaut à l’échelle du serveur en production et vous risquez de casser un agent qui dépendait discrètement d’un outil que vous avez oublié. Deux réglages dé-risquent : Une fois le journal shadow propre — aucun appel légitime n’aurait été refusé — effacez shadow_mode et la liste d’autorisation s’applique.

​

6. Vérifier que ça marche

Après l’application, confirmez que les outils refusés sont réellement écartés :

• Dry-run d’un tools/call contre la politique (Developer+) pour voir le verdict et quelle règle — ou le défaut — l’a produit, sans envoyer de trafic réel. Passez un nom d’outil, une surface, et des arguments d’exemple ; le moteur les évalue et renvoie la trace de verdict sans enregistrer d’événement.
• Surveillez les événements. Chaque appel bloqué enregistre un événement firewall qu’un Developer+ peut lire dans la console ; la page événements d’audit couvre le flux et ses champs.

​

Connexe