Skip to content
Rime Documentation

Masked by Default

Rime applies a masked-by-default governance model to every column in your Snowflake account. When data lands in Snowflake through a connector or Snowpipe, every column is automatically masked. No role can see the underlying values until a governance administrator explicitly classifies the column and grants visibility to specific roles.

This page explains why Rime uses this approach, how it works at the Snowflake level, and what the end-to-end workflow looks like.

Why masked by default

Traditional data governance models work by opting in to masking. You identify sensitive columns, write masking policies, and apply them. Everything you miss is visible to anyone with query access. This creates a predictable failure mode: new columns arrive unmasked, schema changes introduce unclassified fields, and PII leaks into dashboards before anyone notices.

Rime inverts this model. Instead of asking “which columns should be masked?”, the system assumes every column should be masked and asks “which columns should be visible, and to whom?” The result is that unclassified columns are inaccessible rather than exposed. New columns that arrive from source system schema changes are masked immediately, with no manual intervention required.

This approach means:

  • New columns are safe by default. When a source system adds a field that contains sensitive data, it is masked the moment it lands in Snowflake.
  • Coverage gaps are visible. Unclassified columns show up in the classification coverage report, not in analyst dashboards.
  • Governance failures are restrictive, not permissive. If something goes wrong with classification, the failure mode is “a role cannot see a column it should” rather than “a role can see data it should not.”

How it works in Snowflake

Rime implements masked-by-default using Snowflake’s tag-based masking policies, a feature that requires Snowflake Enterprise Edition or higher. The mechanism has three layers:

  1. Tags — Rime creates Snowflake object tags that represent privacy levels and PII types. Every column receives a default tag that triggers the base masking policy.
  2. Masking policies — Rime creates Snowflake masking policies that define what masked data looks like (full mask, null, partial mask, etc.). These policies are bound to tags, not to individual columns.
  3. Role grants — Rime manages which Snowflake roles can see through the mask for each tag. A role must be explicitly granted visibility for a specific privacy level or PII type.

When a query executes, Snowflake checks the column’s tag, finds the associated masking policy, and evaluates whether the querying role has been granted visibility. This happens at the Snowflake engine level — there is no Rime middleware in the query path.

What masked data looks like

The appearance of masked data depends on the masking policy assigned to the column’s tag:

Masking typeExample outputUse case
Full mask****Default for most string columns
Null maskNULLDefault for numeric and date columns
Partial mask***-***-7890Phone numbers, account numbers where last digits are useful for verification
Hasha3f2b8c1...When referential integrity must be preserved across masked joins
Date truncation2024-01-01Dates where year is acceptable but full date is sensitive

Roles without visibility see the masked version. Roles with explicit visibility grants see the original value. There is no in-between — a role either sees the real data or the masked version for a given column.

The workflow

The end-to-end process from data landing to role-based visibility follows these steps:

1. Data ingestion

Data arrives in Snowflake through a connector run or Snowpipe. Rime applies the default masking tag to every new column automatically. At this point, no role other than the Rime service account can see the actual values.

2. PII detection

Rime’s automatic PII scanner samples rows from new and modified columns, looking for patterns that match known PII types. Detected PII is flagged for review — it is not auto-classified.

3. Column classification

A governance administrator reviews flagged columns and classifies them using the data classification interface. Each column receives:

  • A privacy level (Public, Internal, Confidential, Restricted)
  • An optional PII type (email, phone, IRD number, etc.)

Columns can also be classified proactively, without waiting for PII detection.

4. Masking policy assignment

Based on the classification, Rime assigns the appropriate masking policy. Default masking policies are applied automatically based on privacy level and PII type. You can override these with custom policies.

5. Role-based unmasking

The governance administrator grants visibility to specific Snowflake roles. For example:

  • The ANALYST_ROLE might see Public and Internal columns unmasked
  • The COMPLIANCE_ROLE might see everything up to Confidential
  • Only SECURITY_ADMIN sees Restricted columns

These grants are managed through the Rime UI and applied as Snowflake role grants.

6. Ongoing governance

As new data arrives, columns are masked automatically. The compliance reporting dashboard tracks classification coverage, and the PII scanner flags new columns for review. The cycle repeats without requiring changes to the base masking infrastructure.

Tier availability

Masked-by-default governance is available at Business tier and above. Free/Trial and Small Business tiers do not include tag-based masking, PII detection, or column-level classification.

Snowflake Enterprise Edition is required on the customer side. Standard Edition does not support tag-based masking policies. If your Snowflake account is on Standard Edition, Rime will indicate this during Snowflake connection setup.

Limitations

  • Masking operates at the column level. Row-level security is managed separately through Snowflake’s row access policies and is outside Rime’s current scope.
  • Masking policies are evaluated at query time by Snowflake. Rime does not intercept or proxy queries.
  • Columns in views inherit masking from their source columns. If a view selects from a masked column, the view output is also masked unless the querying role has visibility.
  • Semi-structured data (VARIANT, OBJECT, ARRAY columns) is masked at the column level, not at individual key paths within the structure.

Next steps