# Official sources

Use this reference only when you need source grounding for Databricks Unity Catalog or Azure service behavior, or the detailed source list.

## Databricks documentation

Use these as starting points, not as proof of the user's live workspace state:
- https://docs.databricks.com/en/data-governance/unity-catalog/index.html
- https://docs.databricks.com/en/data-governance/unity-catalog/manage-privileges/privileges.html
- https://docs.databricks.com/en/admin/users-groups/service-principals.html
- https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/

## Grounding rule

Official documentation explains Databricks Unity Catalog service behavior. It does not prove the user's current workspace, metastore, catalog configuration, grant assignments, or operational state. Prefer read-only workspace MCP or CLI evidence, repository evidence (Terraform/IaC), or sanitized user-provided evidence for current-state claims.

## Current documentation refresh (2026-06-17)

Service facts from official docs:

**Three-level namespace:** Unity Catalog organizes data assets in a metastore → catalog → schema → table/view/volume/function hierarchy. A single metastore is attached per Azure region per account.

**GRANT model:** USE CATALOG and USE SCHEMA grant namespace traversal but no data access on their own. SELECT and MODIFY on tables/views require the parent USE CATALOG and USE SCHEMA grants. ALL PRIVILEGES on a securable does not include EXTERNAL USE SCHEMA or MANAGE; those must be granted explicitly.

**Least-privilege pattern:** Prefer schema-scoped grants (CREATE TABLE, CREATE VOLUME, CREATE FUNCTION at the schema level) over catalog-wide or ALL PRIVILEGES grants.

**Identity federation:** Use account groups (not workspace-local groups) for production. Assign grants to groups, not to individual users or service principals directly where avoidable. Microsoft Entra ID managed service principals are the preferred automation identity.

**Admin separation:** Account admin, workspace admin, and metastore admin are distinct roles with separate blast radii. Do not conflate them.

**Service principal posture:** Production automated workloads must run as SERVICE PRINCIPALs (Microsoft Entra ID), not interactive users. Interactive user tokens expire and carry broader implicit access.

**Workspace-catalog binding:** Workspaces can be bound to catalogs in read-only or read-write mode. Validate binding intent before assigning broad catalog-level grants.

**Audit:** Unity Catalog system tables (`system.access.audit`, `system.access.column_lineage`, `system.access.table_lineage`) provide audit trails. Confirm system schema is enabled on the metastore.

**Certification reference:** DP-750 (Azure Databricks Data Engineer Associate) covers Unity Catalog governance fundamentals.

Review implications:
- Do not approve broad catalog or ALL PRIVILEGES grants from intent alone. Require scope justification, group-based assignment, service principal identity, and metastore admin sign-off.
- Documentation cannot prove the user's actual metastore, workspace binding, or live grant assignments.

# Safety checklist

Use this reference before privileged, destructive, compliance-impacting, or production-impacting recommendations.

## Non-negotiables

- Never ask users to paste access tokens, service principal secrets, client secrets, connection strings, storage account keys, or customer identifiers into chat.
- Use read-only workspace MCP or IaC repository evidence for live state when available; otherwise use sanitized user evidence or official documentation and label the evidence level.
- Do not invent metastore IDs, catalog names, workspace URLs, principal IDs, grant assignments, or live configuration state.
- Require explicit user approval before privileged, destructive, compliance-impacting, or production-impacting recommendations.
- Use current official Databricks and Microsoft Learn documentation for service behavior when the answer depends on platform details.
- Keep remediation least-privilege, reversible, and scoped to the requested workspace or catalog boundary.
- Static review only: never execute GRANT, REVOKE, CREATE, DROP, or ALTER against a live workspace. Production grant/role/policy/cluster changes are live-guard gated (escalate).

## Stress checks

- What grants can expose data beyond the intended consumer group?
- What admin role or account-level privilege can be escalated?
- What interactive-user pattern breaks production automation or compliance posture?
- What missing parent USE grant silently fails or silently expands access?
- What audit evidence is missing from system tables?
- What rollback or validation path is unproven?

## Evidence labels

Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live Databricks workspace state, grant assignments, or metastore configuration.

# Workflow and output contract

Use this reference only when performing the full governance review, incident triage, implementation guidance, or production-readiness pass.

## Review domains

Check these areas before giving a verdict:

- Namespace scope: metastore, catalog, schema, target securable, and intended operations
- Grant model: privilege type, parent USE grants present, group-based vs individual assignment
- Identity: account groups vs workspace-local groups, service principal vs interactive user
- Admin separation: account admin, workspace admin, metastore admin roles and their blast radii
- Workspace-catalog binding: read-only vs full, correct binding for target workload
- Least-privilege: schema-scoped grants preferred; ALL PRIVILEGES exclusions (EXTERNAL USE SCHEMA, MANAGE)
- Audit: system tables enabled, lineage and access logging configured
- Production posture: service principal identity, token lifecycle, Entra ID federation

## Safe workflow

1. **Frame scope**
   - Workspace/metastore/catalog/schema/environment:
   - Business criticality and owner:
   - Data classification and compliance driver:
   - Required outcome:
   - Explicit non-goals:
2. **Collect evidence**
   - Prefer read-only workspace MCP evidence, repository IaC (Terraform), or sanitized user-provided SQL/JSON for current-state claims.
   - Otherwise inspect official documentation.
   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
3. **Stress-test risk**
   - What grants expose data beyond the intended consumer group?
   - What can escalate privilege in the metastore or account?
   - What interactive-user patterns break production automation?
   - What audit evidence is missing?
4. **Recommend the smallest safe action**
   - Prefer narrow grants, group-based assignment, staged rollout, and rollback.
   - If the safest action is to stop and gather evidence, say that plainly.
   - Production grant/policy changes are live-guard gated (escalate).

## Output contract

Return this structure:

```markdown
# Databricks Unity Catalog Governance Review: <scope>
## Executive verdict
- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
- Biggest risk:
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Findings
| Severity | Finding | Evidence | Why it matters | Minimum safe action |
|---|---|---|---|---|
## Recommended actions
1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
## Validation
- Commands or checks:
- Expected result:
## Residual risk
- <risk or explicit none>
```