Snowflake engineers described a newly merged Iceberg extension on September 4, 2026 that moves fine-grained access control into the catalog. Read Restrictions add row filters and column masks to the Iceberg REST Catalog loadTable response, so the policy travels with the table instead of living in one engine.

The problem they name is familiar to anyone sharing an Apache Iceberg table across warehouses. The file format is portable. The access rules are not. Alice may see a full Social Security number while Bob sees only the last four digits. One engine enforces that. The next one does not, unless someone copies the policy by hand or parks it in a third-party broker that does not own the table.

Read Restrictions close that gap by sending two instructions with the metadata: required-row-filter, an Iceberg predicate the reader must apply, and required-column-projections, a list of columns and the mask for each. Both are scoped to the principal who asked. An administrator marks which engines are trusted to enforce the instructions before data goes back to the user.

The row filter is a predicate such as country = USA, built from primitives like equals, inequalities, and IN. Rows that fail must not appear, and nothing derived from those rows may leak into the result. Complex joins still sit outside the expressible set. Column masking is stricter. The spec names nine masks, including show-last-4, show-first-4, replace-with-null, mask-to-fixed-value, year or month truncation, a global SHA-256 that still joins, and a per-query salted hash that does not. Two engines implementing the same mask are supposed to emit identical output. A card number under show-last-4 comes back as nnnn-nnnn-nnnn-4444. An email under mask-alphanum becomes x.xxxxxxx@xxxxxxx.xxx.

The policy itself can stay richer than the snippet on the wire. What the catalog sends is the already-personalized restriction for that caller, which can change as roles change.

Decoded Take

Open table formats won the storage argument. They have not won the permission argument. If Read Restrictions stick, a Snowflake policy and a Trino policy stop being two documents about the same Parquet files, and catalog vendors become the identity plane for the lakehouse. That is good for auditors and awkward for engines that made fine-grained control a paid differentiator. The next fight is enforcement, not syntax. A spec can name nine masks. It cannot make every reader apply them, or stop a “trusted” engine from ignoring a filter. Watch which catalogs ship this in GA, whether Databricks and the other REST Catalog implementers adopt the same nine masks without extras, and whether regulators treat catalog-scoped FGAC as enough once the same table is queried from a laptop notebook.