Security and data handling
Your model, your Snowflake account, and nothing in between.
Grain is a Snowflake Native App. It installs from Snowflake Marketplace and runs in a container inside your own Snowflake account. There is no Grain server and no desktop software. This page answers the questions your security team will ask.
Where data goes
Everything stays inside your account.
People open Grain from Snowsight and are signed in as their own Snowflake user. The model is stored in a table inside the app. Reading and changing your databases runs as the signed-in user. Nothing is sent to us.
Downloading the model as YAML is the only way model content leaves Snowflake, and only when a person chooses to.
Principles
What Grain does, and what it never does.
Nothing runs on its own
Grain touches your databases only for an action someone starts: Read Snowflake, Compare, Deploy, a Cortex request, reading lineage, or deploying tags. Opening a model reads nothing from your databases.
Read before write
Reading the schema is read-only. Deploy shows every statement first, asks you to tick each destructive one, runs them in order and stops at the first failure.
No credentials to manage
People sign in to Snowflake as they already do and open Grain from Snowsight. There are no passwords, tokens or keys to issue, store or rotate for Grain.
You set the outer limit
The app can reach only the databases and warehouse your administrator names with GRANT CALLER. Leave out OBJECT MANAGEMENT and Grain can't deploy anything.
Your role, your permissions
Reading and deploying run with restricted caller's rights, as the signed-in user and their role. Grain can never do more than that person could do themselves.
No telemetry
Grain collects no usage analytics, crash reports or model contents. We don't know what you model.
Cortex
What the assistant sees.
Cortex requests run in your Snowflake account, under your role, and are billed by Snowflake as part of your normal consumption. Grain sends design metadata only.
| Task | Sent to Cortex | Never sent |
|---|---|---|
| Complete, review, describe an entity | The entity's design, its relationships, your lexicons and house standards, Cortex context and organization profile | Rows from any table |
| Suggest subject areas | Table names, column names and types, comments and declared keys for the schemas you pick | Rows from any table |
| Design from requirements | The description you type | Anything else in your model |
| Import meeting transcript | The transcript you choose, in pieces | The transcript is not stored in the model. Only the summaries and links you adopt are saved. |
Every Cortex result waits for your review. Nothing it proposes is saved until you apply it, and an applied change can be undone in one step.
What the app may do
Two identities, each with limits you set.
Some work runs as the app itself, and some runs as the person using it. Neither can reach your data beyond what you grant.
| Acting as | Can | Cannot |
|---|---|---|
| The app itself | Use its own model table, warehouse and compute pool, and call Cortex | Read or change any of your databases |
| The app, for a signed-in user | What that user's role can do, and what your GRANT CALLER statements allow | Anything beyond either |
- Privileges the app asks for at install: create its own compute pool (one extra-small node), create its own extra-small warehouse, and a service endpoint so the people you grant can open it.
- Edits are attributed to the Snowflake user who made them.
- Read-only mode is a shared app setting for review periods.
- Upgrades arrive through Snowflake's Native App versioning, and the model table is untouched.
For your review
Questions security teams ask.
Does Grain need network access outside Snowflake?
No. The app has no external access integration, so its container cannot reach the internet. People reach it through Snowsight, and nothing is installed on their machines.
Which Snowflake privileges does it need?
At install, the app asks to create its own compute pool and warehouse and to bind a service endpoint. After that, an administrator grants CALLER USAGE and CALLER OBJECT DISCOVERY on each database to read schemas, CALLER OBJECT MANAGEMENT to deploy tables and tags, CALLER USAGE on a warehouse, and the SNOWFLAKE.CORTEX_USER database role for Cortex. Each person still needs their own role's privileges on the objects. Lineage needs Snowflake Enterprise Edition. See the setup script.
Can we keep Grain read-only?
Yes. Don't grant CALLER OBJECT MANAGEMENT, and Grain can read schemas and compare but never deploy. Modelers can still generate DDL and export it as .sql for your own change process.
Can someone deploy by accident?
Deploy shows the full plan first. Each destructive statement needs its own acknowledgement, and nothing runs until you choose Run. For stricter control, have Grain export the script as .sql and run it through your existing change process instead.
Where is the model stored, and in what format?
In a table inside the app, in your Snowflake account, as plain YAML documents. Anyone using the app can download them as a zip of the er-model folder, readable without Grain. The model belongs to you.
Has the app been reviewed by Snowflake?
Every version of a Native App published on Snowflake Marketplace goes through Snowflake's security review before customers can install it. [Confirm review status of the current version.]
Do you have SOC 2, ISO 27001 or a completed security questionnaire?
[State current compliance status and how to request documentation.] Because Grain runs inside your account and sends nothing to us, most reviews focus on the app's privileges and the grants you make.
Need something for your security review?
We'll walk your team through the permissions, the data flow and the deploy safeguards.