Iceberg's REST catalog gains a nine-action vocabulary for handing enforcement to trusted engines

A governed read under the new contract starts when a reader loads a table. The catalog evaluates the policies that apply to the requesting principal and the request context. It returns required column-projection actions and row-filter expressions, and the trusted engine must apply them as it reads ^[7]. The initial vocabulary is nine predefined column actions plus standardized row filters such as comparisons and set membership ^[9]. I think that is the right size for a first version. An engine team can implement nine actions and a small predicate language and test every case.

The hard part is reduction. The catalog has to reduce each policy to that vocabulary before it answers, and many enterprise policies depend on subqueries, lookup tables or custom UDFs that the vocabulary cannot express ^[10]. Databricks wrote that "policies can be represented only when the catalog can reduce their result to the vocabulary defined by the standard, otherwise you lose policy semantics" ^[10].

Delegation also depends on the catalog being able to rely on the engine to enforce the restrictions and stop users from bypassing them ^[4]. A securely configured Trino deployment is Databricks' example of an engine that qualifies, because it enforces row filters and column masks natively ^[6]. A user who can run arbitrary code against the files will not be slowed down by a list of restrictions in a load-table response ^[5]. Community discussion has considered mTLS and OAuth for establishing trust, but trust remains outside the protocol ^[12]. Databricks lists three open implementation questions. One is how an engine securely propagates the end user's identity and attributes. The others are how a catalog tells the user apart from the engine acting for that user, and how credentials are bound to their intended recipient ^[14].

Databricks also describes the path that avoids delegation. On dedicated compute it routes queries through a secure filtering fleet ^[15]. Unity Catalog's cross-engine ABAC puts that fleet behind the Iceberg REST scan/plan APIs, so data is sanitized before an external engine such as Spark or DuckDB processes it ^[3]. The post recommends read restrictions for direct engine-to-catalog access where the source catalog's policies are simple and a trusted engine can enforce the result ^[13]. Enforcement that works across vendors needs both conditions to hold for a team. Its policies must reduce to comparisons, set membership and the nine column actions. Its engines must run where the catalog operator can trust them. The account of where that line falls comes from Databricks, whose Unity Catalog offers the centralized alternative ^[3].

Catalog labels are the second addition the Iceberg community advanced ^[1], and they get far less detail in the Databricks account available here. It does not describe the label format or what a receiving catalog must do with a label, so the claim that labels carry governance between catalogs cannot yet be checked against spec text.