ABAC in Unity Catalog already gave teams a better way to apply row filters and column masks at scale. Instead of rebuilding the same access logic table by table, teams can classify data with governed tags and let policies apply automatically across a catalog or schema.
The latest updates build on that foundation. They start to address the areas where governance usually gets harder: models, user identity, agent-driven access, derived data, and external query engines.
1. ABAC Grant Policies for models
ABAC Grant Policies are now in Beta for models.
A policy can dynamically grant EXECUTE on models that match a governed-tag condition. For example, a team could tag approved models with lifecycle = production and grant analysts permission to execute every production model in a schema. When a new approved model is registered and tagged, the policy applies without someone creating another individual grant.
The current scope is specific: Grant Policies support EXECUTE on models at the catalog or schema level. That includes customer-registered MLflow models and Databricks-hosted foundation models.
This is a useful addition for teams managing a growing number of models. Model approval, lifecycle tagging, and access management can now be connected instead of being handled as separate processes.
2. Identity Attributes are coming
Identity Attributes are listed as Preview soon.
Today, most organizations use groups for everything: region, department, clearance, employment type, project role, and more. Over time, that creates a large number of groups and access combinations that are difficult to review.
Identity Attributes are intended to let policies use live user properties, such as department, region, or clearance, from an identity provider or from Databricks. A future policy could compare a user’s assigned region with a data-residency tag, or use clearance information when determining whether a sensitive field should be masked.
This is not something to implement today, but it is a good reason to review where groups are being used as a substitute for an actual business attribute.
3. Context Attributes will matter for agents and applications
Context Attributes are also Preview soon.
Access is no longer only initiated by someone opening a notebook or running a SQL query. It can come through an internal application, a customer portal, an embedded dashboard, or an AI agent.
Context Attributes are intended to let ABAC policies consider where the request originates, including an agent, application, or workspace. This is important because the same employee accessing data from an internal analytics workspace and the same employee acting through an autonomous agent are not necessarily the same risk scenario.
For teams building governed agent workflows, this is one of the more important updates to watch.
4. Tag Propagation keeps classification with the data
Tag Propagation is available in Private Preview.
A common ABAC problem is simple: a source table is correctly classified, but transformed tables and downstream views are created without the same tags. The data is still sensitive, but the policy no longer has the attribute it needs to protect it.
Tag Propagation carries governed tags from source tables and columns to downstream tables and views as data is transformed. This is especially relevant in a medallion architecture, where customer, transaction, employee, or financial data often moves across several layers before reaching analytics or AI workloads.
The financial-services ABAC lab reflects this reality. PII fields such as account numbers, Social Security numbers, and email addresses need masking, while access to certain customer or account records may need row-level restrictions. The classification should not stop at the source layer. Propagating it downstream is what makes tag-driven controls sustainable.
5. Cross-engine ABAC extends policy enforcement outside Databricks
Cross-engine ABAC is a related Beta release.
It allows external engines to query Unity Catalog tables while Databricks enforces applicable ABAC row filters and column masks. The external engine receives filtered and masked data rather than unrestricted table data.
This matters for organizations using Apache Spark, Iceberg, or other engines alongside Databricks. It provides a path to support open data access patterns without recreating fine-grained security logic in every platform.
There are requirements to plan for, including managed tables with catalog commits, external data access, EXTERNAL USE SCHEMA, supported authentication, and serverless compute for policy enforcement. It is not simply a switch to turn on, but it is a meaningful step for multi-engine data architectures.
What I would focus on now
The starting point is still a disciplined governed-tag taxonomy. Keep it small and useful: PII type, sensitivity, region or residency, business domain, and model lifecycle are good places to start.
Use ABAC where the same policy should apply repeatedly across many tagged assets. Keep direct table-level row filters and column masks for exceptions where the logic is truly unique to one table. Also remember that ABAC does not grant basic table access by itself. Standard Unity Catalog privileges still provide the baseline access; ABAC adds the fine-grained restriction or dynamic model grant.
The direction is practical. Unity Catalog ABAC is moving from a way to protect data tables into a broader control model for data, models, applications, agents, and external consumers.
#Databricks #UnityCatalog #DataGovernance #ABAC #DataSecurity #DataAccessControl #AIDataGovernance #GovernedAI #Lakehouse #DataEngineering #DataArchitecture #DataAndAI #Avanade #Accenture #AvanadeDoWhatMatters
