How do I secure MCP servers in the enterprise?
Summary
- MCP servers are registered as Unity Catalog objects, and agents access them through Unity Gateway, never directly. This ensures all traffic is audited and credentials are managed centrally.
- Fine-grained access control uses standard SQL grants (GRANT EXECUTE ON MCP SERVICE) that take effect instantly, with no redeployment required.
- On-behalf-of execution ensures agents interact with MCP servers using the requesting user's exact permissions, not a shared service account.
- Payload logging captures every tool call to a Delta table with caller identity, request, response, and whether the call was allowed or denied.
- Service policies let you define SQL-based rules to block, allow, or require approval for tool calls based on context and caller identity.
How do I secure MCP servers in the enterprise?
Securing MCP servers at enterprise scale requires three things: preventing agents from connecting directly to servers, ensuring every call is logged and auditable, and enforcing that users access data through the server with their own permissions, not a shared account. Unity Gateway accomplishes all three by making MCP servers first-class Unity Catalog securables. Agents never connect directly; instead, they request tool calls through Unity Gateway, which validates permissions, attaches managed credentials, and proxies the request.
What is an MCP server?
A Model Context Protocol (MCP) server is a tool provider that AI agents can invoke to retrieve data, take actions, or integrate with external systems (issue tracking, chat platforms, CRM systems, or custom APIs). Without governance, agents could directly connect to MCP servers, bypassing audit trails and permission checks. Enterprise deployments need a gating layer that enforces policy.
Key security capabilities to evaluate
| Capability | Why it matters |
|---|---|
| Centralized credential storage | Agents should never hold or pass server credentials directly; a credential manager should inject them at call time. |
| Fine-grained access control | Permissions must be granted per user/group per tool, not all-or-nothing server access. |
| Audit trail | Every tool call (who, what, when, result) must be logged immutably for compliance and investigation. |
| Policy enforcement | Admins must be able to block certain actions (e.g., "no writes to production") without redeploying agents. |
| On-behalf-of execution | Users should access data as themselves, not through a service account that has broad permissions. |
| Network isolation | Servers should be reachable only through approved paths (private networks, firewalls, proxies), not the public internet. |
| Request/response inspection | Sensitive data in tool responses (PII, secrets) should be detectable and can trigger policies. |
How Databricks secures MCP servers
Core architecture: MCP servers are registered as Unity Catalog objects (catalog.schema.mcp_service) [1]. Agents never connect directly; instead, Unity Gateway acts as the only gateway to the server. Every tool call flows through Unity Gateway, which validates permissions, attaches credentials, logs the call, and enforces policies before forwarding to the server [1][4].
Access control: Use standard SQL grants to control who can invoke MCP services [1][25]:
GRANT EXECUTE ON MCP SERVICE catalog.schema.svc TO principal;
Revoke takes effect instantly with no redeployment [25]:
REVOKE EXECUTE ON MCP SERVICE catalog.schema.svc FROM principal;
You can also limit which tools within a service are exposed to specific users [1][19].
Credential management: Credentials are stored securely in Unity Catalog connections (HTTP type with OAuth or PAT authentication) and are never exposed to agents [4][29]. When an agent calls a tool, Unity Gateway retrieves the credential and injects it into the request.
On-behalf-of (OBO) execution: Agents interact with MCP servers using the requesting user's exact permissions, not a shared service account [5][23]. This ensures data access is auditable to individuals, not a generic bot account.
Service policies: Define SQL-based rules to enforce business logic [14][16]:
-- Example: Block writes to production tables
CREATE OR REPLACE POLICY prod_write_block
AS (caller_role != 'admin') THEN deny('Write access denied');
Policies evaluate every tool call and can block, allow, or route to an approval workflow based on context.
Audit logging: Every action (registerMcpService, updateMcpService, deleteMcpService, and mcpCall) is captured in system.access.audit [25]. Additionally, complete payload logs (tool name, arguments, result, caller identity, allow/deny decision) are captured in a Delta table for SQL-based investigation [16].
Network security
MCP traffic routes through your workspace's serverless compute plane [8][9]. Secure the outbound path:
- For Restricted access mode with serverless egress control, add the MCP server's fully qualified domain name (FQDN) to your Allowed domains list [9]
- For Private Link connectivity, use Private Link instead of exposing servers to the internet
- Denied connections are recorded in
system.access.outbound_networkfor troubleshooting [8]
Enterprise implementation pattern
Following this workflow ensures governance at scale [25]:
- Register external MCP servers as Unity Catalog HTTP connections (with OAuth or PAT authentication)
- Create MCP Services that reference these connections
- Grant
EXECUTEprivileges to authorized teams - Apply tool selection to expose only necessary tools
- Attach service policies to enforce business rules
- Monitor usage through
system.access.auditand payload Delta tables
Use cases
Coding agents with external tools. Developers use coding agents to work with issue tracking systems, version control platforms, or internal services. Unity Gateway ensures agents can only call tools they're authorized for, and every call is logged to the developer's identity.
Data platform automation. Agents that automate data pipelines, trigger jobs, or manage infrastructure. Service policies prevent agents from modifying production resources without approval.
Customer support agents. Agents that look up customer information or create tickets. OBO execution ensures lookups are auditable to the agent operator, not a shared bot account.
FAQs
Can I use MCP servers without Unity Gateway?
Yes, agents can connect directly to MCP servers (not registered in Unity Catalog). However, you lose centralized credential management, audit trails, and policy enforcement. Direct connections are not recommended for enterprise deployments.
How do I control which tools an agent can access?
Register tools with Tool Selection in Unity Catalog. When an agent calls a tool, Unity Gateway checks the user's permissions for that specific tool and allows or denies the call.
What happens if a tool call is denied by a policy?
The agent receives a structured error message that includes the reason for the denial. The full event (request, response, deny reason, caller identity) is logged in system.access.audit and payload logs for investigation.
Can I route tool calls to an approval workflow?
Yes. Service policies can route calls to an approval system based on criteria (e.g., "require approval for any write to production"). Approved calls proceed automatically; rejected calls are logged as denied.
The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.