Snowflake

​

Overview

​

Available Tools

​

Admin: Setup in Snowflake

​

1. Create the OAuth Security Integration

CREATE SECURITY INTEGRATION dust_oauth
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = 'https://dust.tt/oauth/snowflake/finalize'
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 7776000;

​

2. Get the Client ID and Client Secret

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('DUST_OAUTH');

​

3. (Optional) Grant the integration to specific roles

GRANT USAGE ON INTEGRATION dust_oauth TO ROLE <role_name>;

​

Admin: Setup in Dust

• Account Identifier: Your Snowflake account identifier (e.g., abc123.us-east-1 or myorg-myaccount).
• Client ID: The OAUTH_CLIENT_ID from the security integration.
• Client Secret: The OAUTH_CLIENT_SECRET from the security integration.
• Warehouse: The warehouse to use for query execution (e.g., COMPUTE_WH). This warehouse is shared for all users.
• Role: The Snowflake role to use (e.g., ANALYST). In personal mode, users can override this during their authentication.

• Personal: Each user authenticates individually with their own Snowflake account. Queries run under each user’s credentials, respecting their individual Snowflake permissions. Users can override the default role during their personal authentication.
• Workspace: The admin authenticates once with a service account. All workspace users share that connection, no individual authentication is required. The role and warehouse are fixed by the admin.

​

Usage

​

With Personal credentials

​

With Workspace credentials

​

Adding Snowflake Tools to Agents

Our data warehouse is organized as follows:
- ANALYTICS database: contains our main reporting tables
- RAW database: contains raw ingested data

When querying Snowflake:
- Always start by exploring the schema using list_databases, list_schemas, list_tables, and describe_table before writing queries.
- Only use SELECT queries. Write operations are not supported.
- Prefer specific columns over SELECT * for better performance.
- Results are limited to 1000 rows per query.

​

What can I ask?

• “What databases do I have access to in Snowflake?”
• “List all tables in the ANALYTICS.PUBLIC schema.”
• “Describe the columns and types of the USERS table.”

• “How many active users signed up last month? Check the ANALYTICS.PUBLIC.USERS table.”
• “Show me the top 10 customers by revenue from the SALES table.”
• “What are the most recent orders in our system?”

• “Compare this month’s revenue to last month using our ANALYTICS tables.”
• “Find all users who haven’t logged in for 30 days.”
• “Summarize the distribution of order statuses in the ORDERS table.”

​

Snowflake Tool vs. Snowflake Connection

​

When to use the Snowflake Tool

• You need to query views (standard or materialized).
• You want per-user access control via personal credentials, so each user’s Snowflake role determines what they can see.

​

When to use the Snowflake Connection

• You want strict admin control over which specific tables agents can access, independent of Snowflake roles.
• You need to retrieve larger result sets (up to 25,000 rows).
• You prefer a simpler agent experience: agents query known, pre-configured tables without needing to explore the schema first.

​

Constraints

• Only read-only (SELECT) queries are supported. Write operations (INSERT, UPDATE, DELETE, MERGE, COPY) are blocked.
• Query results are limited to a maximum of 1000 rows per execution.
• Multi-statement queries (containing semicolons) are not allowed.
• The tool respects Snowflake role-based access control: users can only access data their role permits.