Cross-Region AI Inference, Data Residency and Sovereignty: How Snowflake Is Designed to Earn Your Trust
The question every enterprise CISO is asking
The moment AI becomes part of a regulated workflow, a predictable question arrives from the security and compliance team:
"Where does my data go when I call an AI function? Can it leave my region? Can it leave my cloud provider? Is it stored anywhere? Is it cached?"
These are not hypothetical concerns. They are the questions that block AI adoption in financial services, healthcare, the public sector and many organizations subject to GDPR, NIS2, DORA or sector-specific data residency mandates.
This blog provides an architecture-grounded deep-dive into Snowflake's AI security model — how Snowflake Cortex AI handles inference, what happens when inference crosses a region boundary, how AI outputs are classified and protected by your encryption keys, how Snowflake Horizon Catalog provides a robust governance layer over every AI interaction. It also covers Cortex Code, Snowflake's AI coding assistant, which follows the same end-to-end security model.
Part 1: The architecture — what actually happens when you call an AI model
Three scenarios, one security boundary
Snowflake Cortex inference works across three architectural patterns. Understanding which applies to your deployment is the foundation for every data residency conversation.
We define two types of models:
Self-hosted models: Open models that run on Snowflake GPUs, such as Mistral, DeepSeek, Llama and Snowflake models.
Frontier state-of-the-art models (STOM): The models provided by OpenAI, Anthropic and Gemini, which run on CSP infrastructure (aka closed models)
No model vendor lock-in
Snowflake Cortex AI supports a broad portfolio of both self-hosted open-source and frontier models, all accessible through a single, unified API. If a specific model becomes unavailable in a region or is discontinued by its provider, customers can seamlessly switch to any other model in the catalog — without changing their application code or data pipelines. This model-agnostic architecture helps eliminate AI vendor lock-in at the infrastructure level.
Scenario 1 — Same-region inference (self-hosted models)
This is the most straightforward case. Your Snowflake account and the GPU cluster hosting the model are in the same CSP region.
Key properties and Snowflake security boundary:
- Snowflake does not use Customer Data to train, retrain or fine-tune any model it uses.
- Snowflake does not use metadata or Usage Data to train, retrain or fine-tune any model that Snowflake makes available for use by other parties.
- Self-hosted models run on Snowflake GPUs in the same region within the Snowflake CSP tenant — in this scenario, inference data never leaves the cloud provider.
- All AI-related communication uses TLS within the Snowflake internal network.
- There is no direct access to the inference network from outside of the Snowflake network.
- Customer inputs, outputs and logs are stored encrypted at rest.
- User identity and security are mapped end-to-end across all Cortex capabilities.
- No customer-controlled code runs on the GPU cluster. Snowflake controls all GPU resources and software as part of Snowflake's secure software development lifecycle.
Scenario 2 — Cross-region inference (self-hosted models)
When a model isn't available in your local region and cross-region inference is enabled, requests travel from a source Snowflake region to a destination Snowflake region.
Key properties and Snowflake security boundary:
- Customers can explicitly control cross-region inference.
- Inference traffic between regions is mTLS-encrypted.
- Same CSP: If the source region and inference region are in the same CSP, then the traffic stays on the CSP private backbone (for example, AWS → AWS: AWS global network).
- Cross-CSP: If the source region and inference region are not in the same CSP, then traffic travels over the internet, but it's encrypted end-to-end with mTLS.
- The destination inference region does not allow direct access — all access is orchestrated via Snowflake security defense-in-depth layers (next picture).
- User identity and security are mapped end-to-end across regions.
- Customer inputs, outputs and logs are stored encrypted at rest and with no persistence caching in the inference region.
Why mTLS and not just TLS?
Standard TLS (Transport Layer Security) provides unidirectional authentication — the client verifies the server's identity. Mutual TLS (mTLS) adds bidirectional authentication: Both the client and the server present certificates and verify each other. This helps prevent:
- Unauthorized nodes joining the Snowflake internal inference network
- Traffic injection from untrusted sources between regions
Snowflake manages the certificates and provisioning according to best practices, such as strong cipher suites, certificate rotation and the use of forward secrecy. For cross-region inference, Snowflake enforces mTLS on the Cortex Proxy to Cortex Proxy channel — the path where data physically crosses regional or CSP boundaries.
Scenario 3 — Frontier model access (state-of-the-art models (STOM))
For closed models — Claude (Anthropic on AWS Bedrock), GPT (Azure OpenAI) and Gemini (GCP) — the architecture uses the same proxy flow, terminating at the CSP-hosted frontier model endpoint instead of a Snowflake GPU cluster.
Key properties and Snowflake security boundary:
- Neither Snowflake nor the frontier model providers use Customer Data to train the models.
- Customers can explicitly control cross-region inference.
- Inference traffic between regions is mTLS encrypted.
- Same CSP: If the source region and inference region are in the same CSP, then the traffic stays on the CSP private backbone (for example, AWS → AWS: AWS global network).
- Cross-CSP: If the source region and inference region are not in the same CSP, then traffic travels over the internet, but it's encrypted end-to-end with mTLS.
- The destination inference region does not allow direct access — all access is orchestrated via Snowflake security layers.
- User identity and security are mapped end-to-end across regions.
- Customer inputs, outputs and logs are stored encrypted at rest.
Part 2: Data classification
The three types of data in Snowflake AI
There are three distinct categories:
| Data category | Data types | Data usage |
|---|---|---|
| Customer Data | Your tables, files and structured records. AI Outputs are generally classified as Customer Data (with a small exception described below) and are always encrypted at rest and in transit to and from Snowflake. | By default, Snowflake does not access Customer Data in the ordinary course without a valid justification, such as a customer-initiated support request. Customer Data is not used to train, retrain or fine-tune any models. |
| Usage Data | Metrics, telemetry, usage and operations data in connection with the customer's use of Snowflake, including query logs and metadata (for example, object definitions and properties) | Accessible to Snowflake personnel involved in day-to-day operations. Usage Data is not used to train, retrain or fine-tune any model powering Cortex AI Features that Snowflake makes available for use by other parties |
| AI Data | Any AI Inputs or Outputs that are not Customer Data. Examples: Output that consists of a SQL query suggestion generated by Cortex Analyst. | Restricted to limited Snowflake personnel who have a legitimate business reason to access. AI Data is not used to train, retrain or fine-tune any model powering Cortex AI Features that Snowflake makes available for use by other parties |
AI outputs are treated as customer data
AI Outputs stored within your Snowflake account are protected by your full encryption stack:
- Encrypted at rest using an encryption key hierarchy — the same keys that protect your tables, files and structured data.
- Governed by your RBAC policies — only authorized users can access stored outputs; accessible for compliance audits via SNOWFLAKE.LOCAL.AI_OBSERVABILITY_EVENTS
Part 3: Tenant isolation at the GPU level
One of the most technically sophisticated aspects of Snowflake's inference architecture is how it achieves multi-tenant GPU isolation at the software level.
Key isolation properties:
- No customer-controlled code runs on GPU nodes — only Snowflake-controlled inference code runs there for self-hosted models, or the model provider's code for frontier models.
- Different customers' inputs and outputs exist as different rows encrypted at rest with separate keys — they do not interact with each other.
- The system enforces isolation by job, user, role, Snowflake account and other context IDs — not addressable or readable across tenants. These identifiers are carried across all Snowflake data and AI services.
- Snowflake uses this same software-isolation model across all serverless features (such as Snowpipe, replication and annual rekeying).
Part 4: AI governance with Snowflake Horizon Catalog
The problem with governance outside the data boundary
Most enterprises today face a governance gap: Their data platform has strong controls (RBAC, masking, audit), but when data is extracted and sent to an external AI platform, their governance framework becomes fragmented — or disappears entirely.
Governance controls are enforced before the model sees anything
A critical point for regulated customers: Snowflake's governance layer executes before any data reaches an AI model.
The flow is:
- User invokes a Cortex function or AI agent.
- Role-based access control (RBAC) is resolved — effective permissions determined.
- Column masking policies applied — PII and sensitive columns masked or tokenized.
- Row access policies applied — only authorized rows included.
- Model allowlist checked — function blocked if the model is not on the approved list.
- Cross-region policy checked — request blocked if cross-region is not enabled.
- Only then does the processed, governed data reach the inference layer.
This process is designed so that the AI model never sees data the user isn't authorized to access, regardless of what prompt the user constructs.
Auditing and monitoring: full visibility into AI operations
Snowflake Horizon provides auditability of all AI interactions:
-- All Cortex function calls with tables/columns accessed
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_FUNCTIONS_USAGE_HISTORY;
-- Cortex Analyst generated queries
SELECT user_name, generated_sql, timestamp
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_ANALYST_USAGE_HISTORY;
-- Full AI observability including inputs/outputs
SELECT * FROM SNOWFLAKE.LOCAL.AI_OBSERVABILITY_EVENTS;Part 5: Cortex Code — the same trust model
Cortex Code is Snowflake's AI-powered coding and data engineering assistant. Architecturally, it is built on top of Cortex Agents — which means everything covered in Parts 1–6 applies directly:
Note: The Cortex Threads (for persistent conversation history) can be configured to store messages encrypted with a customer-managed key with Tri-Secret Secure (TSS). Support with configurable retention (default 180 days, reducible via account parameter).
Part 6: Customer controls
Here is a practical, field-ready configuration baseline for regulated customers:
We have controls that help customers manage servers at the account level, model level, function level, data level and with fine-grained access control.
General controls
These are catch-all types of controls:
SNOWFLAKE.CORTEX_USER
Primary role for all Covered AI Features (AI Functions, Agent, Analyst, Fine-tuning, Search, REST API). Granted to PUBLIC by default — all users have access.
Recommendation: Remove this role and use more specific roles as detailed below, unless you would like to experiment with all Cortex features
REVOKE DATABASE ROLE SNOWFLAKE.CORTEX_USER FROM ROLE PUBLIC;
REVOKE IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE FROM ROLE PUBLIC;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE my_role;Account-level controls
These controls are at the account level and impact all sessions, services and users:
Set default cross-region policy (locked down)
ANY_REGION for new accounts (created after March 2026). ACCOUNTADMIN only. Controls cross-region inference routing for all Cortex AI features. Values: ANY_REGION, AWS_US, AWS_EU, AWS_APJ, AWS_GLOBAL, AZURE_GLOBAL, DISABLED or comma-separated combinations.
-- Ensure cross-region is disabled (this is the default)
ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'DISABLED';
-- If cross-region is required scope it to specific regions and use the opt-in model allowlist to limit which models are accessible cross-region.
ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'ANY_REGION OR REGION';CORTEX_MODELS_ALLOWLIST
Account-level parameter controlling which LLM models are available. Values: 'All', 'None' or comma-separated model names. Default is 'All' — all models accessible. ACCOUNTADMIN only.
ALTER ACCOUNT SET CORTEX_MODELS_ALLOWLIST = 'llama3.1-70b,mistral-large2';
ALTER ACCOUNT SET CORTEX_MODELS_ALLOWLIST = 'All';Guardrails (recommended)
Configure Cortex AI Guardrails for prompt injection detection and jailbreak prevention on Cortex Code. Requires cross-region inference enabled (ANY_REGION, AWS_US or AWS_GLOBAL). Guardrails OFF by default. Must be explicitly enabled by ACCOUNTADMIN.
ALTER ACCOUNT SET AI_SETTINGS = $$
guardrails:
advanced_prompt_injection:
- enabled: true
$$;
ALTER ACCOUNT UNSET AI_SETTINGS;Observability
READ UNREDACTED AI OBSERVABILITY EVENTS TABLE
Controls visibility of unredacted content (tool I/O, conversations, feedback) in AI_OBSERVABILITY_EVENTS. OFF by default — roles only see metadata (tool names, latency, token usage). No raw content.
REVOKE READ UNREDACTED AI OBSERVABILITY EVENTS TABLE ON ACCOUNT FROM ROLE my_role;
GRANT READ UNREDACTED AI OBSERVABILITY EVENTS TABLE ON ACCOUNT TO ROLE my_role;SNOWFLAKE.AI_OBSERVABILITY_READER (App Role)
Read-only access to SNOWFLAKE.LOCAL.AI_OBSERVABILITY_EVENTS for Agent monitoring, traces and user feedback. NOT granted by default. Must be explicitly granted by ACCOUNTADMIN.
REVOKE APPLICATION ROLE SNOWFLAKE.AI_OBSERVABILITY_READER FROM ROLE monitor_rl;
GRANT APPLICATION ROLE SNOWFLAKE.AI_OBSERVABILITY_READER TO ROLE monitor_rl;SNOWFLAKE.AI_OBSERVABILITY_ADMIN (App Role)
Admin access to AI_OBSERVABILITY_EVENTS, including the ability to delete entries. NOT granted by default. Must be explicitly granted by ACCOUNTADMIN.
REVOKE APPLICATION ROLE SNOWFLAKE.AI_OBSERVABILITY_ADMIN FROM ROLE admin_rl;
GRANT APPLICATION ROLE SNOWFLAKE.AI_OBSERVABILITY_ADMIN TO ROLE admin_rl;Fine-grain controls
These give customers more control on the top of what is being done at the general and account levels.
USE AI FUNCTIONS
Required (with a database role) to call Cortex AI Functions. Blanket access to all AI functions. Granted to PUBLIC by default — all users can call AI functions.
REVOKE USE AI FUNCTIONS ON ACCOUNT FROM ROLE PUBLIC;
GRANT USE AI FUNCTIONS ON ACCOUNT TO ROLE my_role;USE AI FUNCTION <name>
Per-function privilege (for example, only AI_COMPLETE). OR relationship with blanket USE AI FUNCTIONS. NOT granted by default. Must be explicitly granted by ACCOUNTADMIN.
REVOKE USE AI FUNCTION AI_COMPLETE ON ACCOUNT FROM ROLE analyst_rl;
GRANT USE AI FUNCTION AI_COMPLETE ON ACCOUNT TO ROLE analyst_rl;Cortex Analyst
ENABLE_CORTEX_ANALYST
Controls whether Cortex Analyst functionality is available in the account. Boolean parameter. Cortex Analyst is enabled by default.
ALTER ACCOUNT SET ENABLE_CORTEX_ANALYST = FALSE;
ALTER ACCOUNT SET ENABLE_CORTEX_ANALYST = TRUE;ENABLE_CORTEX_ANALYST_MODEL_AZURE_OPENAI (Deprecated)
Legacy parameter that routed Cortex Analyst requests to external Azure OpenAI models outside Snowflake. Deprecated — Snowflake no longer honors this parameter. Cortex Analyst now uses Snowflake-hosted models only.
SNOWFLAKE.COPILOT_USER
Required for Cortex Code access in Snowsight and CLI. Must be combined with CORTEX_USER or CORTEX_AGENT_USER. Granted to PUBLIC by default — all users have access.
REVOKE DATABASE ROLE SNOWFLAKE.COPILOT_USER FROM ROLE PUBLIC;
GRANT DATABASE ROLE SNOWFLAKE.COPILOT_USER TO ROLE my_role;CORTEX-MODEL-ROLE-ALL (Application Role)
Grants access to all current and future Cortex base models. Must run CORTEX_BASE_MODELS_REFRESH() first. Not created by default. Must be created via CORTEX_BASE_MODELS_REFRESH().
CALL SNOWFLAKE.MODELS.CORTEX_BASE_MODELS_REFRESH();
GRANT APPLICATION ROLE SNOWFLAKE."CORTEX-MODEL-ROLE-ALL" TO ROLE my_role;
REVOKE APPLICATION ROLE SNOWFLAKE."CORTEX-MODEL-ROLE-ALL" FROM ROLE my_role;CORTEX-MODEL-ROLE-<MODEL> (Application Role)
Per-model application role (for example, LLAMA3.1-70B). Created dynamically via CORTEX_BASE_MODELS_REFRESH(). Not created by default. Must be created via CORTEX_BASE_MODELS_REFRESH().
GRANT APPLICATION ROLE SNOWFLAKE."CORTEX-MODEL-ROLE-LLAMA3.1-70B" TO ROLE my_role;
REVOKE APPLICATION ROLE SNOWFLAKE."CORTEX-MODEL-ROLE-LLAMA3.1-70B" FROM ROLE my_role;SNOWFLAKE.CORTEX_ANALYST_USER
Cortex Analyst API access only — no AI Functions, Agent, Search or Fine-tuning. Use when CORTEX_USER has been revoked from PUBLIC. NOT granted to PUBLIC. Must be explicitly granted by ACCOUNTADMIN.
REVOKE DATABASE ROLE SNOWFLAKE.CORTEX_ANALYST_USER FROM ROLE analyst_rl;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_ANALYST_USER TO ROLE analyst_rl;SNOWFLAKE.AI_FUNCTIONS_USER
Scalar AI functions only (AI_COMPLETE, AI_CLASSIFY, and so on) — no Agent, Analyst, Search or Fine-tuning. NOT granted to PUBLIC. Must be explicitly granted by ACCOUNTADMIN.
REVOKE DATABASE ROLE SNOWFLAKE.AI_FUNCTIONS_USER FROM ROLE analyst_rl;
GRANT DATABASE ROLE SNOWFLAKE.AI_FUNCTIONS_USER TO ROLE analyst_rl;SNOWFLAKE.CORTEX_EMBED_USER
Embedding functions (AI_EMBED, EMBED_TEXT_768/1024) and Cortex Search Services with managed embeddings. NOT granted to PUBLIC. Must be explicitly granted by ACCOUNTADMIN.
REVOKE DATABASE ROLE SNOWFLAKE.CORTEX_EMBED_USER FROM ROLE embed_rl;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_EMBED_USER TO ROLE embed_rl;SNOWFLAKE.CORTEX_REST_API_USER
Cortex REST API (Chat Completions & Messages endpoints) only — no SQL AI functions, Agent, Analyst or Search. NOT granted to PUBLIC. Must be explicitly granted by ACCOUNTADMIN.
REVOKE DATABASE ROLE SNOWFLAKE.CORTEX_REST_API_USER FROM ROLE api_rl;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_REST_API_USER TO ROLE api_rl;SNOWFLAKE.CORTEX_AGENT_USER
Cortex Agents API and Snowflake Intelligence only — no AI Functions, Search or Fine-tuning. NOT granted to PUBLIC. Must be explicitly granted by ACCOUNTADMIN.
REVOKE DATABASE ROLE SNOWFLAKE.CORTEX_AGENT_USER FROM ROLE agent_rl;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_AGENT_USER TO ROLE agent_rl;Conclusion: Governance before the model, security at every hop
The key insight for regulated customers is this: Snowflake's security and governance controls execute before data reaches an AI model. The model doesn't see data the user cannot access. The cross-region path is mTLS-encrypted. And Horizon Catalog provides a single, unified governance plane across all three dimensions — data, capability and context.
This is not a feature list — it is an architectural commitment, solidified through extensive Snowflake security review, contractual commitments with CSPs and a platform design where the trust boundary has always been: Snowflake's code plus the cloud service provider.
Cross-Region AI Inference, Data Residency and Sovereignty: How Snowflake Is Designed to Earn Your Trust
Simpler, Safer URLs: Introducing Per-Account Hostnames for Snowflake App Services
What's New in Apache Polaris™ 1.6
