For the complete documentation index, see llms.txt. This page is also available as Markdown.

Security Model & Architecture

How SeeMore Data connects to Snowflake — the metadata we read, the data we never touch, and the access controls, encryption, and compliance behind it.

Tuning a Snowflake account for cost and performance doesn't require access to the data inside it — only to Snowflake's own metadata about how the account is used. That boundary is the foundation of SeeMore Data. This page sets out what SeeMore Data connects to, the metadata it reads, what it can never reach, and how the entire path is secured — the detail a security team needs to approve a deployment.


What we access — and what we never touch

SeeMore Data connects to Snowflake through a dedicated, least-privilege service user (seemore_user, role seemore_user_role) that you create during onboarding. For the core integration that role receives exactly two grants:

  • IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE — read Snowflake's own metadata database.

  • MONITOR USAGE ON ACCOUNT — observe account-wide usage and warehouse activity.

That is the entire footprint:

SeeMore Data reads
SeeMore Data never accesses

Query history, warehouse credit usage, storage metrics, clustering statistics, and object metadata — all from Snowflake's ACCOUNT_USAGE and ORGANIZATION_USAGE schemas

The contents of your tables, PII, or any proprietary business data

The role holds no SELECT privilege on your databases — it can only read Snowflake's metadata views. The full SQL lives on the Create Snowflake User and Privileges page.

Read-only by default; automation only if you opt in

The core integration is strictly read-only. Enabling an automation — Smart Pulse, Auto Shutdown, or Auto Scaler — adds the MANAGE WAREHOUSES privilege so SeeMore Data can adjust warehouse configuration (size, auto-suspend, auto-resume, scaling policy) to reduce your spend. It never reads or writes the data in your tables, and enabling it is entirely your decision.


How the connection works

Reading your metadata

  1. You create the service user with key-pair authentication — you generate the RSA key pair and keep the private key. SeeMore Data only ever holds credentials you choose to provision.

  2. If your account enforces a network policy, you allowlist SeeMore Data's fixed egress IP addresses (3.78.110.132, 3.73.171.134) so nothing else can use the connection.

  3. SeeMore Data connects as that user and reads from SNOWFLAKE.ACCOUNT_USAGE and SNOWFLAKE.ORGANIZATION_USAGE. The footprint on your account is minimal — typically $1–2 per day of compute.

  4. The metadata is pulled into SeeMore Data's per-customer isolated environment and encrypted in transit and at rest.

  5. SeeMore Data runs its analysis there and presents insights, recommendations, and — where you've turned them on — automations, in the web application.

Signing in to SeeMore Data

  • Authentication runs through your identity provider via Okta or Microsoft Entra ID SSO, or email login. Multi-Factor Authentication is supported and required for administrative access.

  • Authorization follows a clear role hierarchyOwner → Admin → Editor → Viewer — so each person gets only the access they need.

  • Isolation is logical and per-organization: no user can reach another organization's data.


Query Text Sanitization

SeeMore Data reads query history — including the text of each statement — to build lineage, attribute cost, and analyze how your queries run. Analyzing the query text is what lets SeeMore Data pinpoint bottlenecks and surface concrete optimization tips (see Query Analyzer). Throughout, that text is treated as metadata — a description of what ran, against which objects, and at what cost — never as a means to read the rows a query returns.

For teams with stricter obligations (HIPAA, PCI, GDPR), SeeMore Data can sanitize query text on request. Once enabled, literal values and sensitive comments are removed from every statement and replaced with placeholders before anything is stored, so the structure of the query is preserved for analysis while the values themselves are not:

Original

Sanitized

Independently of that setting, three controls always apply:

  • Statements that Snowflake itself returns as <redacted> are skipped entirely.

  • Access-control and identity statements — GRANT, CREATE USER, ALTER USER, masking-policy DDL — are never ingested.

  • An optional query-author allowlist lets you restrict ingestion to specific Snowflake users.

To turn on query-text sanitization or discuss a specific compliance requirement, contact security@seemoredata.io.


Snowflake metadata we read

Everything below is read from Snowflake's shared SNOWFLAKE database, granted read-only through IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE. For the exact grants, see the setup page.

Account Usage (SNOWFLAKE.ACCOUNT_USAGE)

Category
Views read

Query & access

QUERY_HISTORY, ACCESS_HISTORY, QUERY_ATTRIBUTION_HISTORY, QUERY_METERING_HISTORY

Warehouse & compute

WAREHOUSE_METERING_HISTORY, WAREHOUSE_EVENTS_HISTORY, WAREHOUSE_LOAD_HISTORY, QUERY_ACCELERATION_ELIGIBLE, QUERY_ACCELERATION_HISTORY, compute-pool and Snowpark Container Services usage history

Storage

TABLE_STORAGE_METRICS, DATABASE_STORAGE_USAGE_HISTORY, aggregated storage history

Object metadata

TABLES, COLUMNS, VIEWS, SCHEMATA, DATABASES, STAGES, PIPES, PROCEDURES, FUNCTIONS, USERS, TAGS, TAG_REFERENCES

Pipelines & maintenance

TASK_HISTORY, TASK_VERSIONS, PIPE_USAGE_HISTORY, COPY_HISTORY, MATERIALIZED_VIEW_REFRESH_HISTORY, AUTOMATIC_CLUSTERING_HISTORY, SEARCH_OPTIMIZATION_HISTORY

Performance

LOCK_WAIT_HISTORY, TABLE_PRUNING_HISTORY, COLUMN_QUERY_PRUNING_HISTORY

Cortex & AI usage

Cortex usage-history views across functions, Analyst, Agent, Search, Fine-Tuning, Cortex Code, Document Processing, and AISQL, plus SNOWFLAKE_INTELLIGENCE_USAGE_HISTORY

Organization Usage (SNOWFLAKE.ORGANIZATION_USAGE)

Available once the account is attached to the ORGADMIN role, for organization-wide and contract observability:

View
Purpose

USAGE_IN_CURRENCY_DAILY

Spend in your contract currency

RATE_SHEET_DAILY

Effective per-credit pricing

CONTRACT_ITEMS

Contract terms and capacity

ACCOUNTS

Accounts in the organization

Helper procedures

A few capabilities are backed by small helper procedures that SeeMore Data installs in a dedicated seemore.utils schema, each running as EXECUTE AS OWNER. They read object metadata — for example, listing streams, dynamic tables, and materialized views, or estimating clustering — or manage Cortex Code credit-limit parameters. None of them read your table data or query results. Their definitions and grants are on the setup page.

SeeMore Data is Snowflake-native. It also connects to transformation, orchestration, ingestion, and BI tools (dbt, Airflow, Fivetran, Tableau, Power BI, Looker) for end-to-end lineage and cost attribution — always through each tool's own metadata and APIs.


Certifications & compliance

  • SOC 2 Type II — audited controls for security, availability, and confidentiality.

  • GDPR & CCPA/CPRA — a Data Processing Agreement with Standard Contractual Clauses for cross-border transfers.

  • ISO 27001 — planned.

  • Independent testing — annual third-party penetration tests, with findings triaged and remediated through our risk-management process.

  • Fully auditable — every SQL statement SeeMore Data runs against your account is transparent and reviewable by your team.

For certifications, reports, and the complete list of controls, see the SeeMore Data Trust Center or write to security@seemoredata.io.


Hosting, encryption & retention

  • Hosting. SeeMore Data runs on AWS. You can connect a Snowflake account on any cloud — AWS, Azure, or GCP.

  • Encryption. Everything is encrypted in transit (TLS) and at rest, including your connection credentials.

  • Retention. Metadata is kept for 365 days and then deleted automatically. Enterprise customers can request a custom retention window.

Last updated