Snowflake masking and row access policies in BI tools: which ones enforce them per viewer (2026)

Snowflake masking policies and row access policies only protect data per person when the BI tool runs each viewer’s query under that viewer’s own Snowflake identity or role. Sigma, Omni, ThoughtSpot, Tableau, and Looker can do this through Snowflake OAuth or External OAuth, so a masked column stays masked for the right people inside dashboards and AI answers. Power BI does it only for DirectQuery models with Microsoft Entra ID single sign-on, Metabase switches roles per user with impersonation on its Pro plan, and Basedash queries Snowflake as one connection role for everyone. Every tool loses per-viewer enforcement somewhere: extracts, scheduled deliveries, shared caches, or embedding.

Capabilities below come from each vendor’s official documentation, and prices from each vendor’s pricing page, both checked on October 4, 2026.

Why the BI connection decides what Snowflake policies see

Snowflake evaluates a masking policy or row access policy at query time, usually by checking CURRENT_ROLE(), IS_ROLE_IN_SESSION(), or CURRENT_USER(). The policy only knows about the Snowflake session that sent the query. It has no idea which person was looking at a dashboard in a BI tool.

That creates the core problem. Most BI tools connect to Snowflake with one service user and one role. Every viewer’s query arrives as that same identity, so a policy that unmasks emails for the SUPPORT role either unmasks them for everyone (if the service role qualifies) or for no one. Your carefully written policies still run; they just can’t tell viewers apart.

Two more facts shape every design:

• Both policy types require Snowflake Enterprise Edition or higher. On Standard Edition, per-viewer filtering has to happen in the BI tool.
• When a live query runs, the policy applies. When the BI tool serves data from an extract, import, cache, or materialized table built by someone else, the policy applied to whoever built it.

If you are new to the policy types themselves, our guide to data masking in BI tools covers static versus dynamic masking and where to enforce each.

Three ways a BI tool can carry viewer identity into Snowflake

1. OAuth passthrough. Each user signs in to Snowflake through Snowflake OAuth or External OAuth (Okta, Microsoft Entra ID, Ping), and the BI tool sends queries with that user’s token. CURRENT_USER() and CURRENT_ROLE() both reflect the real person. This is the strongest option and the one most of the tools below support.
2. Per-user role switching on a shared connection. The BI tool keeps one service user but runs USE ROLE (or picks a connection) based on a user attribute. Policies written against CURRENT_ROLE() work; policies written against CURRENT_USER() see the service user.
3. Session context. The BI tool sets a session variable or query tag carrying the viewer’s email or group, and the row access policy reads it. This works without OAuth but depends on the BI tool setting the variable on every query.

The fallback is BI-layer security: row filters and column rules defined in the BI tool’s model. That protects dashboards inside the tool but not other clients that query Snowflake directly. Our comparison of BI tools for row-level security covers that layer in depth.

How we evaluated

We scored each tool on the questions buyers ask when Snowflake already holds the security rules:

• Per-viewer identity. Can queries run as each viewer through Snowflake OAuth or External OAuth, and which identity providers work?
• Role switching without OAuth. Is there a supported way to set a per-user role, connection, or session variable?
• Where enforcement stops. Do extracts, scheduled deliveries, alerts, and shared caches run as someone else?
• Embedded viewers. Does identity pass through when dashboards are embedded in a customer portal?
• Tool-side column controls. Can the BI tool hide or mask a field when Snowflake can’t tell viewers apart?
• AI features. Do natural language and agent features query through the same connection and permissions?

Comparison table

Tableau

Best for: teams on Okta or Entra ID who want live Tableau dashboards to inherit Snowflake policies per viewer.

• Pricing model: per user by role, annual only. Tableau Cloud Standard is $75 Creator, $42 Explorer, and $15 Viewer per user per month; Enterprise is $115, $70, and $35 (Tableau Cloud pricing, verified October 2026).
• Deployment: Tableau Cloud or Tableau Server.
• Query model: live connections or extracts.
• Per-viewer identity: Snowflake OAuth works out of the box on Tableau Cloud. Tableau Server 2024.2 and later needs a custom OAuth client (Tableau Server Snowflake OAuth). Since 2024.3, External OAuth federates identity from Okta, Entra ID, or Ping.
• The setting that matters: a published data source set to “Prompt user” runs as each viewer. “Embed credentials” behaves like a service account (Snowflake OAuth in Tableau).
• RLS and SSO: user filters on every edition; centralized data policies come with Data Management, which is now included only in Enterprise, Cloud+, and Tableau+. SAML and OIDC SSO on Standard and above; SCIM supported.
• AI features: Tableau Agent respects user-defined row and column policies; Tableau Pulse needs embedded credentials, SSO passthrough, or saved credentials and does not prompt for a database sign-in (Pulse setup).
• Embedding: Embedding API with connected apps.

Tradeoffs. Per-viewer enforcement only holds on live connections. Extracts query Snowflake once at refresh time as the publisher. Subscriptions and data-driven alerts require embedded credentials, so they run as one identity. Embedded views through connected apps do not display data sources set to prompt for credentials, which rules out OAuth passthrough for most customer-facing embeds.

Not ideal for: customer portals that need Snowflake policies per external viewer.

Power BI

Best for: Microsoft 365 organizations that can run Snowflake models in DirectQuery.

• Pricing model: per user. Free, Pro at $14, and Premium Per User at $24 per user per month, paid yearly (Power BI pricing, verified October 2026).
• Deployment: cloud service; Power BI Report Server on-premises.
• Query model: Import or DirectQuery.
• Per-viewer identity: a Fabric admin enables the Snowflake SSO tenant setting, and the model owner selects “End users use their own OAuth2 credentials when accessing this data source via DirectQuery” (Power BI Snowflake connection). Microsoft Entra ID is the only supported identity provider, and SSO only supports DirectQuery. Snowflake documents the Power BI SSO integration, which uses the user’s default role.
• RLS and SSO: DAX roles for rows and object-level security for tables and columns. Users are Entra ID accounts, so SSO is built in and SCIM is not needed.
• AI features: Copilot needs F2 or P1 capacity or higher. Microsoft states Copilot only accesses data the current user can access.
• Embedding: Power BI Embedded (quote).

Tradeoffs. Import mode copies data into the semantic model, and Microsoft notes that data source security roles aren’t used on import. DirectQuery against Snowflake costs warehouse time on every visual. For customer-facing embedding where your app owns the data, Microsoft’s embed token docs list Azure SQL Database as the only source that accepts an SSO identity, so Snowflake SSO does not carry into those embeds. Okta and Ping are not documented.

Not ideal for: Okta-only shops or teams that need import mode for speed.

Looker

Best for: teams already modeling in LookML who want each user’s Snowflake grants to apply.

• Pricing model: quote only. Standard, Enterprise, and Embed editions each include 10 Standard users and 2 Developer users (Looker pricing, verified October 2026).
• Deployment: Google Cloud hosted (Looker, Google Cloud core).
• Query model: live queries, with persistent derived tables (PDTs) for materialization.
• Per-viewer identity: with OAuth on the Snowflake connection, each Looker user authenticates with their own Snowflake account. It uses Snowflake’s own OAuth; External OAuth is not documented. Users get their default Snowflake role and cannot switch roles.
• Without OAuth: user attributes can parameterize connection fields, for example a per-user warehouse or database credentials.
• RLS and SSO: access_filter for rows and access_grant for Explores, views, and fields. SAML and OIDC on Standard and above; no native SCIM endpoint documented.
• AI features: Gemini in Looker and Conversational Analytics run queries through the LookML model and follow its permissions.
• Embedding: signed embedding with user attributes.

Tradeoffs. PDTs are not supported on OAuth Snowflake connections, so you configure a PDT override user, and those tables are built with that single identity. Schedules and alerts run on the owner’s OAuth token and fail if it expires. Caches are per user. Behavior of OAuth connections for signed embed users is not documented, so plan on access filters for embedded viewers.

Not ideal for: teams that need role switching or Okta-federated Snowflake sessions.

Sigma

Best for: spreadsheet-style analysis on Snowflake where governance lives in Snowflake grants and policies.

• Pricing model: quote only; 7-day free trial (verified October 2026).
• Deployment: cloud only; queries run in your warehouse.
• Query model: live queries with result caching.
• Per-viewer identity: organization-level OAuth reuses the identity provider users sign in with; connection-level OAuth supports ADFS, Auth0, Entra ID, Okta, Ping Identity, or Snowflake’s OAuth server (Snowflake OAuth in Sigma). Optional role switching lets users pick among their granted roles. Sigma describes OAuth as a premium feature enabled through your account executive.
• Without OAuth: role and warehouse user attributes on key pair connections, and query variables (beta) that set a session variable such as sigma_user_email for row access policies to read.
• RLS and SSO: user-attribute RLS and column-level security in data models. SAML SSO and SCIM supported; tier not published.
• AI features: Sigma Assistant applies the same grants and RLS. Warehouse agents (Cortex) run with the connection’s configured role.
• Embedding: secure embeds can pass the viewer’s token in the oauth_token JWT claim (embedded data access).

Tradeoffs. Under individual OAuth credentials, Sigma does not reuse cached results across users, so warehouse cost rises. The “run as service account” workbook setting and public embeds bypass per-viewer policies. Scheduled exports fail when the owner’s token expires. Pricing is not public.

Not ideal for: teams that need public price lists or offline extracts.

ThoughtSpot

Best for: search and agent-driven analytics on Snowflake with Okta or Entra ID passthrough.

• Pricing model: per user or usage credits. Essentials from $25 per user per month for 5 to 50 users, Pro from $50 per user per month with Spotter capped at 25 queries per user per month, Enterprise custom (ThoughtSpot pricing, verified October 2026). 14-day free trial.
• Deployment: ThoughtSpot Cloud or self-managed ThoughtSpot Software.
• Query model: live queries against the warehouse.
• Per-viewer identity: Snowflake OAuth, plus External OAuth through Entra ID or Okta, with an optional secondary roles setting.
• Without OAuth: additional connection configurations assign a different user, role, or warehouse to specific users and groups.
• RLS and SSO: RLS rules with ts_username and ts_groups, plus column security rules. SAML and OIDC SSO; SCIM on ThoughtSpot Cloud.
• AI features: Spotter enforces existing row- and column-level security and sends generated SQL to your warehouse.
• Embedding: Visual Embed SDK.

Tradeoffs. Scheduled Liveboards show non-ThoughtSpot recipients data based on the sender’s permissions. Column indexing for search suggestions runs with the connection owner’s OAuth credentials, so turn indexing off on masked columns or suggestions can surface values. ThoughtSpot “passthrough functions” are SQL wrappers, not identity passthrough. Embedding with warehouse OAuth is not documented.

Not ideal for: teams that want a flat price without per-user AI query caps.

Omni

Best for: teams that want a shared semantic model and Snowflake policies applied per viewer, including inside embeds on a custom domain.

• Pricing model: quote only; no public pricing page (verified October 2026).
• Deployment: Omni-hosted.
• Query model: live queries with caching.
• Per-viewer identity: per-user OAuth, native Snowflake or External through Okta or Entra ID. With External OAuth, each user’s queries run under their own Snowflake role and session. A service account still builds the model.
• Without OAuth: dynamic connection environments map users to per-role connections through a user attribute. Omni warns not to rely on these alone to isolate sensitive data.
• RLS and SSO: access_filters for rows, access_grants for fields and topics, and mask_unless_access_grants, which replaces values with an MD5 hash. SAML, OIDC, and SCIM supported; tier not published.
• AI features: AI-generated queries run within the workbook and respect Omni permissions.
• Embedding: signed embed URLs; per-user OAuth works only on vanity domain embeds.

Tradeoffs. Schedules run as the creator and cannot be personalized with user attributes. Caches, cubes, and extracts are not shared across users, which lowers cache hit rates and raises warehouse spend. Every user sees the same model fields unless access grants hide them. See how Omni and Sigma differ elsewhere in our Omni vs Sigma comparison.

Not ideal for: teams that need published pricing or embeds on Omni’s default domain.

Metabase

Best for: teams that can map users to a handful of Snowflake roles and want an open source path.

• Pricing model: platform fee plus per user. Open source is free; Starter is $100 per month for 5 users plus $6 per user; Pro is $575 per month for 10 users plus $12 per user ($517.50 per month billed yearly); Enterprise is custom (Metabase pricing, verified October 2026). 14-day trial.
• Deployment: Metabase Cloud or self-hosted.
• Query model: live queries with optional caching.
• Per-viewer identity: not supported. The Snowflake connection uses one user with a password or RSA key.
• Role switching: impersonation (Pro and Enterprise) runs USE ROLE with a role taken from a user attribute before each query. Snowflake is supported, and the connection user must have secondary roles disabled. Because the Snowflake user stays the shared Metabase user, write policies against CURRENT_ROLE() rather than CURRENT_USER(). Database routing is the alternative when each group needs its own connection.
• RLS and SSO: row and column security (formerly sandboxing) on Pro and Enterprise; it does not apply to SQL questions. SAML and JWT SSO and SCIM on Pro and Enterprise.
• AI features: Metabot inherits the permissions of the person using it; the MCP server is scoped to the connecting person’s permissions.
• Embedding: Modular embedding SDK and guest embeds.

Tradeoffs. People in the Admins group are never impersonated, and the most permissive group a user belongs to wins. Impersonated users cannot create Slack alerts or dashboard subscriptions, and alerts show recipients data under the creator’s permissions. Guest embeds always route to the router database, so per-viewer Snowflake roles don’t reach anonymous embed viewers.

Not ideal for: policies keyed to individual Snowflake users rather than roles.

Basedash

Best for: small teams on Snowflake whose policies are role-based and coarse, and who want AI-generated dashboards without a modeling project.

• Pricing model: flat team tier plus AI usage. Startup is $1,000 per month for up to 25 users, including $1,000 of monthly AI credits; Enterprise is custom (Basedash pricing, verified October 2026). 14-day trial, no credit card.
• Deployment: cloud, or self-hosted on Enterprise.
• Query model: live queries against Snowflake; no extracts.
• Per-viewer identity: not supported. The Snowflake connection uses one user (key pair recommended) and an optional role. Snowflake masking and row access policies apply, but they evaluate every viewer as that one role.
• Per-group workaround: connect Snowflake more than once with different roles, then use data source access control to limit each connection to the right Basedash groups. Grants apply in charts, dashboards, AI chat, exports, and the SQL editor.
• RLS and SSO: per-user row-level security through the basedash.groups session variable works on PostgreSQL only. Data visibility controls hide tables, schemas, or columns organization-wide. SAML and OIDC SSO and SCIM on Enterprise.
• AI features: AI chat that writes Snowflake SQL and builds charts and dashboards, plus an MCP server on every plan. AI queries go through the same connection and grants.
• Embedding: embedding with a React SDK on Enterprise.

Tradeoffs. If your Snowflake policies distinguish individual users, or you need a column masked for some viewers and clear for others on the same dashboard, Basedash can’t express that today. Sigma, Omni, ThoughtSpot, Tableau, or Looker with OAuth are better fits. Basedash works when the security boundary is a few roles that map cleanly to groups, or when sensitive columns can be hidden for everyone. More on Basedash with this warehouse is on the BI for Snowflake page.

Not ideal for: per-viewer masking or row filtering on Snowflake.

Do AI assistants in BI tools respect Snowflake masking policies?

They respect whatever identity the BI tool queries with. Snowflake can’t see a prompt; it sees SQL from a session. So the AI question reduces to the connection question above.

Vendors document this at the BI layer. Tableau Agent respects user-defined row and column policies. Spotter enforces ThoughtSpot RLS and column rules. Sigma Assistant applies the same grants as the rest of Sigma. Metabot inherits the user’s Metabase permissions. Omni runs AI queries inside the workbook under Omni permissions. Microsoft says Copilot only accesses data the current user can access. None of these vendors states in its docs that the AI feature forwards the viewer’s Snowflake OAuth token, though each says the feature uses the same model or connection as everything else.

Two practical checks matter more than vendor statements:

• Schema metadata. Masking hides values, not column names. Hex, for example, notes that its AI features do not filter schema suggestions to a user’s permissions. If a column name is itself sensitive, hide it from the model.
• Agents that use a fixed role. Sigma’s warehouse agents run with the connection’s configured role, not the viewer’s. Snowflake’s own Cortex Analyst and agents run in the user’s session, and policies can detect agent activity with SYS_CONTEXT('SNOWFLAKE$CURRENT','IS_AGENT_ACTIVATED') if you want stricter rules for AI queries.

Does per-viewer enforcement slow dashboards down?

The documented cost shows up in caching. When every viewer queries as themselves, results cached for one person can’t be served to another. Sigma does not reuse cached results across OAuth users, Omni does not share caches, cubes, or extracts across users, and Looker caches per user. Expect more warehouse queries, more compute credits, and slower first loads for each viewer.

Ways to limit the impact:

• Keep heavy aggregation in Snowflake tables or dynamic tables that are safe for everyone, and apply row access policies to the detail tables people drill into.
• Use role-based policies (IS_ROLE_IN_SESSION) instead of per-user lookups, so mapping tables stay small.
• Reserve OAuth passthrough for workbooks that touch policy-protected tables, and run aggregate-only content through a service account.

Which tool should you choose?

• Your identity provider is Okta and you want policies per viewer: Sigma, Omni, ThoughtSpot, or Tableau. Looker supports Snowflake OAuth but not External OAuth through Okta.
• You are a Microsoft shop: Power BI with Entra ID SSO on DirectQuery models. Accept that import-mode models and scheduled refreshes don’t carry the viewer’s identity.
• You embed dashboards in a client portal: Sigma secure embeds can pass a viewer token in the JWT, and Omni supports per-user OAuth on vanity domain embeds. Tableau, Power BI app-owns-data, and Metabase guest embeds fall back to one identity, so use BI-layer row filters for external viewers.
• You can’t use OAuth: Metabase impersonation or Sigma role attributes for role switching, Sigma query variables or ThoughtSpot per-group connection configurations for session context.
• You want a semantic model with field masking in the BI tool: Omni’s mask_unless_access_grants, Looker access grants, Power BI object-level security, or Sigma column-level security.
• You are a small team with role-based policies: Basedash or Metabase, using one connection per role and group-level access, at a published price.

For the broader Snowflake shortlist beyond security, see our guide to the best BI tools for Snowflake, and for SSO, SCIM, and audit logs by plan see BI tool security features by plan.

Other options worth knowing

• Hex. OAuth data connections on the Enterprise plan store a token per user. Published apps either require each viewer’s credentials or run as the publisher.
• Lightdash. Projects can require users to provide their own warehouse credentials, including Sign in with Snowflake. Pre-aggregates always run under a single user.
• Snowflake Cortex Analyst and Cortex Agents. These run inside Snowflake in the user’s own session, so RBAC and policies apply without any passthrough setup. They answer questions rather than replace a dashboarding tool.

Frequently asked questions

Which AI-enabled BI tools integrate with Snowflake and support fine-grained column masking?

Sigma, Omni, ThoughtSpot, Tableau, and Looker can query Snowflake with each viewer’s OAuth identity, so Snowflake masking policies decide per person whether a column is masked. Power BI does the same on DirectQuery with Entra ID SSO. If you need the BI tool itself to mask a field, Omni’s mask_unless_access_grants hashes values, Sigma and ThoughtSpot have column security rules, and Power BI has object-level security. All of these tools also include AI query features that run through the same permissions.

How does role-based access control work when a BI tool queries the warehouse live?

Snowflake applies grants, masking policies, and row access policies to the session that sends the query. If the BI tool uses one service role, every viewer gets that role’s access. If it uses OAuth passthrough, each query carries the viewer’s own user and default role. Role switching through impersonation or user attributes sits in between: the user stays shared but the role changes per viewer. Design policies against CURRENT_ROLE() when you rely on role switching.

Do Snowflake masking policies apply to Tableau extracts or Power BI import mode?

Only at refresh time. An extract or import queries Snowflake once with the publisher’s or gateway’s credentials, and whatever that identity can see is stored in the extract. Every viewer then sees the stored result unless you add BI-layer filters. Tableau notes extracts query the database only at creation and refresh, and Microsoft states that data source security roles aren’t used for imported data. Keep policy-protected tables on live or DirectQuery connections.

Which edition of Snowflake do I need for masking and row access policies?

Dynamic data masking and row access policies both require Snowflake Enterprise Edition or higher. On Standard Edition, you can still restrict tables and views with grants and secure views, but per-row and per-column rules have to live in the BI tool, for example in Looker access filters, Sigma user attributes, Power BI roles, or Metabase row and column security.

How do LLM assistants in BI tools protect masked Snowflake data?

The assistant generates SQL, and the BI tool runs it through the normal connection. With OAuth passthrough, Snowflake masks values for that viewer before the results reach the model. With a shared service role, the model sees what that role sees. Values the model never receives can’t appear in an explanation, so enforce masking in Snowflake with per-viewer identity, and hide sensitive column names from the BI tool’s model if names alone reveal too much.

Can I enforce Snowflake row access policies for customers viewing embedded dashboards?

Partly. Sigma secure embeds can pass a viewer’s OAuth token in the embed JWT, and Omni supports per-user OAuth on vanity domain embeds. Most embedded customers don’t have Snowflake accounts, though, so the common pattern is a row access policy that reads a session variable or a mapping table, with the BI tool setting the tenant ID on each query, or BI-layer row filters driven by signed embed attributes in Looker, Metabase, Omni, or Basedash.

Does Basedash enforce Snowflake masking policies per user?

No. Basedash connects to Snowflake as one user and role, so Snowflake policies apply but evaluate every Basedash viewer the same way. Teams separate access by connecting Snowflake once per role and limiting each connection to specific groups with data source access control, and by hiding sensitive columns organization-wide. Per-user row-level security in Basedash works on PostgreSQL through the basedash.groups session variable.