Snowflake test data, inside your network

What works today

Dedicated Snowflake connector: INFORMATION_SCHEMA discovery, declared keys, row counts from table metadata, bounded aggregate profiles and Arrow result reads processed inside your network.

Warehouse cost: discovery reads metadata only; profiles scan a bounded sample and every query runs on the configured warehouse under a statement timeout, tagged datanivra-agent. The driver ships in the standard agent image from agent 0.3.0.

Authentication: key-pair (secret reference); OAuth token (secret reference); password (secret reference).

Known limitations

• Key-pair authentication verified against a real Snowflake account; OAuth and password authentication are not part of the recorded run.
• Requires agent 0.3.0 or later; earlier agent images do not include its driver.
• Snowflake does not enforce declared foreign keys, so relationships may need explicit mappings.
• NUMBER(p,0) columns are carried as 64-bit integers; larger values fail the job with a reason code.

Capability matrix

Each capability is tracked separately and shown at the level the recorded conformance evidence supports. A connector that only discovers metadata is never presented as equivalent to one that runs the whole workflow.

Read-only proof

Proven before reading: the session disables secondary roles, then SHOW GRANTS for the connector role, every role it inherits and PUBLIC may hold only USAGE, SELECT, REFERENCES, MONITOR and READ on the source database; an administrative role, any privilege on a role or user, or an account-level privilege other than Snowflake's default feature switches refuses the source. Privileges confined to other databases or warehouses cannot modify the source and are tolerated.

Conformance evidence

DataNivra runs every connector through a common conformance kit on synthetic data: no write statements, proven read-only access, secret redaction, schema and relationship discovery, bounded streaming, cancellation, clear reason codes, egress canaries and no raw values in logs, then the discover, mask, subset, certify and provision workflow. The published status is computed from those results.

Connector version 0.1.0, last verified 2026-10-07.

What crosses the boundary

Connectors run inside the agent in your network. Only metadata, aggregates and evidence reach DataNivra Cloud:

• Schema, table and column names and data types (for file sets, operator-declared or opaque table names — never data-derived file names).
• Aggregates such as row-count estimates, null and distinct ratios; counts from 1 to 10 are reported as 10 (small-cell protection).
• Classification findings (which column looks like which kind of sensitive data) and relationship metadata.
• Evidence metadata: checksums, gate outcomes, engine and policy versions, and templated error codes.

Never sent:

• Any cell value, row, sample, minimum/maximum or top-k value — masked or not.
• Credentials, connection strings or resolved secret values: DataNivra stores only the secret reference.
• Free text copied from your data, or exception messages that contain values.

See the customer-resident architecture and how to verify these claims yourself.

Setup outline

1. Use agent 0.3.0 or later (earlier agent images do not include the Snowflake driver).
2. Create a role with USAGE on one small warehouse, the database and the schema and SELECT on its tables, and a key-pair service user whose default role it is (secondary roles off).
3. Store the connection document with the private key as a secret reference. Every query runs on the named warehouse under a statement timeout.
4. In the console, register the source with the secret reference of that document (for example vault://tdm/source-connection) and the agent that can reach it, then run discovery.
5. Before reading, the agent proves the role is read-only on the source database from SHOW GRANTS (inherited roles and PUBLIC included) and refuses to continue if it is not.

Example connection document, stored in your secret store and resolved by the agent locally (DataNivra only ever sees its reference):

{
  "kind": "SNOWFLAKE",
  "account": "myorg-claims",
  "user": "TDM_AGENT",
  "private_key_ref": "vault://tdm/snowflake-tdm-agent#private_key",
  "warehouse": "TDM_XS",
  "database": "CLAIMS_DB",
  "schemas": ["CLAIMS"]
}

Next: install the agent, then follow the getting started guide.