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.
SeeMore Data is SOC 2 Type II compliant and runs in production for large financial and healthcare organizations. We study how your queries and warehouses behave — never the contents of your tables.
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:
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.
These privileges expose metadata only — your actual data stays private and out of reach.
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
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.
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.SeeMore Data connects as that user and reads from
SNOWFLAKE.ACCOUNT_USAGEandSNOWFLAKE.ORGANIZATION_USAGE. The footprint on your account is minimal — typically $1–2 per day of compute.The metadata is pulled into SeeMore Data's per-customer isolated environment and encrypted in transit and at rest.
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 hierarchy — Owner → 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)
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:
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
