Restricting a Databricks MCP Server to Approved Unity Catalog Catalogs and Schemas

Start with an allowlist, not a grant list

A Databricks MCP server gives agents and coding assistants a tool interface to enterprise data. If nothing scopes that interface, an agent can discover and query catalogs and schemas well beyond its purpose. The first step is a decision, not a configuration: which catalogs and schemas may this agent reach, and for what purpose?

Write the answer as an explicit, organization-defined scope. This follows the pattern in NIST SP 800-53 Rev. 5, where access to data repositories containing organization-defined information is restricted and the scope is a parameter the organization assigns. NIST SP 800-53 is a control framework, not a legal requirement, but the pattern is useful for structuring the work.

Express each entry as attributes that can be evaluated: the subject (the agent or service identity), the object (catalog and schema), and the requested operation (the tool call). NIST describes attribute-based access control in similar terms, as authorization determined by evaluating attributes of the subject, object and operation against policy. Applying this to MCP tool calls is a design choice, but it yields an allowlist you can test.

Assign a named owner for the list, an approval path and change control. A written policy should exist alongside the technical control, because assessors look for enforcement of approved authorizations under a stated access control policy.

Layer one: least privilege at the Databricks layer

Platform-native controls set the baseline for what an identity can reach. Three apply here: Unity Catalog grants, service principal scoping, and the MCP server's own configuration.

Give each MCP server deployment a dedicated service principal rather than a shared or personal identity. Grant it access only to the catalogs and schemas on the allowlist, and nothing at a broader level. If the design uses end-user identity instead, confirm that the maximum reach of any user who can call the server is still acceptable, since the agent inherits it. Where tables in approved schemas contain sensitive fields, row-level and column-level controls reduce what a permitted query can return.

Then constrain the server configuration so it exposes only the tools and data objects the use case needs. A smaller tool surface means fewer paths to unapproved data.

These controls have a limit. They define what an identity can reach, not what an agent may touch on each tool call. A single approved identity can still serve many agent purposes, and grants alone produce no record of what was requested, allowed or blocked. That gap is what the second layer addresses.

Failure modes to test for

These are failure modes to treat as hypotheses and test in your own environment. Each maps to a mitigation in one of the two layers.

• Overly broad service principal grants: The identity can read more than the allowlist. Mitigate by removing broad grants and granting only on approved catalogs and schemas.
• Schema discovery tools: Listing tools reveal names of unapproved catalogs or schemas. Mitigate by filtering tool results against the allowlist and trimming the exposed tool set.
• Fully qualified table names in generated SQL: An agent writes a query that names an object outside its scope. Mitigate by inspecting tool-call arguments and blocking out-of-scope references.
• Grant drift after changes: A new grant or tool definition widens reach silently. Mitigate by re-running boundary tests after every change.
• Sensitive fields inside approved schemas: Permitted queries return data the agent should not see. Mitigate with column-level controls and redaction of results.

Layer two: enforce policy on MCP tool calls

Runtime enforcement sits in the path between the agent and the MCP server. It evaluates each tool call against the allowlist before the call executes, and evaluates the result before it returns to the agent.

On arguments, the policy checks which catalog, schema or fully qualified object a call references. A call inside the allowlist proceeds. A call outside it is blocked, or escalated for human approval where your process requires that. On results, the policy checks that returned names and rows stay in scope, and redacts fields that should not leave the boundary. Rate limits on repeated out-of-scope attempts can also be part of the policy.

The decision should be deterministic. The same call under the same policy should produce the same outcome, so that it can be tested like any other control. NIST describes policy filters that validate schema structures, and the same idea applies here: check structured arguments and results against a defined approved scope.

Trussed enforces policy in the execution path across agents, tools, MCP servers and coding assistants, with decisions of allow, redact, block, rate limit or escalate for human approval at the level of individual tool calls. Enforcement happens at runtime, not review after the fact, and it generates audit-ready evidence. It can be deployed self-managed in the customer cloud, with configurable retention and data residency. The approach in this guide does not depend on any one product, but the enforcement point has to sit in the path to be effective.

Decide which layer is authoritative

Two layers can conflict if their roles are unclear. NIST SP 800-162 notes that the distribution and orchestration of access control mechanisms must be predetermined to avoid conflicts and weaknesses in object protection.

A workable split is this. Unity Catalog grants are the outer limit: nothing outside the allowlist should be reachable by the identity at all. Runtime policy is the narrower, per-call decision inside that limit, based on purpose, arguments and results. If runtime policy is misconfigured, grants still contain the damage. If a grant is widened by mistake, runtime policy still blocks out-of-scope calls. Record this division in the written policy so reviewers know which layer answers which question.