Snowflake Formal

Snowflake Access Control and Data Masking

Works withPAM

Formal's Connector sits in front of Snowflake and checks every session, query and result against the person or agent behind it, including the human behind a shared BI service account. Mask columns, block queries and log everything, on top of your Snowflake roles.

Get a demo ›Read the docs ›

~/.snowflake/config.tomlexample

# Point the Snowflake CLI at the Formal Connector
[connections.my-connection]
account = "<snowflake-account-id>"
host = "account.<connector-hostname>"
port = <connector-port>
user = "idp:formal:human:[email protected]"
password = "<your-formal-token>"

$ snow connection test -c my-connection

How Formal connects to Snowflake

Add Snowflake as a resource
Create a Snowflake resource with your account URL and turn on TLS, with a Formal-managed or your own wildcard certificate.
Store the Snowflake credentials
Native Users hold a password or key-pair (SNOWFLAKE_JWT) credential, picked per identity. Users never see or send it.
Connect as a Formal identity
Clients connect to account.<connector-hostname> with your Snowflake account identifier and a Formal human or machine user.
Enforce and log
Policies run at session, request and response. Every query is logged with the user and the end user.

What Formal adds to Snowflake security

PAM

Policies per person, not per role

Rego policies see the Formal user, their groups and the Snowflake role used to connect. One policy can cover Snowflake, Postgres and MySQL.

PAM

Per-user column masking

Nullify, hash, fake or redact result columns before they reach the client. When policies overlap, the highest privacy level wins.

PAM

The human behind the BI account

BI tools pass the end user to the Connector, so policies and logs name the person, not the shared service account.

PAM

Blocks and LIMIT rewrites

Block a session at login or a query before Snowflake runs it. Formal adds a LIMIT to unbounded queries or lowers a higher one.

PAM

One audit log across databases

Snowflake queries land in the same log as your other resources, with the query as received and as sent.

PAM

Time-bound exceptions

Suspend one policy for one user or group, for matching requests and a time window, instead of granting a role for good.

“Implementing Formal was a game-changer for our data management strategy. The ability to seamlessly integrate and gain deep insights into our data consumption significantly improves our user management.”

Nicoleta Iordachi

Data Platform Manager, ManoMano

7M+Active users

500Employees

$700MCapital raised

0User disruption

Read the full story ›

Snowflake roles decide what a role can read. They can’t tell which analyst is behind the BI service account that holds the role, and Snowflake’s own audit trail names that shared user. Formal adds Snowflake access control at the proxy, on top of native Snowflake security: every session, query and result is checked against the person or agent who sent it.

How does Formal extend Snowflake access control beyond RBAC?

In Snowflake RBAC, privileges are granted to roles and roles are granted to users. That model gets thin when many people share one Snowflake user (a BI tool, an internal app, an agent), and when the same rules must also hold on Postgres or MySQL.

Formal’s Connector is a reverse proxy in your VPC that works as a Snowflake proxy for your clients. People and agents log in with their Formal identity, and the Connector authenticates to Snowflake with a Native User credential it holds, so nobody handles Snowflake secrets. Snowflake still enforces the grants on that Native User: your roles stay the outer boundary.

On top, PAM policies written in Rego run at session (login), request (before the query runs) and response (on the rows coming back). They can use the Formal user, their groups, the BI end user and the Snowflake role used to connect (input.snowflake.role). One policy can cover several databases with included_technologies := ["postgres", "mysql", "snowflake"].

How does Snowflake data masking work through Formal?

Snowflake’s native Dynamic Data Masking uses masking policies: schema-level objects attached to columns and evaluated at query time by role and execution context (Enterprise Edition or higher). The MASKING_POLICIES and POLICY_REFERENCES views show which masking policy is set where.

Formal masks at the Connector, after Snowflake returns the rows. The decision uses the Formal identity and groups, including the end user behind a BI tool (input.end_user.groups), so two analysts on the same Metabase connection can see different values. Mask types include nullify, salted or deterministic hashing (deterministic keeps joins working), fake values and redaction.

The two layers stack: Snowflake applies its masking policies first, then Formal masks what comes back. Drivers download large result sets as chunks from cloud storage; the Connector proxies those downloads through its s3. subdomain and masks the chunks too. For masking across databases, see data masking.

Who ran the query behind a shared BI service account?

Most BI tools connect to Snowflake as one service account, and Snowflake’s ACCESS_HISTORY view records the user that ran each statement: that shared user. Formal resolves the person instead, through end-user identity propagation:

Omni sends a QUERY_TAG with the user’s Omni ID at login. Every query in that session belongs to that user.
Metabase, Sigma, Hex and custom apps append a SQL comment with the user’s external ID to each query.
Looker passes the user’s email in the JDBC connection options (formal_enduser).

The Connector maps each ID to a Formal user, then policies evaluate input.end_user and logs show the end user next to the machine user. Setup per tool is in the BI integrations guide. For why this matters when the BI tool itself is the target, read the Metabase zero day.

How do you keep Snowflake audit logs across databases?

Every Snowflake query through the Connector is logged with the Formal user, the end user and their groups, the query as received and as sent after any rewrite, and the policies it triggered. It lands in the same log as your other resources, and log integrations export it to S3, Google Cloud Storage, Azure Blob Storage, Datadog, Splunk or Panther.

Keep Snowflake’s access history for column lineage inside the warehouse; use Formal’s log to answer who, across systems. ManoMano uses Formal across Metabase, Snowflake and Postgres. Its case study reports full visibility into data access patterns across the three, policies enforced on Okta groups, and former employees found with active Metabase jobs.

How do approvals and time-bound Snowflake access work?

Instead of granting a role for good, create a policy suspension: an exception to one policy for one user or group, limited to matching requests and a time window. Approving an access request creates one, and Workflows can create one as an action.

Frequently asked questions

What are the best practices for access control in Snowflake?

Good Snowflake access control starts with roles: grant privileges to roles, keep ACCOUNTADMIN to a small, controlled set of users, and attach masking and row access policies to sensitive objects. Then cover what roles can’t: one identity per person and agent instead of shared logins, per-user masking, central query logs and time-bound exceptions instead of standing grants. Formal adds those four to your Snowflake security setup.

Does Formal replace Snowflake masking policies?

No. Native Snowflake data masking applies masking policies inside the warehouse, by role and execution context. Formal masks the result at the Connector, by Formal user, group or BI end user, and the same rule can cover Postgres or MySQL. Keep native masking policies where they work; add Formal where one Snowflake user serves many people.

How does Formal identify users behind a BI service account?

Through end-user identity propagation. Omni sends the user’s ID in QUERY_TAG at login, Metabase and custom apps add a SQL comment with an external ID to each query, and Looker passes the user’s email in the JDBC options. Formal maps the ID to a user, so policies and logs use the person. See the BI integrations guide.

Is this the same as Snowflake row access policies?

No. Row-level security in Snowflake uses row access policies: schema-level objects, evaluated by Snowflake, that decide which rows a query returns. Formal works at the proxy on sessions, queries and result columns, keyed to the identity behind the connection. Keep row access policies for row filtering and use Formal for identity-aware blocking, masking and audit.

Which Snowflake clients work through Formal?

The docs cover the Snowflake CLI (snow) with password or SNOWFLAKE_JWT authentication, Retool over JDBC, Omni through a host override, and Looker through JDBC options. Each client connects to account.<connector-hostname> with your account identifier and an authenticator that matches the Native User. See the Snowflake guide.

Can AI agents query Snowflake through Formal?

Yes. An agent connects as a Formal machine user (the docs list AI code agents as a machine user use case), for example with key-pair authentication. The same Snowflake security policies apply: block sessions or queries, add a LIMIT to unbounded queries, mask columns, and log every query under the agent’s identity.

Ready to (zero) trust your agents?

One network security layer for every agent and human, from the laptop to production.

Get a demo ›