Use Kiri inside Databricks AI Assistants

Databricks AI assistants are good at writing SQL and explaining tables. They’re not good at knowing what’s governed about those tables — that a column is restricted PII, that a table has an owner, that a metric has a canonical definition. That knowledge lives in your Kirimana contracts. This page wires the Kirimana MCP server so a Databricks assistant can read your contracts, classifications, and lineage as it works, and ground its answers in the governance you’ve already declared.

Scope, stated plainly: this is a read and context integration. The Kirimana MCP server gives the assistant governance metadata to read. Separately, the AI query gate (the evaluate_query MCP tool) returns an allow / gated / forbidden decision a cooperating assistant can call before it runs SQL — that decision, and the audit, ship today. What is not shipped is forced, engine-level enforcement: Kirimana isn’t in the Databricks execution path, so it can’t stop a query the assistant chooses to run anyway. Enforcement here is cooperative, not mandatory.

What the assistant gains

Once the MCP server is wired in, a Databricks assistant can pull the same read-only catalog surface any MCP client sees:

• Contracts — the full ODCS contract for a table: schema, custom properties, governance. The authoritative “what does Kirimana know about this thing?”.
• Classifications — the sensitivity of a contract or a specific column (public / internal / confidential / restricted), so the assistant knows a field is restricted before it puts it in an answer.
• Lineage — immediate upstream and downstream edges for an asset, so “where does this table come from?” is answerable from the catalog rather than guessed from names.
• PII metadata — every column flagged as PII, for the assistant to warn on or avoid.
• KPI records and AI policy — the exec-facing KPI lineage and the kiri.ai_policy block for a contract.

The assistant reads this. It composes better answers because it can see the governance. It does not — and cannot, through this integration — enforce anything on the Spark engine.

Wire the MCP server

The wiring is a .mcp.json server entry that launches the Kirimana MCP server over stdio, exactly as for any other MCP client, with the Databricks assistant as the host:

{
  "mcpServers": {
    "kirimana": {
      "command": "uv",
      "args": ["run", "kiri-mcp"],
      "cwd": "/absolute/path/to/your/kirimana/repo",
      "env": {
        "KIRIMANA_PROJECT_DIR": "examples/hello-dynamics",
        "KIRIMANA_MCP_SUBJECT": "alice@acme.com",
        "KIRIMANA_MCP_GROUPS": "acme/platform-team"
      }
    }
  }
}

• KIRIMANA_PROJECT_DIR points at the project whose kiri.yml and contracts you want the assistant to read.
• KIRIMANA_MCP_SUBJECT and KIRIMANA_MCP_GROUPS carry the caller’s identity — the assistant reads as that identity, and every read is logged under it.

The stdio transport has no auth header, so the host process supplies identity. Set both env vars in real use; the host is the trust boundary.

Read-only by construction

The server exposes resources and tools that describe state — nothing that mutates it. Contract edits and applies live on the CLI, never on MCP. So the worst a misbehaving Databricks assistant can do through this integration is read metadata it’s already entitled to read — and every one of those reads is recorded.

RBAC still applies. If the project has a kiri_rbac.yml and the caller’s subject is unset, the server safe-defaults to DENY on every call — an unclaimed identity reads nothing. When the subject is set, the assistant gets exactly the calling user’s rights, never elevated ones. Scope KIRIMANA_MCP_GROUPS to the minimum role the user needs.

Audit trail

Every read and tool-call the assistant makes appends one JSONL entry to the same audit stream the CLI writes, under <project>/.kiri/audit/, each entry carrying the acting identity, the surface read, a status, and a trace id. Response bodies aren’t stored — only their size — so the log records that the assistant read a contract, and under whose identity, without becoming a shadow copy of the contract itself.

Override the audit path when the project directory is read-only (a common case for shared or containerised hosts):

export KIRIMANA_MCP_AUDIT_PATH=/var/log/kirimana/mcp.jsonl

Tail that file alongside your other Databricks audit streams; it follows the same JSONL convention, so it drops into the same aggregator.

What this is not

It’s worth being blunt about the boundary, because it’s easy to over-read:

• It does not intercept or gate queries the assistant runs against the warehouse. If an assistant writes and executes SQL, that SQL runs under Databricks’ own permissions, not Kirimana’s — Kirimana isn’t in the query path.
• It does not enforce contract policy at query time inside the engine. Enforcement of that kind is not shipped in v1.0.0-beta.1.
• It does not modify anything in the catalog or the workspace.

What it does is give the assistant the governance context to be smarter — to know a column is restricted, to know who owns a table, to see the lineage — and to record, in an audit trail you own, every governance read it made. Combine it with Unity Catalog’s own access controls for enforcement; use Kirimana for the context and the audit.

Try it

From a wired Databricks assistant:

• “What’s the classification of gold.dim_customer.email, and who owns the table?” — the assistant reads kirimana://classification/gold_dim_customer.email and the contract, and answers from governance rather than inference.
• “Show the upstream lineage for the revenue fact.” — it attaches the catalog://lineage/… resource and cites the edges.

Both reads land in the audit log under the configured identity — the same forensic record you’d get from the CLI.