Gerenciar um serviço MCP
Esta página descreve como governar um Serviço de MCP com as mesmas primitivas do Unity Catalog que protegem seus outros securables: limite quais ferramentas o serviço expõe, aplique políticas de serviço para permitir ou negar chamadas individuais, defina limites de taxa e monitore o uso. Esses controles se aplicam tanto a serviços de MCP que você registra quanto a Serviços de MCP fornecidos pela Databricks.
Selecione quais ferramentas são expostas
Por default, um Serviço MCP disponibiliza todas as ferramentas que o servidor MCP fornece. Para disponibilizar apenas um subconjunto, selecione as ferramentas ao criar o Serviço MCP, ou atualize a seleção posteriormente. Cada seletor é correspondido a nomes de ferramentas: um padrão que termina em * é uma correspondência de prefixo (get_* corresponde a get_me e get_issue), e qualquer outro valor é uma correspondência exata (search_repositories corresponde apenas a essa ferramenta).
- UI
- REST API
No fluxo de criação, em Ferramentas :
- Selecione Selecionar manualmente para selecionar cada ferramenta individualmente.
- Selecione **Avançado** para inserir padrões de seleção, usando as regras de prefixo e de correspondência exata descritas acima.
- Ative **Incluir ferramentas adicionadas a este servidor automaticamente no futuro** para disponibilizar novas ferramentas à medida que o servidor MCP as adicionar.
Para alterar a seleção de ferramentas após a criação, defina include_tool_selectors com uma solicitação de PATCH. Restringir um serviço a somente get_* ferramentas:
databricks api patch \
"/api/2.1/unity-catalog/mcp-services/main.default.my_mcp?update_mask=config.include_tool_selectors" \
--json '{
"config": {
"include_tool_selectors": ["get_*"]
}
}'
Reset para disponibilizar todas as ferramentas definindo include_tool_selectors para uma lista vazia.
As ferramentas que você não selecionar não aparecem em tools/list, e o serviço MCP rejeita um tools/call para uma ferramenta não selecionada:
{ "code": -32003, "message": "Tool not allowed by MCP service configuration." }
Aplicar uma política de serviço
Beta
As políticas de serviço estão em Beta. O Unity Gateway está disponível de forma geral, mas seus recursos beta são habilitados separadamente. Um administrador de conta deve ativar os recursos beta do Unity Gateway na página Prévias do console da account. Consulte Gerenciar prévias do Databricks.
Uma política de serviço avalia cada chamada de ferramenta antes de sua execução (a fase de entrada, ON CALL) e, opcionalmente, seu resultado (a fase de saída, ON RESULT). Uma política pode permitir, negar ou exigir aprovação humana para a solicitação — por exemplo, para bloquear operações destrutivas ou bloquear chamadas que contenham PII — sem alterar quais ferramentas estão disponíveis. As políticas de serviço fazem parte da governança de AI no Unity Catalog.
Para escrever uma função de política e anexá-la a um serviço MCP, consulte Políticas de serviço para securables de AI e Criar e anexar uma política de serviço.
Controlar o acesso a provedores de terceiros
Qualquer serviço MCP que se conecte a um provedor de aplicativos de terceiros é governado em duas camadas independentes. A camada de rede controla se uma conexão com o provedor pode ser estabelecida. A camada de privilégios controla se um usuário pode acessar o provedor por meio do serviço MCP.
Isto se aplica a servidores MCP externos que você registra e a aplicativos conectados fornecidos pelo Databricks, como Slack, GitHub, Atlassian, Google e Microsoft 365. Use ambas as camadas juntas para controlar quem pode acessar um provedor externo e quais provedores podem ser acessados.
Controle a quais provedores um serviço pode se conectar
Um serviço MCP se conecta à API ou ao servidor MCP do provedor por meio do Unity Gateway. Essas solicitações externas estão sujeitas ao controle de saída serverless. Com uma política de rede de acesso restrito , as conexões de saída são negadas por default. Um serviço MCP poderá acessar um provedor público somente se o domínio do provedor for um destino permitido na política. Os destinos alcançados de forma privada por meio do Private Service Connect são permitidos implicitamente.
Isso oferece uma postura default desativada para Serviços MCP externos sem configurações por serviço. Um provedor que não seja permitido na política de rede é bloqueado na camada de rede, mesmo para um usuário que possua EXECUTE no serviço. Para permitir ou bloquear um provedor e encontrar todos os destinos de que um serviço precisa, consulte Permitir um servidor MCP em uma política de rede.
Controlar quem pode invocar o serviço
Um serviço MCP é um objeto protegível do Unity Catalog. Um usuário pode invocar as ferramentas fornecidas pelo serviço MCP apenas se possuir EXECUTE no serviço. Eles também precisam de USE CATALOG e USE SCHEMA em seu catálogo e esquema pai. Para restringir o acesso:
- Conceda esses privilégios apenas a usuários ou grupos aprovados, em vez de amplamente no esquema que contém o serviço.
- Revise e revogue quaisquer concessões (grants) amplas existentes em nível de esquema que, de outra forma, deixariam o serviço chamável. Para serviços fornecidos pelo Databricks, verifique se há uma concessão (grant) default no esquema
system.ai. - Opcionalmente, use políticas GRANT de ABAC para conceder
EXECUTEdinamicamente a partir de tags governadas, de modo que apenas serviços aprovados sejam permitidos e quaisquer adicionados posteriormente sejam automaticamente excluídos.
Combine essas concessões com políticas de serviço para permitir, negar ou exigir aprovação para chamadas de ferramentas individuais.
O controle de saída serverless e a governança do Unity Catalog são camadas independentes e complementares. Uma concessão do Unity Catalog não abre um caminho de rede, e adicionar um provedor a uma política de rede não concede permissão do Unity Catalog em um serviço. Criar uma conexão do Unity Catalog não permite automaticamente o seu destino em uma política de rede de acesso restrito. A inclusão em lista de permissões implícita para conexões do Unity Catalog foi descontinuada; as contas que a utilizavam antes da descontinuação a mantêm por um período de transição limitado. Use ambas as camadas juntas para defesa em profundidade.
Definir limites de taxa
Limite a frequência com que os agentes podem chamar um serviço MCP para controlar custos e proteger o servidor externo. Consulte Aplicar limites de taxa a serviços de modelo e MCP.
Monitore o uso
O Unity Gateway registra a atividade de cada serviço MCP nas tabelas do sistema do Unity Catalog:
- Uso : volume de chamadas, erros e latência em
system.ai_gateway.usage(filtroservice_type = 'MCP_SERVICE'). Consulte Acompanhar uso do modelo. - Auditoria : alterações no plano de controle (
createMcpService,updateMcpService,deleteMcpService) e cada invocação (mcpCall) emsystem.access.audit. Consulte a referência da tabela do sistema de log de auditoria. - Rastreamentos : as solicitações de chamada de ferramentas, respostas e decisões de política são capturadas pelo registro em log de rastreamento, que é habilitado uma vez no nível da conta e compartilhado em todos os Serviços MCP.
- Dashboard : o tráfego do servidor MCP externo aparece no painel de uso integrado do Unity Gateway. Consulte Painel de uso integrado.
Para todas as tabelas do sistema do Unity Catalog, consulte Referência de tabelas do sistema. Para uma visão geral da governança do tráfego de AI, consulte governança de AI no Unity Catalog.
Próximos os passos
- Registrar um servidor MCP externo para registrar e invocar um servidor MCP externo.
- Políticas de serviço para ativos de segurança de AI para conceitos de política de serviço e proteções integradas.
- O que é o controle de saída serverless? para controlar quais provedores externos seus serviços de MCP podem acessar.
- Monitore toda a atividade de IA usando a tabela de rastreamento unificada para monitorar, depurar e auditar toda a atividade de MCP a partir de um único local.
- Governança de AI com o Unity Gateway para governar servidores MCP e LLM Endpoint a partir de um local central.