Row/Column-Level Security & Data Masking

Access as role

Policy switches

Row-level security

Column masking

Masking technique

Policy strictness Sensitive only

Rows visible

–

Cols masked

–

Raw fields exposed

–

How the policy engine works

Every record in the lakehouse table carries hidden attributes — a region and department — plus a per-column sensitivity level (0 = public id, up to 3 = SSN/diagnosis-grade). Two independent controls decide what a query returns:

row visible  ⇔ !RLS || attrs(row) matches role.filter
cell shown   ⇔ !mask || sensitivity(col) < strictness→cutoff

Row-level security (RLS) — a predicate evaluated per row before any column is even considered. Turn it off and every role sees every row's rack, regardless of region or department scope.
Column masking — applied per visible cell once RLS has run. Redact blanks the value, Tokenize replaces it with a stable one-way hash of the real value (same input → same token, but irreversible), Generalize replaces a precise value with a coarser bucket.
Policy strictness — the sensitivity cutoff: at "Sensitive only" just SSN/diagnosis-grade columns mask, at "Everything but ID" almost the whole row is protected even for roles that would otherwise see it in the clear.
Raw fields exposed — the fraction of the table's total cells a role can actually read unmasked; this is the real number an auditor cares about, and it can swing from ~90% to under 5% purely from these three switches.

Real-world relevance: this is exactly how lakehouse platforms (Databricks Unity Catalog, Snowflake, BigQuery) enforce governance — RLS and column masking are evaluated at query time, so the same underlying table serves an admin the full data and a support agent a redacted, region-scoped slice, with zero data duplication.

Visible, unmasked Visible, masked Hidden by RLS

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.