Feature request: Classification-aware masking for MCP SQL results

[karthik-raparthi]

Problem

execute_sql / execute_sql_multi send SQL straight to a Databricks SQL Warehouse with no awareness of column sensitivity. There also does not appear to be a signal in the current toolset (for example, get_table_stats_and_schema) about which columns are classified or tagged as PII/SPI. That means an agent has no reliable way to reason about whether it should select a column before writing a query, and nothing at the MCP/tool layer discourages or blocks SELECT * on a sensitive table.

Unity Catalog now has GA support for ABAC (row filter + column mask policies), Governed Tags, and automated Data Classification, which feels like the right long-term primitive for this. However, ABAC/persona-based governance takes time to design well: teams need to agree on personas, map users and groups, validate classifications, define governed tags, write masking functions, attach policies at the right catalog/schema/table scope, and test exceptions.

MCP setups also commonly authenticate with a single DATABRICKS_TOKEN or DATABRICKS_CONFIG_PROFILE shared across many human users and agent sessions. If that identity is broadly privileged for convenience, native per-user ABAC policies may not reflect the actual human's entitlements; the agent effectively inherits the connection credential's privileges.

Proposal

Add optional, classification-aware safety behavior for SQL tools that reuses Unity Catalog governed tags and/or automated Data Classification metadata rather than inventing a separate classification system.

The intended flow would be:

1. An AI coding tool such as Cursor, Claude Code, Copilot, etc. asks to run SQL through execute_sql / execute_sql_multi.
2. Before execution, or before returning results, the MCP layer inspects Unity Catalog classification/tag metadata for the referenced tables and columns.
3. Columns classified as sensitive are handled according to policy: block, redact, mask, or deterministically hash depending on the use case and persona.
4. Only the safe result set is returned to the AI tool.

Possible layers:

1. Preventive: classification/tag-aware SQL handling. Before execution, look up relevant metadata from information_schema.column_tags and/or Data Classification results for referenced tables. Block or rewrite SELECT * on tables with sensitive columns. Optionally auto-mask or hash tagged columns unless the caller matches an allow-listed persona or attribute. This should fail closed if tag/classification metadata cannot be loaded.
2. Detective: result scanning. Scan formatted results for common sensitive patterns such as email, SSN, phone numbers, and credit card numbers before returning data to the agent. This would catch leaks that slip past column-level controls through views, joins, computed expressions, or incomplete tagging.
3. Agent-visible sensitivity context. Annotate schema/statistics tools such as get_table_stats_and_schema with the governed tags/classification signals that ABAC policies use, so the agent can avoid unsafe query plans before execution.
4. Persona-aware masking. Optionally allow a persona or attribute context on the MCP call that is separate from the warehouse credential's own grants. This would make masking decisions based on the intended user/persona rather than only on the shared service credential.

Why this matters for agent workflows

ABAC and persona-based governance are the right enterprise direction, but they are not always complete before teams start using AI coding tools against Databricks. Agents can generate broad SQL quickly, often through shared workspace credentials or automation profiles. Even when the underlying platform supports ABAC, the agent still needs metadata awareness and guardrails so it can avoid unsafe queries before execution.

A classification-aware MCP layer would help bridge that rollout gap:

• It gives agents visibility into sensitive columns before writing SQL.
• It reduces accidental SELECT * exposure while ABAC/persona models are still being implemented.
• It provides defense-in-depth for shared-credential or service-principal MCP deployments.
• It encourages native Unity Catalog ABAC adoption by reusing the same governed tags/classification metadata instead of creating a parallel policy model.

Why not rely only on native ABAC?

Native ABAC should remain the source of truth, and this proposal is meant to complement it rather than replace it. The concern is that governed tags, classification, personas, and policies may roll out gradually across an estate, while MCP/agent workflows often use shared credentials. In those cases, the assistant can accidentally become a broader access path than intended, especially before persona mappings and ABAC policies are fully designed, deployed, and validated.

A safe-by-default MCP layer would reduce accidental exposure while still encouraging customers to adopt the native Unity Catalog ABAC model.

Scope

This likely touches:

• execute_sql
• execute_sql_multi
• get_table_stats_and_schema
• The shared SQL execution path in databricks-tools-core, if that is the better abstraction boundary
• Possibly a databricks-skills entry documenting recommended ABAC + classification-safe SQL patterns for agents

I noticed in CONTRIBUTING.md that external contributions are not currently accepted, so I am filing this as a feature request rather than opening a PR. Happy to provide more detail on the preventive/detective pattern if a design writeup would be useful.

[karthik-raparthi]

Design detail: scope vs. redaction, and the unclassified-schema default

One more note for context: a variation of this preventive + detective pattern (classification-driven scope, tag-driven column protection, fail-closed on unclassified scope) has been running reliably in a production MCP deployment, so this is not just theoretical. The trade-off is that block unclassified scope can occasionally block a genuinely non-PII schema until governance classifies it, but that is a much safer default than silent passthrough.

A few refinements from having run this pattern in production, in case they are useful for scoping.

1. Treat scope and redaction as two distinct metadata signals

It is tempting to drive everything off column_tags, but that conflates two questions:

• Scope: was this schema/table actually scanned by Data Classification?
• Redaction: which specific columns should be masked, hashed, or redacted?

Scope is better read from Data Classification results, because classification is effectively enabled/run per schema. Redaction is column-level and comes from the applied governed tags.

Keeping these separate matters because a schema that was manually tagged but never classified is different from one that was scanned and found clean, which is different again from one that was never scanned at all. Inferring scope from tag presence collapses those cases and can create silent gaps.

2. Define the unclassified-schema default explicitly

The proposal covers what to do with sensitive columns, but the highest-risk case is a table whose schema was never scanned. That should be a first-class policy decision (block, warn, or passthrough), not an implicit passthrough.

Recommendation: block fail-closed. "Governance has not scanned this" is not the same as "this has no PII." Letting an unscanned scope execute with only detective result scanning is exactly the kind of quiet under-protection a two-layer model is meant to prevent. A safer default is to block and point the user toward the governance action: get the schema classified.

3. Consider persona-aware masking as a later phase

Layers 1-3 are tractable and safe with a shared credential. Layer 4 is different: allowing the MCP call to assert a persona separate from the connection credential's own grants means the client is effectively asserting its own entitlement.

Without a server-side trust anchor that verifies the asserted persona against a trusted identity, that can become a privilege-escalation path. It may be worth treating persona-aware masking as future work that requires an identity anchor, so it does not block the more immediately shippable classification-aware layers.

4. Operational questions to answer

• Metadata caching: tag/classification lookups should be TTL-cached per catalog with a manual refresh path, otherwise every query pays a metadata round-trip on the hot path.
• Cross-catalog / multi-part names: for queries referencing multiple catalogs, classification metadata should be resolved from the referenced object name rather than a single global default. A global default can silently look up the wrong catalog's tags.
• Rewrite contract: decide up front between deterministic hashing and redaction/nulling. Deterministic hashing preserves joins and group-bys, while redaction is safer but makes the result set less analytically useful.

The main distinction I would emphasize is: use Data Classification results to decide whether an object is in governed scope, then use governed tags to decide how specific columns should be protected.

Happy to share a more detailed writeup of the two-layer design if it would help scope the work.