Contrôler l'accès aux serveurs MCP pour votre organisation

• Choisir un modèle qui correspond au niveau de contrôle dont vous avez besoin
• Déployer un ensemble de serveurs fixe avec managed-mcp.json, y compris comment désactiver MCP entièrement
• Contrôler les serveurs avec des listes blanches et des listes noires
• Indiquer aux utilisateurs à quoi s’attendre quand une restriction bloque un serveur
• Surveiller les serveurs que votre organisation utilise réellement

​

Choisir un modèle

​

Contrôle exclusif avec managed-mcp.json

• allowedMcpServers et deniedMcpServers s’appliquent également aux serveurs gérés, donc un serveur géré qui ne les satisfait pas ne se chargera pas.
• Le propre deniedMcpServers d’un utilisateur se fusionne à partir de ses paramètres, donc les utilisateurs peuvent bloquer un serveur géré pour eux-mêmes.

{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    },
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/mcp"
    },
    "company-internal": {
      "type": "stdio",
      "command": "/usr/local/bin/company-mcp-server",
      "args": ["--config", "/etc/company/mcp-config.json"],
      "env": {
        "COMPANY_API_URL": "https://internal.example.com"
      }
    }
  }
}

​

S’authentifier avec des identifiants par utilisateur

• Expansion ${VAR} pour lire les secrets de l’environnement de chaque utilisateur.
• OAuth ou en-têtes par utilisateur afin que chaque utilisateur s’authentifie en tant que lui-même.
• headersHelper pour générer des identifiants au moment de la connexion.

​

Valider la configuration

1. claude mcp list affiche uniquement les serveurs dans managed-mcp.json. Si les propres serveurs d’un utilisateur apparaissent toujours, le fichier n’est pas lu ; vérifiez le chemin et les permissions.
2. claude mcp add --transport http test https://example.com/mcp échoue avec Cannot add MCP server: enterprise MCP configuration is active and has exclusive control over MCP servers. L’URL n’a pas besoin d’être un vrai serveur, car la vérification de la politique rejette la commande avant que quoi que ce soit ne soit contacté.

​

Désactiver MCP entièrement

{
  "mcpServers": {}
}

​

Autoriser les connecteurs claude.ai aux côtés de l’ensemble géré

​

Contrôle basé sur les politiques avec listes blanches et listes noires

​

Faire correspondre les serveurs par URL, commande ou nom

• Dans deniedMcpServers, serverName accepte n’importe quelle chaîne non vide, donc vous pouvez bloquer les connecteurs claude.ai par leur nom d’affichage. Par exemple, { "serverName": "claude.ai Slack" } bloque le connecteur Slack. Préférez une entrée serverUrl quand vous avez besoin que le refus soit robuste aux renommages, ou quand un nom de connecteur entre en collision et gagne un suffixe (N).
• Dans allowedMcpServers, serverName est limité aux lettres, chiffres, traits d’union et traits de soulignement. Utilisez serverUrl pour ajouter un connecteur claude.ai à la liste blanche.

​

Comment un serveur est évalué

1. Fusionner les listes. Les entrées de liste blanche et de liste noire de chaque source de paramètres se combinent en une liste blanche et une liste noire. Quand allowManagedMcpServersOnly est true, seule la liste blanche gérée est conservée ; la liste noire fusionne toujours de chaque source.
2. Vérifier la liste noire. Un serveur qui correspond à n’importe quelle entrée de liste noire, par URL, commande ou nom, est bloqué. Rien ne remplace une correspondance de liste noire.
3. Vérifier la liste blanche. Si allowedMcpServers n’est défini nulle part, chaque serveur qui a réussi la liste noire se charge. S’il est défini, ce à quoi le serveur doit correspondre dépend de son type, indiqué dans le tableau ci-dessous.

• Les commandes correspondent exactement. Chaque argument, dans l’ordre. ["npx", "-y", "server"] ne correspond pas à ["npx", "server"] ou ["npx", "-y", "server", "--flag"].
• Les valeurs serverCommand et serverUrl se développent avant la correspondance. La valeur de la politique et la valeur configurée du serveur passent toutes les deux par la même expansion ${VAR} et ${VAR:-default} que .mcp.json, donc une entrée écrite comme ["${HOME}/bin/server"] correspond à une configuration de serveur qui utilise soit la même référence, soit le chemin développé. Sur Windows, référencez une variable d’environnement qui y est définie, telle que ${USERPROFILE} au lieu de ${HOME}. Les valeurs serverName correspondent littéralement et ne se développent jamais.
• Les URL supportent les caractères génériques * n’importe où dans le modèle, y compris le schéma. La correspondance du nom d’hôte est insensible à la casse et ignore un point FQDN final, donc https://Mcp.Example.com/* correspond à https://mcp.example.com/api. Les chemins restent sensibles à la casse.

​

Exemple de configuration

{
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverUrl": "https://mcp.sentry.dev/*" },
    { "serverCommand": ["npx", "-y", "@modelcontextprotocol/server-filesystem", "."] },
    { "serverCommand": ["python", "/usr/local/bin/approved-server.py"] },
    { "serverUrl": "https://mcp.example.com/*" },
    { "serverUrl": "https://*.internal.example.com/*" }
  ],
  "deniedMcpServers": [
    { "serverName": "dangerous-server" },
    { "serverCommand": ["npx", "-y", "unapproved-package"] },
    { "serverUrl": "https://*.untrusted.example.com/*" }
  ]
}

• Ligne 3 : la première entrée serverUrl. Une fois qu’elle existe, chaque serveur distant doit correspondre à un modèle d’URL, donc un utilisateur ne peut pas obtenir un serveur distant non répertorié en lui donnant un nom autorisé.
• Ligne 5 : la première entrée serverCommand. Même effet pour les serveurs stdio, donc chaque serveur local doit correspondre exactement à une commande répertoriée.
• Ligne 11 : une entrée serverName dans la liste noire. Les entrées de liste noire s’appliquent toujours, donc n’importe quel serveur nommé dangerous-server est bloqué indépendamment de son URL ou de sa commande.

{
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.example.com/*" },
    { "serverUrl": "https://*.internal.example.com/*" }
  ]
}

{
  "allowedMcpServers": [
    { "serverCommand": ["npx", "-y", "approved-package"] }
  ]
}

{
  "allowedMcpServers": [
    { "serverName": "github" },
    { "serverCommand": ["npx", "-y", "approved-package"] }
  ]
}

{
  "allowedMcpServers": [
    { "serverName": "github" },
    { "serverName": "internal-tool" }
  ]
}

{
  "allowedMcpServers": [
    { "serverUrl": "https://*.example.com/*" }
  ],
  "deniedMcpServers": [
    { "serverUrl": "https://staging.example.com/*" }
  ]
}

​

Restreindre la liste blanche aux paramètres gérés uniquement

{
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverUrl": "https://*.internal.example.com/*" }
  ]
}

​

Comment les restrictions apparaissent aux utilisateurs

​

Surveiller l’utilisation de MCP

​

Résumé de la configuration

​

Ressources connexes

• Décider ce qu’il faut appliquer : restrictions MCP aux côtés des règles de permission, du sandboxing et des autres contrôles d’administration
• Connecter Claude Code aux outils via MCP : la référence MCP complète, y compris les transports, les portées et l’authentification
• Paramètres : la hiérarchie des paramètres et comment les paramètres gérés ont la priorité
• Paramètres gérés par le serveur : livrer allowedMcpServers et deniedMcpServers à partir de la console d’administration Claude.ai
• Sécurité : le modèle de menace que ces contrôles défendent
• Guide de l’administrateur Claude Enterprise : SSO, SCIM, gestion des sièges et playbook de déploiement