Aller au contenu principal
Dernière mise à jour le

Gouverner un service MCP

Cette page décrit comment gouverner un service MCP avec les mêmes primitives Unity Catalog qui protègent vos autres éléments sécurisables : limiter les outils que le service expose, appliquer des politiques de service pour autoriser ou refuser des appels individuels, définir des limites de débit et surveiller l'utilisation. Ces contrôles s'appliquent à la fois aux services MCP que vous enregistrez et aux services MCP fournis par Databricks.

Sélectionnez les outils exposés​

Par default, un service MCP met à disposition tous les outils que le serveur MCP fournit. Pour rendre disponible seulement un sous-ensemble, sélectionnez les outils lors de la création du service MCP, ou mettez à jour la sélection plus tard. Chaque sélecteur est comparé aux noms d'outils : un modèle se terminant par * est une correspondance de préfixe (get_* correspond à get_me et get_issue), et toute autre valeur est une correspondance exacte (search_repositories correspond uniquement à cet outil).

Dans le flux de création, sous Outils :

  • Sélectionnez **Sélectionner manuellement** pour sélectionner chaque outil individuellement.
  • Sélectionnez Avancé pour saisir les modèles de sélection, en utilisant les règles de préfixe et de correspondance exacte décrites ci-dessus.
  • Activez Inclure automatiquement les outils ajoutés à ce serveur à l'avenir pour rendre les nouveaux outils disponibles au fur et à mesure que le serveur MCP les ajoute.

Les outils que vous ne sélectionnez pas n’apparaissent pas dans tools/list, et le service MCP rejette un tools/call pour un outil non sélectionné :

JSON
{ "code": -32003, "message": "Tool not allowed by MCP service configuration." }

Appliquer une politique de service​

info

Bêta

Les politiques de service sont en version bêta. Unity Gateway est disponible de manière générale, mais ses fonctionnalités bêta sont activées séparément. Un administrateur de compte doit activer les fonctionnalités bêta de Unity Gateway depuis la page Previews de la console du compte. Consultez Gérer les aperçus Databricks.

Une politique de service évalue chaque appel d'outil avant son exécution (la phase d'entrée, ON CALL) et, éventuellement, son résultat (la phase de sortie, ON RESULT). Une politique peut autoriser, refuser ou exiger une approbation humaine pour la requête — par exemple, pour bloquer des opérations destructrices ou des appels contenant des PII — sans modifier les outils disponibles. Les politiques de service font partie de la gouvernance de l'IA dans Unity Catalog.

Pour écrire une fonction de politique et l’associer à un service MCP, consultez Stratégies de service pour les éléments sécurisables d’IA et Créer et associer une stratégie de service.

Contrôler l'accès aux fournisseurs tiers​

Tout service MCP qui se connecte à un fournisseur d'applications tiers est régi à deux niveaux indépendants. La couche réseau détermine si une connexion au fournisseur peut être établie. La couche de privilèges contrôle si un utilisateur peut accéder au fournisseur par le biais du service MCP.

Cela s'applique aux serveurs MCP externes que vous enregistrez et aux applications connectées fournies par Databricks telles que Slack, GitHub, Atlassian, Google et Microsoft 365. Utilisez les deux couches ensemble pour contrôler qui peut accéder à un fournisseur externe et quels fournisseurs sont accessibles.

Contrôler les fournisseurs auxquels un service peut se connecter​

Un service MCP se connecte à l’API ou au serveur MCP du fournisseur via Unity Gateway. Ces requêtes externes sont soumises au contrôle de sortie Serverless. Avec une politique réseau à accès restreint , les connexions sortantes sont refusées par default. Un service MCP peut ensuite accéder à un fournisseur public uniquement si le domaine de celui-ci est une destination autorisée dans la stratégie. Les destinations atteintes en mode privé via Private Link sont implicitement autorisées.

Cela vous offre une configuration default désactivée pour les services MCP externes, sans paramètres par service. Un fournisseur qui n’est pas autorisé dans la politique réseau est bloqué au niveau de la couche réseau, même pour un utilisateur disposant de EXECUTE sur le service. Pour autoriser ou bloquer un fournisseur et trouver toutes les destinations requises par un service, consultez Allow an MCP server in a network policy.

Contrôler qui peut appeler le service​

Un service MCP est un élément sécurisable de Unity Catalog. Un utilisateur ne peut appeler les outils fournis par le service MCP que s’il détient EXECUTE sur le service. Ils ont également besoin de USE CATALOG et de USE SCHEMA sur son catalogue parent et son schéma. Pour restreindre l’accès :

  • Accordez ces privilèges uniquement aux utilisateurs ou groupes approuvés plutôt que largement sur le schéma qui contient le service.
  • Examinez et révoquez toutes les autorisations étendues existantes au niveau du schéma qui laisseraient autrement le service appelable. Pour les services fournis par Databricks, recherchez un default grant sur le schéma system.ai.
  • Optionnellement, utilisez les politiques ABAC GRANT pour accorder EXECUTE de manière dynamique à partir de tags gouvernés, de sorte que seuls les services approuvés soient autorisés et que ceux ajoutés ultérieurement soient automatiquement exclus.

Associez ces attributions aux stratégies de service pour autoriser, refuser ou exiger une approbation pour les appels d'outils individuels.

remarque

Le contrôle de sortie serverless et la gouvernance Unity Catalog sont des couches indépendantes et complémentaires. Une attribution Unity Catalog n'ouvre pas de chemin réseau, et l'ajout d'un fournisseur à une politique réseau n'accorde pas l'autorisation Unity Catalog sur un service. La création d'une connexion Unity Catalog n'autorise pas automatiquement sa destination dans une politique réseau à accès restreint. L'autorisation implicite pour les connexions Unity Catalog est obsolète ; les comptes qui l'utilisaient avant son abrogation la conservent pendant une période de transition limitée. Utilisez les deux couches ensemble pour assurer une défense en profondeur.

Définir les limites de débit​

Limitez la fréquence à laquelle les agents peuvent appeler un service MCP pour contrôler les coûts et protéger le serveur externe. Voir Appliquer des limites de débit aux services de modèle et MCP.

Surveiller l'utilisation​

Unity Gateway enregistre l’activité de chaque service MCP dans les tables système de Unity Catalog :

  • Utilisation : volume d'appels, erreurs et latence dans system.ai_gateway.usage (filtre service_type = 'MCP_SERVICE'). Consultez Suivre l’utilisation du modèle.
  • Audit : modifications du plan de contrôle (createMcpService, updateMcpService, deleteMcpService) et chaque invocation (mcpCall) dans system.access.audit. Consultez référence de la table système des Audit Logs.
  • Traces : Les requêtes d’appel d’outil, les réponses et les décisions de politique sont capturées par la journalisation des traces, qui est activée une fois au niveau du compte et partagée entre tous les services MCP.
  • Tableau de bord : le trafic du serveur MCP externe apparaît dans le tableau de bord d’utilisation intégré de Unity Gateway. Voir Tableau de bord d’utilisation intégré.

Pour toutes les tables système Unity Catalog, consultez Référence des tables système. Pour un aperçu de la gouvernance du trafic d'IA, consultez Gouvernance de l'IA dans Unity Catalog.

Étapes suivantes​

Sur cette page