Row-Level Security in the Spreadsheet Layer

When an analyst opens a shared table in a traditional spreadsheet, they get the data their permissions allow, assuming whoever set up the export remembered to filter it. That assumption is where most RLS implementations break down in practice.

Row-level security is a warehouse-native capability. The policy lives in the warehouse, enforced at query time, by the warehouse engine. When Row Zero runs a query, it runs it as the authenticated user's warehouse credential. The warehouse applies whatever row-level policies are configured for that user or role. Row Zero doesn't have a separate RLS layer, and that's intentional.

How Warehouse RLS Works

Each major warehouse implements RLS differently at the syntax level, but the concept is consistent: a policy function or condition is attached to a table and evaluated per-row at query time based on the current session's user or role context.

In Snowflake, this looks like a row access policy assigned to a table:

CREATE ROW ACCESS POLICY rls_region_policy
  AS (region_col VARCHAR) RETURNS BOOLEAN ->
    current_role() = 'GLOBAL_ANALYST'
    OR (
      current_role() = 'REGIONAL_ANALYST'
      AND region_col = GET_PATH(CURRENT_CONTEXT(), 'region')
    );

ALTER TABLE orders
  ADD ROW ACCESS POLICY rls_region_policy
  ON (region);

In BigQuery, RLS is expressed through row access policies that bind a filter condition to a group:

CREATE ROW ACCESS POLICY sales_region_filter
  ON `project.dataset.orders`
  GRANT TO ("group:[email protected]")
  FILTER USING (region = 'EMEA');

In Redshift, row-level security is implemented via RLS policies similarly:

CREATE RLS POLICY regional_access
  WITH (region VARCHAR)
  USING (region = CURRENT_USER);

ATTACH RLS POLICY regional_access ON orders TO ROLE regional_analyst;

What Happens in Row Zero

When an analyst connects to Row Zero and opens a table, Row Zero issues a SQL query against the warehouse using the analyst's credentials, or a service account that has been granted the analyst's effective permissions. The warehouse evaluates that query under the analyst's session context, which means any row access policies attached to the queried tables are applied automatically.

If an analyst's role gives them access only to rows where region = 'EMEA', that's all they see in the spreadsheet. They can sort the data, filter further, write formulas against it, join it with another table they have access to, and run Python in-cell against it. But they cannot see rows outside their policy, because those rows are filtered before the result set leaves the warehouse.

The important architectural point here: Row Zero never receives the full unfiltered table and then applies a secondary filter. The filtering happens inside the warehouse at query execution time. There is no copy of the data on Row Zero's side that could be accessed separately.

The Scenario Where Spreadsheet-Layer RLS Matters

Consider a data platform team supporting analysts across three regional business units. Each region has a separate analyst group with warehouse roles scoped to their region's customer data. The shared customers table uses Snowflake row access policies to filter by region on customer_region_code.

Before Row Zero, the team's workflow was: engineering exports a region-filtered CSV weekly, posts it to a shared folder, analysts download and work in Excel. The problem with this workflow isn't just the staleness. It's that the CSV export step is a human process. Someone has to remember to run the right filter for each region. Mistakes happen. A CSV scoped incorrectly gets shared with the wrong regional group, and you have a data leak that's hard to audit retroactively.

With a warehouse-native spreadsheet that runs queries under each analyst's own credentials, that human export step disappears. The policy lives in the warehouse, always applied, not dependent on someone remembering to filter the export correctly.

What Row Zero Does Not Do

We want to be precise about this. Row Zero enforces the row-level security that exists in your warehouse. It does not create or manage RLS policies. If your warehouse tables have no RLS policies, a user connecting to Row Zero can query those tables without restriction, bounded only by their warehouse role's schema-level permissions (which tables and columns they can access, not which rows).

Setting up RLS correctly is a warehouse administration task. The policies need to be designed for your access model, tested for the session context behavior of your user types, and maintained as your team structure evolves. Row Zero doesn't simplify that work. What it does is make sure the work isn't undone by an intermediate export step.

Column-Level Security Follows the Same Logic

The same principle applies to column masking policies available in Snowflake and BigQuery. If your warehouse has a dynamic data masking policy on a PII column that shows the full value to a DBA role and a masked value to an ANALYST role, that masking applies to the query result regardless of the tool used to issue the query. Row Zero doesn't receive unmasked values and re-mask them. The masking is applied by the warehouse engine before the result is returned.

This isn't a special Row Zero feature. It's a consequence of query pushdown. The warehouse handles security at the data layer, and any tool that queries through the warehouse interface inherits those protections. The distinction matters because tools that extract data to a local execution layer break this chain. If a tool copies data to its own storage and queries from there, the warehouse's access policies no longer apply after the extraction point.

Row Zero doesn't extract to its own storage. Queries go to the warehouse, results come back. The warehouse's security model stays intact throughout the analyst's session.

← Back to blog