Snowflake Cortex Security: A Preventive Hardening Review

A Cortex AI request is admitted by several independent decisions. Snowflake privileges determine who may invoke an AI function. Model RBAC limits which models a role may use. Account settings influence inference geography. Cortex AI Guardrails cover named product surfaces, while the Trust Center AI Security tab reports scanner coverage and findings. I want to test these controls in that order because a permitted SQL call and a green scanner chart answer different security questions.

TL;DR

• Narrow USE AI FUNCTIONS and per-function privileges before testing model behavior. Narrow Snowflake database roles too.
• Use model RBAC as the current control for model access. Treat CORTEX_MODELS_ALLOWLIST as a deprecated mechanism rather than the long-term design.
• Review CORTEX_ENABLED_CROSS_REGION against approved processing locations and test the effective account configuration.
• Enable the AI Security scanner package and verify Cortex AI Guardrails scope by product surface. Assign an owner for each failed-path test.

Privileges define who can invoke Cortex AI

Snowflake's Cortex AI privilege and access guidance says Cortex AI Function access requires the USE AI FUNCTIONS account privilege or an applicable USE AI FUNCTION <name> privilege, plus the relevant Snowflake database role. The page also describes broad USE AI FUNCTIONS and SNOWFLAKE.CORTEX_USER grants to PUBLIC by default and provides procedures for narrowing them.

Begin with role inventory. List every production role that inherits the account privilege and every per-function grant. Include each assigned database role such as CORTEX_USER or AI_FUNCTIONS_USER. Remove unintended inheritance in a test account, then execute one permitted function and one denied function under named roles. Preserve the grant output and SQL error.

A role tree printed on a single sheet, with PUBLIC circled in red, is more useful than a generic access-control statement. It shows the inheritance path that an engineer can remove or justify.

Model RBAC is the current access mechanism

The same Snowflake guidance recommends model RBAC for fine-grained model access. It treats CORTEX_MODELS_ALLOWLIST as deprecated and documents a transition beginning in August 2026 that prevents changing the parameter to a new value other than None, ahead of planned removal later in 2026.

Build the target state around model objects and role grants. Define which roles need each model according to approved data and use cases. Test a permitted model under the intended role, then request a model outside that grant. Store the exact role and model identifier. Preserve the SQL and outcome.

I would block a production launch that still presents an allowlist spreadsheet as the primary long-term Cortex model control. Snowflake has identified RBAC as the forward path. Architecture documents and runbooks should follow that mechanism now, before the deprecated parameter becomes an emergency migration task.

Inference geography needs an account decision

Snowflake's cross-region inference documentation says CORTEX_ENABLED_CROSS_REGION controls cross-region inference at account level. Snowflake states that source customer data remains stored in the account region. Prompt and response payloads can be transmitted transiently to the processing region and are not persisted there.

Security and privacy owners should approve the effective value against the organization's processing-location requirements. Record the account region, permitted processing regions, selected setting, owner, and review date. Then run a supported model request and capture the inference-region evidence available for that path.

The control question concerns permitted transient processing. Data residency diagrams often show the database region and stop there. Add the inference region and payload path explicitly. This catches the architecture gap between stored customer data and transient prompt processing.

Guardrails have a named product scope

Snowflake's Cortex AI Guardrails documentation places the control within the Snowflake Horizon Catalog. Current documentation describes prompt-injection protection for named clients including CoCo and Snowflake CoWork. Cortex Agents are also named. Advanced protection scans tool outputs for indirect prompt injection, uses account-level AI_SETTINGS, and depends on supported cross-region inference.

Record guardrail status by product surface. Test a synthetic direct injection and a synthetic indirect instruction returned by a controlled tool. Keep the configured AI_SETTINGS and selected client. Also keep the inference requirement, timestamp, and observed outcome. Avoid extending the result to every Cortex AI Function. Coverage follows the named client and configuration described by Snowflake.

Zero trust for AI adds a separate request authorization principle: an authenticated caller still needs a decision for this prompt, model, data class, and purpose. Native Cortex guardrails address their documented prompt-injection path. Snowflake privileges and external request policy retain separate jobs.

Trust Center turns configuration into findings

The Trust Center AI Security tab centralizes visibility for Cortex Agents, AI Security scanner coverage, Cortex AI Guardrails status, and scanner-reported violations or detections. Access uses documented Trust Center roles such as SNOWFLAKE.TRUST_CENTER_VIEWER and SNOWFLAKE.TRUST_CENTER_ADMIN.

Snowflake's Trust Center overview says the charts depend on enabling the AI Security scanner package. Snowflake recommends that package for accounts using AI features, especially Cortex Agents and Snowflake CoWork. Cortex Code is also included in that recommendation.

Enable the package under an approved administrator and verify that the expected accounts and components appear. Assign each finding an owner and due date. Then test viewer access with a read-only security role. A blank chart can mean missing scanner coverage, so evidence should include scanner status rather than only a screenshot of the chart.

Preventive review assigns controls and owners

Use six hardening rows, each with an owner and a denied-path test.

• Function invocation: Snowflake security owns account and per-function privileges. The completion test is a permitted function under one role and a denied function under another.
• Model access: the AI platform owner defines model grants through RBAC. The completion test requests one approved and one unapproved model.
• Inference geography: privacy and cloud security approve the account setting and supported regions. Evidence captures effective configuration and observed region metadata.
• Runtime guardrails: the AI platform owner maps Cortex AI Guardrails to each named client and tests direct and indirect injection cases.
• Security scanning: the Snowflake administrator enables the AI Security scanner package. The Trust Center owner triages resulting findings.
• External request policy: customer applications route authenticated HTTP LLM calls through a policy point when the architecture exposes that route.

The post-authentication gap is relevant to that final row. A valid Snowflake role can invoke an approved model while the prompt still violates an enterprise purpose or data-handling rule. Inline policy can decide that routed request before inference. Internal SQL and managed Cortex processing stay under Snowflake controls.

This is a preventive architecture review. Audit views can confirm grants and usage after the tests. They can also confirm findings, but evidence joins and assessor-package construction belong in the separate Cortex audit-log discipline.

DeepInspect

This is the gap DeepInspect closes. DeepInspect is a stateless proxy for routed authenticated HTTP AI traffic between users or agents and LLM endpoints. When a customer-controlled application sends a model request through that path, DeepInspect evaluates application-supplied identity, role, prompt classification, destination, and versioned policy before forwarding it.

Snowflake continues to enforce Cortex privileges, model RBAC, inference configuration, Trust Center findings, and native guardrails. Direct Snowsight SQL, internal Cortex AI Function execution, internal tool calls, and Snowflake-managed agent processing remain outside DeepInspect's interception boundary unless the architecture explicitly exposes and routes the relevant HTTP request. Book a technical deep dive at deepinspect.ai.