Snowflake integration

2. Connection and scope

Seedling verifies the provider account before storing the workspace connection. A current Seedling workspace administrator controls installation and disconnect; account identity is never inferred from an email address or display name.

Key-pair service user

Create a dedicated Snowflake user with an RSA public key, a least-privilege role, warehouse USAGE, and metadata access to explicitly included databases and schemas.

Connection ownership

This connector is workspace-only. A current Seedling workspace administrator controls installation, credential replacement, disconnect, and purge for the exact connection.

3. Snowflake data Seedling accesses

Seedling uses synchronized information for source-backed search, operating context, verification, and customer-approved workflows. Availability depends on the connected account, selected resources, provider plan, and native permissions.

Warehouse structure

Databases, schemas, tables, views, columns, types, constraints, relationships, and relation metadata.

Authorization and governance

Roles, role inheritance, grants, managed-access context, row-access policies, masking policies, ownership, and external-user signals visible to the role.

Explicit exclusion

Application table rows and warehouse business-record values are not synchronized by the current metadata-only connector.

4. Read-only permission contract

Grant only the Snowflake capabilities required for metadata inventory.

• USAGE on the selected warehouse, databases, and schemas — establish bounded execution and namespace visibility.
• REFERENCES on approved tables and views — relation metadata without row reads.
• Optional SNOWFLAKE.OBJECT_VIEWER, SECURITY_VIEWER, and GOVERNANCE_VIEWER database roles — account inventory, grants, and policy context when approved.
• Database and schema include/exclude filters further bound the visible catalog.
• SELECT on business tables is not required; Seedling issues no DML, DDL, grant, role, warehouse, or policy mutation.

5. Security and access

• Provider credentials and other connection secrets are encrypted in the workspace tenant data plane, never returned to the browser, and excluded from logs and queue payloads.
• Every source, synchronization, secret lookup, audience contribution, disconnect, and purge remains bound to the exact connection that created it.
• The provider does not expose enough complete object-level audience evidence for Seedling to reproduce native permissions safely. Workspace content therefore uses the connection's restricted-by-default workspace-or-no-human-access policy; administrator and steward status grant no raw-content bypass.
• The PEM private key and passphrase are encrypted tenant credentials. Rotate with Snowflake's RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2 overlap rather than transferring keys through support.
• Generated output cannot bypass Seedling's human review, verification, and approval gates.

6. Retention and deletion

Connected data

Synchronized Snowflake records remain while the connection is active and are removed through a durable integration purge after disconnect.

Credentials

Stored Snowflake credentials or connection secrets and connection-owned synchronization state are deleted from active Seedling systems as part of the purge.

Backups

Deleted information may remain in encrypted, access-restricted backups until expiry, ordinarily within 35 days after active-system deletion.

7. Installation, help, and removal