Réseautage MCP

Vérifiez l’accès au réseau dans deux directions : de votre client Model Context Protocol (MCP) vers votre espace de travail, et de votre espace de travail vers des serveurs MCP externes. Pour la connexion et l’identité, voir authentification MCP.

Du client vers l’espace de travail

Les requêtes MCP doivent être autorisées par les contrôles réseau entrants de votre espace de travail. Si les listes d’accès IP de l’espace de travail sont activées, demandez à un administrateur d’autoriser les adresses IP publiques d’origine des requêtes :

Où s’exécute le client MCP Adresses à autoriser
Sur votre ordinateur, comme Claude Code, Codex CLI ou Cursor L’IP publique sortante de votre réseau. Si le trafic passe par un VPN ou un proxy d’entreprise, utilisez l’IP sortante de ce réseau. Demandez à votre administrateur réseau.
Dans un service hébergé, tel qu’un connecteur Claude ou ChatGPT Les plages d’IP sortantes publiées par le fournisseur. Voir les IP sortantes de Claude et les IP sortantes de ChatGPT.

Pour les clients hébergés, la connexion au navigateur se fait depuis votre réseau, tandis que les appels MCP proviennent des serveurs du fournisseur. Les deux doivent être autorisés. Par exemple, se connecter correctement depuis votre VPN d’entreprise ne signifie pas que ChatGPT peut atteindre votre MCP.

Si votre organisation utilise également des contrôles d’entrée contextuels, les requêtes doivent également satisfaire à ces politiques. Les listes d’accès IP des comptes s’appliquent à l’accès à la console de compte et à l’API de compte, comme un administrateur créant une application OAuth.

Workspace vers serveur MCP externe

Les appels vers des fournisseurs MCP externes via Unity Gateway utilisent le plan de calcul serverless de l’espace de travail. Cela s’applique aux serveurs externes enregistrés et aux MCP fournis par Databricks pour les services externes.

Si votre politique réseau sans serveur utilise l’accès restreint, ajoutez le nom de domaine entièrement qualifié (FQDN) du serveur à Domaines autorisés. Commencez par l’hôte sur la connexion Unity Catalog du MCP. Vérifiez system.access.outbound_network la présence d’autres destinations bloquées. Voir Gérer les politiques réseau et les journaux réseau sortants.

  • Une connexion Unity Catalog n’autorise pas automatiquement sa destination.
  • L’accès complet est le mode de la politique réseau sans serveur permettant par défaut les connexions internet sortantes. Les domaines explicitement bloqués restent refusés. Par exemple, une politique qui bloque mcp.example.com empêche les appels vers ce serveur MCP. Demandez à un administrateur de vérifier les destinations bloquées dans la politique.
  • Pour tester le trafic MCP en mode test à blanc, sélectionnez Tous les produits. Les options de service des modèlesSQL et IA de Databricks ne mettent pas le trafic MCP en échec à blanc.

Connectivité privée

Pour atteindre un serveur MCP dans votre réseau cloud, choisissez comment le calcul serverless Azure Databricks s’y connecte :

  • Point de terminaison privé : Utilisez Private Link pour conserver le trafic sur une connexion privée. Un administrateur de compte ajoute une règle de terminaison privée pour le domaine du serveur à une configuration de connectivité réseau (NCC) attachée à votre espace de travail. Votre administrateur cloud approuve la connexion de terminaison. Voir Configurer la connectivité privée.
  • Endpoint public avec pare-feu : Configurez le pare-feu du serveur pour permettre à Azure Databricks d'obtenir des IP sortantes serverless pour le cloud et la région de votre espace de travail. Ces IP sont partagées entre les clients Azure Databricks, il faut donc maintenir l’authentification activée sur le serveur. Voir Trouver les IP sortantes et configurer votre pare-feu.

Les domaines ajoutés aux règles de points de terminaison privés sont automatiquement autorisés par les politiques réseau, donc vous n’avez pas besoin de les ajouter séparément aux domaines autorisés. Pour un point de terminaison public, suivez Workspace vers un serveur MCP externe.