Databricks

Reusable DTwo policies for Databricks MCP servers — the official Databricks managed servers that the Claude Databricks connector uses (Genie, Databricks SQL, AI Search, UC Functions), plus the deprecated databrickslabs/mcp labs server and the community stdio servers (JustTryAI/databricks-mcp-server, RafaelCartenet/mcp-databricks-server). The MCP surface is small but potent: a handful of fixed snake_case verbs (genie_ask, execute_sql, execute_sql_read_only, poll_sql_result, genie_poll_response) plus dynamic {CATALOG}__{SCHEMA}__{NAME} tools for AI Search indexes and UC functions, and — on the community servers — cluster/job control (create_cluster, terminate_cluster, run_job, export_notebook). Its risk profile is dominated by the SQL string inside one argument: the managed execute_sql is explicitly read and write, so INSERT/UPDATE/DELETE/DROP/GRANT are irreversible data-plane and permission changes, the lakehouse routinely holds PII/PHI/cardholder tables that egress in the async poll responses (not the submit call), community PAT auth bypasses per-user Unity Catalog identity entirely, and system.ai proxy services can turn Databricks into a gateway to other SaaS apps. Policies here therefore pair tool-name matching with query-text and response-text inspection.

Available policies

Tool naming on the DTwo gateway

DTwo prefixes tool names with the MCP server name configured on the gateway. A Databricks SQL server registered as databricks-sql will surface tools like databricks-sql-execute_sql, while one registered as dbx will surface dbx-execute_sql. These policies match on the suffix / stem (execute_sql, execute_sql_read_only, poll_sql_result, etc.) so they stay portable across naming conventions and across the three different servers that each expose an execute_sql-ish tool with different auth semantics — but you should always confirm the exact tool name your gateway sends using the dump-input debug technique before deploying. The single-space Genie invoke tool name and the genie_ask question parameter name are unverified in Databricks docs (see each policy's Known limitations); the dynamic {CATALOG}__{SCHEMA}__{NAME} AI Search / UC-function tools have no stable canonical name and need per-deployment enumeration or the allowlist pin.

Identity claims

The identity-gated policies (fence-sensitive-schemas, role-gate-compute-ops) read input.subject.claims.groups with placeholder group names (e.g. data-privacy, and the platform-engineering group used by role-gate-compute-ops). Replace these with your own IdP group names at import time. Missing claims fail closed for grants (no group → not exempt). The remaining policies are single-purpose and require no IdP claims.

Contributing

To add a Databricks policy:

1. Create apps/databricks/<policy-slug>/ with policy.md and a tests.yaml test file.
2. Add a row to the table above.
3. Declare apps: ["databricks"] in the policy frontmatter, plus any industry / bundle slugs that apply.
4. If the policy fits a framework or thematic bundle, link to it from the matching landing page under bundles/.
5. Run pnpm manifest from the repo root.

See CONTRIBUTING.md for the full process.