Can an AI gateway govern MCP servers and tool access?

Summary

• Yes. When MCP servers and their tools sit behind an AI gateway, every tool call is authenticated, authorized, filtered, and logged in one place instead of being left to each agent.
• On Databricks that gateway is Unity Gateway (generally available). MCP servers, the functions agents call as tools, the connections to external systems, and the agents themselves are registered as Unity Catalog securable objects and governed with the same GRANT and REVOKE privileges as data.
• Tool filtering exposes only the specific tools an agent should see, turning broad server access into fine-grained control over which actions are reachable.
• Service policies (in Beta) evaluate each tool call before and after it reaches the server and can allow, deny, or require approval based on who is calling and what the call contains.
• Every call runs as the requesting user, so a tool can reach only what that person is allowed to access, and each invocation is recorded in system tables for audit.

Can an AI gateway govern MCP servers and tool access?

Yes. Left ungoverned, an agent with access to a Model Context Protocol server can call any tool that server exposes, often with a shared credential and no record of who did what. An AI gateway closes that gap: it registers each MCP server as a managed object, decides which tools are visible, authorizes every call against the caller's identity, and logs the result. For an enterprise the question is not whether tools are useful, it is whether tool use is governed like the rest of the data estate.

What are MCP servers and tool access?

The Model Context Protocol (MCP) is an open standard for connecting AI agents to tools and data through a consistent interface. An MCP server publishes a set of tools, such as searching a repository, querying an API, or filing a ticket, that an agent can call. Tool access is the authorization question underneath: which agents, acting for which users, may invoke which tools, and under what conditions. Governing that is what separates a demo from a production agent.

Key capabilities to evaluate

Capability	Why it matters
Registered as governed objects	MCP servers and tools should be managed assets with owners and permissions, not ad-hoc endpoints scattered across teams.
Fine-grained tool filtering	You should be able to expose only the specific tools an agent needs, not a server's entire surface.
Identity-based authorization	Calls should run as the requesting user so a tool reaches only what that person may access.
Contextual approval	Sensitive actions should be deniable or gated on approval based on the caller and the request content.
Full audit trail	Every tool call, its name, arguments, result, user, and allow or deny decision, should be recorded for security review.
Central routing and limits	One control plane should route calls and apply rate limits and budgets across servers.

How Databricks approaches this with Unity Gateway

Unity Gateway, generally available and built on Unity Catalog, governs tools the same way it governs data and models.

• Everything is a securable. MCP servers are registered as Unity Catalog services with three-level names (catalog.schema.service). The functions agents call as tools, the connections used to reach external APIs, and the agents themselves are also Unity Catalog objects. You grant and revoke access with the EXECUTE privilege and attribute-based policies, exactly as for tables. See how AI governance works on Databricks.
• Tool filtering. When you register an MCP service, you list which tools are exposed by name pattern, so an agent sees only the tools it should. Managed connections hold the credentials, so tokens are never handed to the agent.
• Contextual policies (Beta). Service policies, currently in Beta, are defined as Unity Catalog functions and evaluate each tool call before and after it reaches the server, allowing, denying, or requiring approval based on the caller and the request. Decisions are enforced in real time.
• Runs as the user. Calls execute on behalf of the requesting user, so a tool can reach only the data that user is entitled to, and every action is attributed to a real identity rather than a shared service account.
• Audited by default. Control-plane events and every tool call land in system tables such as system.access.audit and the gateway usage tables, capturing the tool, its arguments, the result, and whether the call was allowed or denied. See connect agents to tools with MCP and the blog Stop rogue AI: how Unity Catalog secures agent actions.

FAQs

What is MCP governance?

It is applying access control, filtering, approval, and audit to the tools an AI agent can call through MCP servers. On Databricks, MCP servers and tools are Unity Catalog securables, so the same permission model and audit trail that cover tables also cover tool use.

Can I limit which tools an agent can call?

Yes. Tool filtering exposes only selected tools from a server by name pattern, and EXECUTE grants control who can invoke the server at all. Service policies (in Beta) can further allow, deny, or require approval for individual calls.

How are external, third-party MCP servers governed?

Register the external server as a Unity Catalog service reached through a managed connection. The gateway authorizes each call, applies tool filtering and policies, forwards the request with managed credentials, and logs the invocation. See connecting agents to external MCP servers securely.

Is every tool call auditable?

Yes. Tool invocations are recorded in system tables with the tool name, arguments, result, and the identity that made the call, giving security teams one queryable record across agents and servers.