Data Masking
What a masking policy is#
A masking policy says: column X of dataset Y is masked with strategy S, and
only callers at or above role R may see the raw value. Policies are the
enforcement half of column-level access control: when a read surface returns
rows, any output column matched by a policy is masked server-side for
callers below the policy's unmask role — the raw value never leaves the
server for them. A masked NULL stays NULL.
Today the enforced read surface is the ETL preview (the row preview shown when building SQL pipeline tasks).
Each policy has exactly these fields:
| Field | Meaning |
|---|---|
| Dataset key | The fully-qualified table name the column lives in, e.g. sales.customers — matched exactly against the tables referenced by the preview's SQL |
| Column | The column name; matched case-insensitively at enforcement time |
| Strategy | How the value is obscured — see below |
| Unmask role | The lowest global role allowed to see the raw value: admin, editor, or viewer |
| Enabled | Disabled policies are kept but not enforced |
One policy exists per (dataset, column) pair — saving the same pair again updates the existing policy.
Strategies#
| Strategy | Effect |
|---|---|
| Redact | Replaces the whole value with a fixed six-character bullet string; the value is gone entirely |
| Hash | SHA-256 hex digest — deterministic and non-reversible, no key involved |
| Partial | Keeps the last 4 characters and bullets the rest (card / phone number tails); values of 4 characters or fewer are fully bulleted |
| Tokenize | Keyed HMAC-SHA256 hex — deterministic per deployment (keyed with the master key), so the same input always maps to the same token: joinable without exposing the raw value |
Creating a policy#
- Open Settings → Data Masking and select New policy.
- Enter the dataset key (
<SCHEMA>.<TABLE>) and column name. - Pick a strategy and the unmask role — Admin only, Editor and up, or Everyone (viewer+).
- Save. The policy is enabled immediately.
Deleting a policy removes the rule; the column is no longer masked.
Semantics worth knowing#
- Writes are admin-only; listing is viewer+. A masking policy is an access-control rule, so only an administrator may create, relax, or remove one — but any user can see that a column is masked (policy metadata contains no secret). All writes are audited.
- Most restrictive wins. At enforcement time, when the same column name is covered by policies across several referenced datasets, the policy with the highest unmask threshold applies — the platform fails toward masking, never toward leaking.
- Matching is exact, not pattern-based. The dataset key is compared as a literal string against the preview's referenced tables, and the column name matches case-insensitively. There are no wildcard or per-connector patterns.
- The role ladder used for the unmask threshold is the global
admin > editor > viewerladder — see Roles and permissions.
Note. Masking governs read surfaces; it does not rewrite data at rest or alter what pipelines write to destinations. Use it to keep sensitive values (emails, national IDs, card numbers) out of preview results for lower-privileged users.