The Databricks MCP server lets Claude, Cursor, and AI agents run NL→SQL with Genie, call Unity Catalog functions, and search your lakehouse. Here's the official setup, the real blast-radius risks, and how to govern it with DLP-grade redaction at the MCP layer.
The Databricks MCP server is a Model Context Protocol implementation that exposes your lakehouse as a standardized set of tools to AI agents. Databricks provides managed servers out of the box — a Genie server for natural-language-to-SQL across your data, Unity Catalog Functions servers that let an agent invoke predefined SQL queries and tools, and Vector Search (AI Search) servers for semantic retrieval over indexed documents — and lets you host custom MCP servers on Databricks Apps for anything beyond that.
See the official Databricks managed MCP documentation for the current server list, endpoint patterns, and OAuth scopes. Each managed server has its own endpoint — Genie at /api/2.0/mcp/genie/{genie_space_id}, UC functions at /api/2.0/mcp/functions/{catalog}/{schema}/{function_name}, vector search at /api/2.0/mcp/vector-search/{catalog}/{schema}/{index_name} — and an external agent connects by registering that endpoint and authenticating with an OAuth token on behalf of the user.
From the analyst's perspective, the AI agent suddenly understands their lakehouse — ask a question in English, get an answer computed over real Delta tables. From the security perspective, the AI agent now has query access to every row that principal can reach across the catalog.
That's the value. It's also where data-security teams need a control layer.
Wire the Databricks MCP server into an agent and the lakehouse starts answering questions on its own. Acting as the authorizing principal, Claude can reach Genie spaces, Unity Catalog functions, and your Delta tables without anyone opening a notebook. The concrete wins:
Every one of those actions runs through Databricks' own APIs and Unity Catalog's permission model — which is what makes it genuinely useful, and exactly why the regulated data those queries return needs an inspection layer in the tool-call path.
The risks fall into four categories that every healthcare and regulated team running Databricks should price into the deployment.
1. Genie NL→SQL has enormous blast radius. Unlike a single-object read, one Genie prompt can be translated into a query that scans and joins across the entire lakehouse. There is no WHERE not_regulated = true clause — Genie returns whatever the generated SQL selects, and the raw result rows flow straight to the model. A vague question can pull far more sensitive data than the user intended to expose.
2. Unity Catalog grants are usually broad. In practice, analysts and service principals are granted catalog- or schema-level access so they can do their jobs. Unity Catalog enforces those grants faithfully — but if the principal can read a schema full of PHI, so can the agent acting on its behalf. The MCP server honors permissions; it doesn't narrow them.
3. PHI, PII, and financial data sit in Delta tables and get returned raw. Lakehouses are where regulated data concentrates — patient records, claims, transactions, card data, customer identifiers. When Genie or a UC function returns those rows, the values land in the AI model's context window in the clear. Nothing inspects them on the way out.
4. Row filters and column masks don't follow the data to an external agent. Unity Catalog supports row filters and column masks, and they're valuable — but they're scoped to the principal's read path inside Databricks. They don't redact what flows out over MCP to an external agent and into a third-party model's context. The moment the result set leaves the lakehouse boundary, those controls are behind it, not in front of the model.
The traditional DLP a company already runs — at the network edge, on the file share, inside a SaaS rule engine — does not sit in the MCP path. The Genie or function response goes straight from the lakehouse into the AI agent's context window. That reach is exactly why each agent's access and queries against Databricks must be governed: controlled (what it can query and do), the sensitive data in the result rows protected, and every query audited. That is where Strac Databricks MCP DLP lives.
Strac's Databricks MCP DLP is the governance layer that sits between AI agents and the Databricks MCP server. Strac governs every tool call: it sees exactly what each agent queries across the lakehouse, controls its actions (allow, block, or require approval on broad scans, high-risk exports, and write queries), protects the sensitive data in the returned rows by redacting, masking, tokenizing, or vaulting it — down to the column level — and proves it by logging every query as audit evidence. Non-sensitive, in-policy queries flow through untouched.
What this looks like in practice:
The same Strac MCP DLP layer covers other data-platform surfaces — Snowflake MCP, BigQuery MCP, and Postgres MCP — one control plane across every place AI agents query your regulated data. For the full picture of why this matters as data moves into models, see MCP DLP and AI DLP.
MCP DLP protects the AI-agent surface. Strac's native Databricks DLP protects the data-at-rest surface — the same lakehouse, but discovered and classified where the regulated data actually lives. Most regulated teams run both: native DSPM to know what sensitive data sits in which Delta tables and cloud storage, MCP DLP to govern what agents do with it. Together they cover every path regulated data can take into and out of Databricks.
What Strac's native Databricks DLP includes:
For the broader integration catalog — every SaaS, cloud, browser, and endpoint surface Strac covers — see strac.io/integrations.
The screenshot below shows Strac's MCP DLP redacting sensitive data from a real Claude session — patient identifiers, customer emails, and card numbers tokenized inline before the model received the prompt. The same inspection pattern runs on every Genie query, UC function call, and vector search routed through Strac.
Setup is agentless and takes under 10 minutes.
.webp)
json
"mcpServers": {
"databricks": {
"url": "https://mcp.strac.io/databricks",
"auth": { "type": "bearer", "token": "<your-strac-token>" }
}
}
For Cursor, OpenAI Agents, and custom agents — same endpoint, same auth.The same Strac Databricks MCP DLP control produces evidence mapped to every major compliance framework. For lakehouses holding patient and claims data, HIPAA is the headline — Strac puts a redaction and accounting-of-disclosures layer between PHI in Delta tables and any external model.
For the broader AI-data-governance program this sits inside, see DSPM for AI.
The Databricks MCP server is a Model Context Protocol implementation that lets AI agents (Claude, Cursor, ChatGPT, custom agents) query your lakehouse via standardized tool calls. Databricks ships managed servers for Genie (natural-language-to-SQL), Unity Catalog functions, and Vector Search, plus the option to host custom MCP servers on Databricks Apps. It's how an AI assistant gets contextual access to every Delta table the authorizing principal can read.
Genie and the Databricks Assistant are agents that run inside Databricks — they translate natural language to SQL and answer questions within Databricks' own boundary and UI. The Databricks MCP server points the other direction: it exposes the lakehouse (including Genie itself) to external agents like Claude, Cursor, and custom agents over the open Model Context Protocol, so the AI client your team already uses can query your data. Genie keeps the interaction inside Databricks' guardrails; MCP lets an external agent reach in, and the result rows leave those guardrails the moment they return to the client. That hand-off is exactly where Strac Databricks MCP DLP inspects, masks, and redacts.
By itself, no — not without an additional DLP layer. The Databricks MCP server enforces Unity Catalog permissions, but it returns whatever the principal can read, and analysts are usually granted broad schema-level access. A single Genie query can pull thousands of rows of PHI, PII, or card data straight into the model's context. For regulated use, you need an MCP-layer control like Strac Databricks MCP DLP that inspects and masks every result row before content reaches the AI model.
They protect it inside Databricks, for the principal's own read path. Row filters and column masks are scoped to how that principal sees data in the lakehouse — they don't redact what flows out over MCP to an external agent and into a third-party model's context window. The moment the result set crosses the lakehouse boundary, those controls are behind it. Strac sits in the tool-call path itself, so masking follows the data all the way to the model.
Databricks' built-in protections operate at the catalog and policy layer — Unity Catalog grants, row filters, column masks, lineage. None of those inspect the payload that leaves over MCP to an external model. Strac is purpose-built for the MCP layer: it intercepts every tool call before the result reaches the AI agent's context window, with detection breadth (PII / PHI / PCI / financial / secrets / OCR-in-documents) and column-level masking that goes beyond static catalog policies.
Yes. Strac exposes a standard MCP gateway endpoint, so any MCP-aware AI client routes its Databricks tool calls through it with one configuration change. No SDK changes, no notebook changes, no application code changes.
PII (SSN, driver's license, passport, address, phone, email), PHI (clinical notes, MRN co-occurrence, ICD-10 codes adjacent to identifiers, lab values), PCI (full and partial card numbers via Luhn check), financial identifiers (account and routing numbers, balances), credentials (API keys, cloud access keys, OAuth tokens, JWTs, SSH keys — 48+ patterns), and custom detectors trained on your Unity Catalog classifications. Detection runs across structured columns, free-text fields, vector-search document hits, and files (OCR).
Under 10 minutes for the first workspace. OAuth Strac into Databricks, swap the Strac MCP gateway endpoint into your AI client's config, pick a policy template, done. No agents to install, no Unity Catalog re-permissioning, no notebook changes.
Masked and redacted values are replaced inline in the result rows. Optionally, sensitive values can be vaulted — replaced with a short-lived retrieval link that only authorized users can resolve, so the original is retrievable for legitimate use without ever entering the AI context. Vaulted data is stored encrypted at rest in your Strac tenant; you control retention.
Yes. Strac produces a per-call audit log: timestamp, AI client identity, principal, server invoked (Genie / functions / vector search), query or function, tables and columns touched, data classes detected, redactions and masks applied, vault references, disposition. The log is queryable in the Strac console and exportable to your SIEM. This is the evidence trail HIPAA, SOC 2, PCI, and GDPR auditors will ask about for AI-agent activity against your lakehouse.
The Databricks MCP server is rapidly becoming the way AI agents read into the lakehouse — and the lakehouse is where the most concentrated PHI, PII, and financial data your organization has actually lives. Genie's natural-language-to-SQL gives an agent enormous reach across that data, Unity Catalog grants are usually broad, and row filters and column masks stop at the lakehouse boundary. Running Databricks MCP in 2026 without an MCP-layer DLP control is not a question of if the first incident reaches your security team; it's when.
Strac Databricks MCP DLP gives you the governance layer, the column-level masking, the audit evidence, and the framework-agnostic compliance coverage so healthcare and regulated teams can let analysts use Databricks with Claude, Cursor, ChatGPT, and any future AI client without making each one a separate security exception.
If you are running — or about to run — Databricks MCP in production, book a 30-minute demo. We'll walk through the architecture, the policy templates, and a deployment plan for your specific lakehouse, Genie spaces, and AI clients.
For the broader MCP DLP control plane across every data surface, see the MCP DLP pillar. For more data-platform deep dives: Snowflake MCP, BigQuery MCP, Postgres MCP.
.avif){kind=icon}
.gif)
