I read the current limitation lists for Databricks access policies so you do not have to find them by breaking a pipeline. If you are new to the platform, my older write-up on Azure Databricks Unity Catalog covers the basics, and Unity Catalog: Unlocking Powerful Advanced Data Control in Databricks covers the control model this post builds on.

Your Databricks Access Policies Have Gaps: What the Docs Actually Say

Two mechanisms exist, and the limits differ between them. The first is manually applied, table-level row filters and column masks. The second is attribute-based access control (ABAC) policies, which apply row filters and column masks by rule. Keep both in your head, because a runtime floor or a feature restriction that holds for one often does not hold for the other.

One framing point before the list. Almost everything below is documented as “unsupported” or “blocked”, not as a silent leak. I am not going to tell you your masked data is escaping, because the documentation does not say that and I have not tested it. What the docs do say is that there are places where these policies stop, and a team that does not know where will find out in production. The general reference is the Unity Catalog row filters and column masks page.

Gap 1: Views and Time Travel With Manual Filters and Masks

Databricks states it flatly: you cannot apply row-level security or column masks to a view. That is the manual mechanism. It means that if your design was “mask the base table, then expose curated views”, you cannot attach the filter or mask to the view itself. My earlier piece on table-level access in modern platforms is the background for why that layering is attractive.

Time travel is the second one. The docs say time travel isn’t supported with table-level row filters or column masks.

Note the verb. “Not supported” does not tell you what a time travel query returns, and the page does not say. I will not guess. If you rely on time travel against a filtered table, test it in your own workspace and read the result yourself.

The ABAC side of both stories is different, and it is still Beta. I cover it at the end.

Gap 2: Copies, Shares and Side Doors (Clones, OpenSharing, REST APIs, Paths)

This is the gap that hits data engineers, because it is about moving data rather than querying it.

Deep and shallow clones are not supported on tables that have row-level security or column masks. The ABAC requirements page says the same for tables with ABAC policies. So a nightly deep clone to a sandbox, or a shallow clone for a test environment, is a job that will not work against a protected table under either mechanism.

OpenSharing providers cannot share tables with table-level row filters or column masks. If a share is how a partner gets your data, a manually masked table cannot be in it.

External engines are next. You cannot use the Iceberg REST catalog or Unity REST APIs to access tables with row filters or column masks. If you built interoperability around those endpoints (my post on Delta UniForm and open lakehouse interoperability describes why people do), this is the limit to check first.

Last, paths. Path-based access to files in tables with policies is not supported. If anything in your estate reads table files directly by storage path, it is outside this model. The same discipline applies if you use volumes, which I wrote about in Maximize Efficiency with Volumes in Databricks Unity Catalog.

Here is each route a consumer might take to a table that carries a row filter or column mask policy, and what the documentation says about it.

Gap 3: Runtime Version Floors That Differ by Mechanism

Runtime floors are the part most likely to bite on a Monday morning, because clusters drift.

Databricks Runtime versions below 12.2 LTS do not support row filters or column masks. The docs say such runtimes fail securely, meaning no data comes back. That is the safe direction to fail in, but an empty result in a scheduled job is still an incident.

For manually applied filters and masks there is a second floor. You cannot read them using dedicated compute on Databricks Runtime 15.3 or below, per the manual application page.

ABAC is stricter. Standard and dedicated compute on runtimes earlier than 16.4 can’t access ABAC-secured tables, according to the ABAC requirements page.

If you plan to move from manual masks to ABAC, the 16.4 line is the one that will cost you cluster upgrades.

Gap 4: ABAC Edge Cases, Plus Nested MERGE (AI Search Indexes, One Row Filter)

Here is the one item in this post that reads like genuine non-propagation. The ABAC requirements page says ABAC policies on a source table don’t apply to AI Search indexes created from that table.

I want to be careful. I have not tested this. The docs state the limit and I am repeating the limit. But if you have a masked table feeding an index that an application or agent queries, this is the first thing I would test, because the index is a separate object and the policy is documented as not following the data into it.

Two smaller limits sit alongside it. Only one distinct row filter can resolve at runtime for a given table and a given user, so overlapping row filter policies that would hand one person different filters on the same table are a design problem. The other comes from the general row filters and column masks page, so it is not ABAC-specific: MERGE statements do not support tables with row filter or column mask policies that contain nesting, which matters if your upserts target a table with layered policies.

Metric views are also not supported by ABAC policies on views.

What a Team Should Check This Week

This is the gaps above turned into an inventory.

1. List every cluster and job runtime. Anything below 12.2 LTS cannot use row filters or column masks, dedicated compute on 15.3 or below cannot read manually protected tables, and ABAC needs 16.4 or later.
2. Search your jobs for deep and shallow clones of any table that carries a policy.
3. List the OpenSharing shares and check whether any includes a table with a table-level row filter or column mask.
4. List every AI Search index built from a table with ABAC policies, and test what an index query returns.

For the wider housekeeping around catalogs and grants, my Unity Catalog best practices post is still a reasonable starting point, though it predates all of this.

September’s Four ABAC Additions, All Beta

Databricks shipped four ABAC changes in September 2026. All four are Beta. I am giving dates because the September release notes do, and I am giving no GA dates because I have none.

DENY policies (Sep 8, Beta). These are narrow. They can deny the MANAGE ACCESS CONTROL privilege. That is not a general deny on reading data, so do not read it as a fix for any gap above.

Metastore-level policies (Sep 17, Beta). A single policy applies across every catalog in the metastore, including catalogs created later. This is about coverage rather than a limitation listed in the gaps.

Time travel (Sep 23, Beta). Time travel queries now enforce ABAC policies, starting in Databricks Runtime 19, on qualifying Unity Catalog managed tables. I cannot tell you which tables qualify, because I have not found the criteria stated. This partly addresses Gap 1 on the ABAC side only.

Views (Sep 29, Beta). ABAC row filters and column masks now extend to views, in addition to tables, and the ABAC views documentation says Databricks Runtime 19 or above is required. Metric views are not supported. This partly addresses the view gap, again for ABAC only.

Manual row filters and column masks on views and time travel remain as described in Gap 1. The Beta features change the ABAC picture, and I would not treat them as a reason to relax the checklist.

Conclusion

Treat the documented limits as your threat model, because they stay true whether or not these Beta features ever reach GA. By the end of this week, run the four checks above: runtimes, clones, shares, and AI Search indexes. If you skip the runtime audit, the docs say the failure is empty results rather than exposed data, but a broken job is still a broken job. If you skip the AI Search check, you are relying on a policy that the documentation says does not apply to the index.

If you test the AI Search case, I would like to hear what you see. Tell me what the index returned, which runtime you used, and whether the source table used ABAC.