Iceberg governance portability has two different paths—and neither eliminates trust

Databricks has laid out a practical framework for two recently adopted additions to the Apache Iceberg REST Catalog: read restrictions and catalog labels. The important point is that they solve different governance problems. Read restrictions let a catalog delegate an access decision to a trusted query engine; labels let one catalog pass governance context to another catalog, which then applies its own local policies. (Databricks)

Read restrictions are an enforcement contract

Under read restrictions, the source catalog evaluates policy for a particular principal and request, then returns row-filter expressions and column-projection actions for the consuming engine to enforce. The first specification deliberately uses a bounded vocabulary: nine predefined projection actions plus standardized filter expressions. Policies involving subqueries, lookup tables or custom functions may not fit without losing semantics. (Databricks)

That boundary matters for natural-language analytics. A generated query can be syntactically valid and still be unsafe if its execution layer can bypass a mask or filter. Databricks argues that user-controlled Spark or DuckDB runtimes are not trusted merely because they understand the protocol; administrators must eliminate alternate paths to the underlying data. The Iceberg specification defines what an engine must enforce, but leaves establishment of trust—potentially through controls such as mTLS or OAuth—outside the protocol. (Databricks)

Labels move context, not policy meaning

Catalog labels target federation among systems such as Unity Catalog, Snowflake, AWS Lake Formation and Google Cloud Knowledge Catalog. A producing catalog can attach opaque key-value labels at table or column level—for example, marking a field as pii=ssn. A consuming catalog maps those labels into its own classifications or tag model and evaluates access with its native identities, policies and runtime. (Databricks)

This keeps policy evaluation and auditing local and avoids a remote authorization call for every user and asset. It also makes labels useful beyond access control: Databricks identifies discovery, ownership, cost attribution, data quality and semantic hints for AI models as potential uses. But portability stops short of shared meaning. Iceberg defines neither common semantics nor stable identifiers for labels, so enterprises still need naming conventions or explicit mappings between catalogs. (Databricks)

The deployment decision

Databricks’ three-way rule is a useful architecture test: use centralized scan planning when an untrusted engine must never receive unauthorized data; use read restrictions when a trusted engine can fully express and enforce the source catalog’s decision; use labels when another catalog needs reusable governance context and will make its own decisions. (Databricks)

For teams deploying text-to-SQL agents across multiple engines, the takeaway is not that Iceberg has made governance automatic. It has standardized two handoff points. Teams still have to prove runtime trust, test whether their policies fit the restriction vocabulary, and define label semantics consistently across catalogs. Those are now clearer integration requirements rather than hidden assumptions.