Databricks Unity Catalog permissions are easiest to manage when access is designed by role, resource, and operating cadence rather than granted one request at a time. This guide provides a practical access-control matrix for analysts, engineers, data scientists, and AI applications, plus a recurring review process for ownership, inheritance, service principals, and denied-access issues.
Overview
Unity Catalog provides a governance layer for data and AI assets across Databricks workspaces. The exact capabilities available to an account can depend on workspace configuration, cloud, identity setup, and product version, so treat this article as a planning framework and confirm current privilege names and supported features in your environment before applying changes.
A useful permissions model separates four concerns:
- Identity: Users, groups, and service principals should be managed through the organization’s identity provider where possible.
- Scope: Access should be granted at the narrowest practical securable object, such as a table, volume, schema, or catalog.
- Ownership: Each catalog, schema, table, volume, external location, and related object should have a responsible owner or owning group.
- Review: Grants, ownership, workspace access, and workload identities should be checked on a recurring schedule.
The metastore is the top-level governance container associated with one or more workspaces. Within it, catalogs organize broad domains or environments; schemas organize related tables, views, volumes, and other assets. External locations and storage credentials govern access patterns for cloud storage. AI applications may also depend on tables, volumes, functions, model-serving resources, or other governed assets, so their service identities need explicit, testable access.
What to track
Role-by-resource access matrix
Use groups for people and service principals for applications. Avoid granting routine access directly to individual users unless there is a documented exception.
| Role | Metastore and workspace | Catalogs and schemas | Tables and views | Volumes and external data | Typical operating pattern |
|---|---|---|---|---|---|
| Analyst | Workspace access through an approved group; no administrative ownership by default | Use access to approved business catalogs and schemas | Read access to required tables and views; write access only for defined work areas | Read access to approved volumes when needed; avoid broad storage permissions | Query, analyze, and create governed outputs in designated locations |
| Data engineer | Workspace access appropriate to development or production responsibilities | Create or modify objects only in assigned engineering areas | Read and write access for pipeline inputs and outputs; separate production duties where practical | Access only to storage locations used by assigned pipelines | Build, operate, and troubleshoot data movement and transformation jobs |
| Data scientist | Workspace access for approved development environments | Read access to governed source data and write access to project schemas | Read source data; create derived datasets under an owned project area | Use project volumes or approved locations for notebooks, artifacts, and data files | Develop features, experiments, and models without unrestricted production access |
| AI application | Use a dedicated service principal rather than a personal identity | Grant access only to catalogs and schemas required at runtime | Read or write only the tables needed by the application workflow | Limit volume and external-location access to required files and paths | Run with stable, auditable, least-privilege permissions |
| Governance administrator | Manage approved account, workspace, and governance functions | Manage ownership and grants according to a documented control process | Review sensitive access and exceptions | Administer storage integrations where assigned | Separate oversight from day-to-day data production when possible |
This matrix is a starting point, not a universal grant script. For each row, record the business purpose, owning group, environment, data classification, approval authority, and expiration or review date.
Inheritance, ownership, and workspace federation
Permissions can be inherited through the object hierarchy in supported configurations. That makes parent-level grants efficient, but it also makes broad grants easy to overlook. Before granting access at the catalog or schema level, check which child objects will be affected and whether the access is appropriate for every dataset in that scope.
Ownership is not a substitute for a complete access design. A team may own a schema while analysts receive read access through a group and an application receives a narrower runtime grant. Keep ownership with a durable group or accountable team rather than an employee who may change roles.
If multiple workspaces use the same metastore, review workspace access and catalog-to-workspace behavior separately. A user’s ability to enter a workspace does not automatically define what they should be able to query, and a catalog grant should not be assumed to solve every workspace-isolation requirement.
Service principals for applications
For an AI application, automation job, or scheduled pipeline, create a distinct service principal for each meaningful workload or trust boundary. Grant only the resources required to perform its documented functions. For example, a retrieval application may need read access to a curated document table and a vector-related data resource, while an ingestion job may need write access to a landing area but no access to unrelated business domains.
Track the service principal owner, deployment environment, expected operations, granted resources, secret or token management location, and last successful access test. Do not use a developer’s personal identity as the production application identity.
Cadence and checkpoints
A lightweight review calendar keeps permissions from becoming stale without turning every change into a large audit project.
- At onboarding: Map the person or workload to a group or service principal, assign workspace access, and grant the smallest useful catalog, schema, table, volume, or external-location scope.
- Before production release: Test the application identity with representative read and write operations. Confirm that denied operations are denied and required operations succeed.
- Monthly: Review new access requests, temporary grants, failed authorization events, changes in ownership, and service principals that no longer have a clear owner.
- Quarterly: Reconcile group membership, catalog and schema grants, table or view access, volume and external-location permissions, workspace assignments, and privileged roles. Remove unused access and renew documented exceptions.
- After a material change: Recheck permissions after reorganizing teams, adding a workspace, changing a storage integration, moving data between catalogs, launching an AI application, or changing an application’s data flow.
Keep a review record with the review date, reviewer, scope, findings, remediation owner, and evidence of completed changes. A simple register is often more useful than an undocumented assumption that permissions are still correct.
How to interpret changes
A new denied-access error does not always mean that one missing table privilege is the entire problem. Trace the request from the workload to the data:
- Identify the exact principal making the request. Confirm whether it is a user, group member, job identity, or service principal.
- Identify the workspace and environment from which the request originates.
- Identify the object being accessed, including its catalog, schema, table, view, volume, external location, or related resource.
- Check ownership, direct grants, group-derived grants, parent-level inheritance, and workspace-specific restrictions.
- Confirm that the requested operation matches the granted capability. Reading a table, creating an object, modifying data, and managing permissions are different needs.
- Review storage credentials, external-location configuration, network assumptions, and application configuration when the object-level grant appears correct.
When access is broader than intended, determine whether it comes from a direct grant, nested group, parent object, inherited permission, ownership, or an administrative role. Remove the source of unnecessary access rather than adding compensating exceptions elsewhere.
For AI workloads, compare permissions with the application’s actual tool calls and data flow. An application that only retrieves approved context should not automatically receive write access to source systems. Pair access reviews with evaluation and deployment reviews so that changes to prompts, retrieval sources, or tools do not silently expand the data boundary. The Databricks AI Agent Deployment Guide and Databricks AI Governance Checklist provide related planning context.
When to revisit
Revisit this permissions guide at least quarterly and whenever your data estate or AI workload changes. Prioritize a review when a new catalog or workspace is introduced, a team changes responsibilities, a service principal is added or retired, a sensitive dataset is onboarded, an external location changes, or an audit identifies an access exception.
Use this reusable access-request template for each new grant:
Requester and owner: Name the requesting team, approving owner, and technical contact.
Principal: Identify the user group or service principal.
Environment: Specify workspace, account, and development, test, or production scope.
Resources: List catalogs, schemas, tables, views, volumes, external locations, or other objects.
Operations: State the required actions and why each is necessary.
Duration: Define whether access is permanent, temporary, or subject to a review date.
Validation: Describe the successful-use test and the operations that must remain denied.
Approval and evidence: Record the approver, implementation date, and review evidence.
After each review, remove obsolete grants, assign missing owners, update the matrix, and record unresolved risks. Recheck the article and your internal permission runbook quarterly against current Unity Catalog documentation and workspace capabilities, especially when privilege names, securable-object behavior, identity-management workflows, or workspace federation options change.
