Agent identity on Snowflake

Beta Enterprise Agent identity is behind the agent-identity feature flag. On Lightdash Cloud, ask Lightdash support to turn it on for your organization. On a self-hosted instance, enable the flag and set up the Snowflake agent integration. What Beta means.

AI agents run SQL in your warehouse. Without agent identity, the warehouse sees the same user for an agent query and for that person’s dashboard query. It cannot treat the two differently. Agent identity fixes this in two parts:

Lightdash marks every agent query. The mark is on every warehouse and needs no setting. On Snowflake, the mark is in the query tag.
Snowflake verifies agent sessions. Your organization can require each person to connect their agent through a separate Snowflake OAuth sign-in. Snowflake then knows that the session is an agent session. Your row access policies, masking policies, session policies and views can act on that.

The result: the warehouse, not Lightdash, enforces what agents may read. A person can see a value in a dashboard while their agent sees REDACTED. Lightdash’s own controls still apply on top. See Data access control. The verified agent session is available only for Snowflake. Connections to other warehouses get the query mark but are not affected by the organization rule. Jump to organization setup, connecting your agent, Snowflake policies or verification.

Who sees what

Signal	Where it appears	What it tells you
Agent mark	`query_tag` in Snowflake query history	Lightdash ran the query for an agent.
Agent session	`SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED')` inside the session	Snowflake verified the session as an agent session. Policies read this value.
Agent type	`agent_type = 'EXTERNAL_AGENT'` in `SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY`	Snowflake ran the query in a verified agent session.

A query tag alone does not prove that Snowflake verified the session. The agent session value and agent_type do.

Before you start

The Snowflake agent integration is set up for your instance. On Lightdash Cloud, Lightdash support sets it up. On a self-hosted instance, follow Agent identity on Snowflake.
Your project uses the same Snowflake account as the integration. An instance has one agent integration for one Snowflake account. A project on a second Snowflake account cannot complete the agent connection.
Each person has an allowed default role. Snowflake blocks the ACCOUNTADMIN, SECURITYADMIN, ORGADMIN and GLOBALORGADMIN roles from OAuth sessions. The agent sign-in uses the person’s default role. Each person who uses agents needs a default role outside that list.

The agent sign-in is separate from the person’s normal Sign in with Snowflake connection. A person can have both.

Require agent identity for your organization

Organization admins set one rule for the whole organization. It applies to every Snowflake connection in every project.

Open Warehouse credentials

Go to Organization settings → Warehouse credentials and find the Agent identity card.

Turn on Require agent identity

Turn on Require agent identity. The switch saves the rule at once.

Check the notification

A success notification confirms the save.

The Agent identity card on the Warehouse credentials page, with the Require agent identity switch turned on

If the instance has no Snowflake agent integration, the switch is disabled. The card shows the CREATE SECURITY INTEGRATION statement for your instance instead. While the rule is on:

Every AI query on a Snowflake connection must run through the person’s agent connection. Lightdash refuses queries from people who have not connected.
This covers chat, MCP, Slack and data app sample queries.
Every Snowflake connection form shows “Agent identity required by your organisation”, with a link to the organization settings.

The Type field of a Snowflake connection form with the read-only note Agent identity required by your organisation and an Organisation settings link

The switch does not create Snowflake policies. Without policies, agent sessions read the same data as the person. See Write Snowflake policies for agent sessions. Turning the rule off lets agents use the person’s normal credentials again, with the agent mark. It does not revoke Snowflake tokens that people already issued.

Connect your agent

Each person who uses agents connects their own agent once.

Open My warehouse connections

Go to Settings → My warehouse connections and find the Agent connection section.

Select Connect agent

Select Connect agent. A Snowflake sign-in opens in a popup.

Approve the sign-in

Sign in to Snowflake and approve the request. Lightdash checks that Snowflake marks the session as an agent session before it saves the connection.

The section then shows “Agent connected” and a Disconnect button.

My warehouse connections with the Agent connection section and a Connect agent button

To remove the agent connection, select Disconnect. AI features lock again for that person until they reconnect. This connection is separate from your personal warehouse connections. Dashboards and the SQL Runner keep using your normal credentials.

Before you connect

While the rule is on and a person has not connected their agent:

AI composers are hidden for Snowflake projects. This includes the Ask AI launcher, the homepage ask box and AI help in other parts of the app.
The agent chat shows a Connect your agent to your warehouse card with a Connect agent button. It opens the same Snowflake sign-in.
MCP and Slack refuse the query with: “Connect your agent to the warehouse once so it can run as you.”

The Connect your agent to your warehouse card with a Connect agent button

Write Snowflake policies for agent sessions

Snowflake owns the data rules. Your policies decide what agent sessions may read.

Lightdash does not create these policies. Adapt the examples to your data and existing policies before you attach them. Use a Snowflake role with the required policy privileges.

Each example reads SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED'). The value is true only in a verified agent session.

Hide rows from agents

A row access policy can exclude sensitive rows from agent sessions:

CREATE ROW ACCESS POLICY agent_rows
  AS (is_sensitive BOOLEAN) RETURNS BOOLEAN ->
    NOT COALESCE(SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED')::BOOLEAN, FALSE)
    OR NOT is_sensitive;
ALTER TABLE protected_records
  ADD ROW ACCESS POLICY agent_rows ON (is_sensitive);

Mask values from agents

A masking policy can hide a value from agent sessions:

CREATE MASKING POLICY agent_mask
  AS (value STRING) RETURNS STRING ->
    CASE WHEN SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED')::BOOLEAN
      THEN 'REDACTED'
      ELSE value
    END;
ALTER TABLE protected_records MODIFY COLUMN email
  SET MASKING POLICY agent_mask;

Use a view on Snowflake Standard Edition

Row access and masking policies need Snowflake Enterprise Edition. On Standard Edition, a view gives the same result for the columns it covers:

CREATE OR REPLACE VIEW customers_v AS
SELECT customer_id, name,
       CASE WHEN SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED')::BOOLEAN
            THEN 'REDACTED' ELSE phone END AS phone
FROM customers;

Point your dbt model at the view, not the table.

Limit what an agent session can do

A session policy can limit the privileges of an agent session:

CREATE SESSION POLICY agent_session_scope
  AGENT_RESTRICTED_SESSION_SCOPE = 'SNOWFLAKE$DATA_READ_WITH_AI';
ALTER USER example_user SET SESSION POLICY agent_session_scope;

The restricted scope limits the privileges the role already has. It does not grant new privileges. Review any existing session policy before you replace it. For the full Snowflake reference, see agent identity and restricted session scopes.

Verify the result

Run the same check in an agent session and in a normal session for the same person. For the agent session, ask an agent to run the SQL, for example in SQL mode or through the MCP run_sql tool. For the normal session, run it in a Snowflake worksheet as that person.

SELECT SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED') AS agent_activated,
       SYS_CONTEXT('SNOWFLAKE$SESSION', 'ACTIVE_RESTRICTED_SESSION_SCOPES') AS active_scopes;

agent_activated is true only in the agent session. Then inspect recent query history with a role that can read account usage:

SELECT query_id, start_time, user_name, role_name, agent_type, query_tag
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE start_time >= DATEADD('hour', -1, CURRENT_TIMESTAMP())
ORDER BY start_time DESC;

The agent query has agent_type = 'EXTERNAL_AGENT' and the Lightdash agent mark in query_tag. QUERY_HISTORY has an ingestion delay, so new queries can take a while to appear. See QUERY_HISTORY. Finally, query a protected table through an agent and as the person. Check that your row access, masking and session policies give the restrictions you expect.

​Who sees what

​Before you start

​Require agent identity for your organization

​Connect your agent

​Before you connect

​Write Snowflake policies for agent sessions

​Hide rows from agents

​Mask values from agents

​Use a view on Snowflake Standard Edition

​Limit what an agent session can do

​Verify the result

Who sees what

Before you start

Require agent identity for your organization

Connect your agent

Before you connect

Write Snowflake policies for agent sessions

Hide rows from agents

Mask values from agents

Use a view on Snowflake Standard Edition

Limit what an agent session can do

Verify the result