Snowflake Gen AI Governance Study Guide — GES-C02

Snowflake Gen AI Governance

This domain covers securing and governing Gen AI workloads on Snowflake: who is allowed to call Cortex, which models can run and where inference physically happens, filtering unsafe model output, and applying Snowflake's existing data-governance primitives to AI pipelines rather than treating AI as a ungoverned side channel. Expect questions that name a specific control (a role, a parameter, a service) and ask what it does, plus scenario questions about data residency and cost control.

Access Control: SNOWFLAKE.CORTEX_USER

Access to Cortex LLM and AI functions is gated by the built-in SNOWFLAKE.CORTEX_USER database role. A role (user, custom role, or service) must be granted this database role before it can invoke Cortex functions at all.

GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE analyst;

This is the first gate in the access chain: even if a role has full SELECT privileges on every table a Cortex pipeline touches, it still cannot call AI_COMPLETE or any other Cortex function without SNOWFLAKE.CORTEX_USER. Revoking the role is the direct way to cut off Cortex access for a role without touching any of its other table-level grants.

Model Governance: CORTEX_MODELS_ALLOWLIST

The CORTEX_MODELS_ALLOWLIST account/session parameter restricts which specific models are permitted to run in the account. An organization that wants to standardize on a small, vetted set of approved models — for cost control, compliance review, or consistency — sets this allowlist so that calls referencing any other model are rejected, even if the caller otherwise has SNOWFLAKE.CORTEX_USER.

This is the control to reach for whenever a scenario says something like "the security team wants to ensure only approved models can be used for generative AI, even by users who otherwise have Cortex access."