Privileges and model access for Cortex AI Functions¶

Cortex LLM privileges¶

Access to Snowflake Cortex AI Functions is gated by an account-level privilege and one of several database roles. Use the following sections to grant or revoke access at the account, role, or per-function level.

USE AI FUNCTIONS on the account privilege¶

The USE AI FUNCTIONS account-level privilege includes the privileges that allow your users to call Snowflake Cortex AI functions. By default, the USE AI FUNCTIONS privilege is granted to the PUBLIC role. The PUBLIC role is automatically granted to all users and roles, allowing all users in your account to use the Snowflake Cortex AI functions. If you don’t want all your users to have this privilege, you can revoke access to the PUBLIC role and grant access to other roles.

If you need finer-grained control over which AI functions individual roles can call, see USE AI FUNCTION <name> — per-function privileges.

To control which roles have the USE AI FUNCTIONS privilege:

• Revoke it from the PUBLIC role.
• Grant it to specific roles.

To revoke the USE AI FUNCTIONS account-level privilege from the PUBLIC role, run the following command:

REVOKE USE AI FUNCTIONS ON ACCOUNT
FROM ROLE PUBLIC;

After you’ve revoked the USE AI FUNCTIONS privilege from the PUBLIC role, you can use the ACCOUNTADMIN role to grant it to other roles in your Snowflake account.

The following example:

1. Grants the USE AI FUNCTIONS privilege to cortex_user_role.
2. Grants the cortex_user_role to example_user.

USE ROLE ACCOUNTADMIN;

CREATE ROLE cortex_user_role;

GRANT USE AI FUNCTIONS ON ACCOUNT TO ROLE cortex_user_role;

GRANT ROLE cortex_user_role TO USER example_user;

You can grant access to Snowflake Cortex AI Functions through roles that are commonly used by specific groups of users. For example, if you’ve created an analyst role that is used as a default role by analysts in your organization, you can grant these users access to Snowflake Cortex AI Functions with a single GRANT <privileges> … TO ROLE statement. For more information about granting privileges to commonly used roles, see User roles.

GRANT USE AI FUNCTIONS ON ACCOUNT TO ROLE analyst;

USE AI FUNCTION <name> — per-function privileges¶

In addition to the blanket USE AI FUNCTIONS privilege, you can grant per-function privileges using USE AI FUNCTION <name>. This allows ACCOUNTADMIN to control access at the individual function level instead of granting access to all AI functions at once.

The per-function privilege and the blanket USE AI FUNCTIONS privilege have an OR relationship:

• If a role has USE AI FUNCTIONS, it can call all Cortex AI functions, regardless of any per-function grants or revocations.
• If a role has only USE AI FUNCTION AI_COMPLETE, it can call only the AI_COMPLETE function.
• If a role has both USE AI FUNCTIONS and a per-function grant, revoking the per-function grant does not affect access because the blanket privilege still applies.

Supported per-function privileges¶

The following table lists each Cortex AI function and its corresponding per-function privilege name for use with GRANT USE AI FUNCTION <name> ON ACCOUNT TO ROLE <role_name>.

Granting per-function privileges¶

Use the ACCOUNTADMIN role to grant a per-function privilege. The syntax is:

GRANT USE AI FUNCTION <function_name> ON ACCOUNT TO ROLE <role_name>;

The following example revokes the blanket privilege from PUBLIC, then grants only AI_COMPLETE access to a specific role:

USE ROLE ACCOUNTADMIN;

-- Remove blanket access from PUBLIC
REVOKE USE AI FUNCTIONS ON ACCOUNT FROM ROLE PUBLIC;

-- Create a role with access to only AI_COMPLETE
CREATE ROLE ai_complete_user_role;
GRANT USE AI FUNCTION AI_COMPLETE ON ACCOUNT TO ROLE ai_complete_user_role;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE ai_complete_user_role;

GRANT ROLE ai_complete_user_role TO USER example_user;

You can grant multiple per-function privileges to the same role to build a custom set of allowed functions:

USE ROLE ACCOUNTADMIN;

CREATE ROLE ai_analyst_role;

GRANT USE AI FUNCTION AI_COMPLETE ON ACCOUNT TO ROLE ai_analyst_role;
GRANT USE AI FUNCTION AI_CLASSIFY ON ACCOUNT TO ROLE ai_analyst_role;
GRANT USE AI FUNCTION AI_EXTRACT ON ACCOUNT TO ROLE ai_analyst_role;
GRANT USE AI FUNCTION AI_TRANSLATE ON ACCOUNT TO ROLE ai_analyst_role;

GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE ai_analyst_role;
GRANT ROLE ai_analyst_role TO USER analyst_user;

Revoking per-function privileges¶

To revoke a per-function privilege:

REVOKE USE AI FUNCTION <function_name> ON ACCOUNT FROM ROLE <role_name>;

For example:

USE ROLE ACCOUNTADMIN;

REVOKE USE AI FUNCTION AI_COMPLETE ON ACCOUNT FROM ROLE ai_analyst_role;

After revocation, the role can no longer call AI_COMPLETE unless it also has the blanket USE AI FUNCTIONS privilege.

Viewing per-function grants¶

You can view per-function privilege grants using SHOW GRANTS:

-- View all grants to a specific role
SHOW GRANTS TO ROLE ai_analyst_role;

-- View all grants on the account
SHOW GRANTS ON ACCOUNT;

Per-function grants appear with the privilege name USE AI FUNCTION <function_name> (for example, USE AI FUNCTION AI_COMPLETE).

Using AI Functions with Restricted Caller’s Rights¶

To use AI Functions with Restricted Caller’s Rights, you must grant the USE AI FUNCTIONS privilege (or the appropriate USE AI FUNCTION <name> per-function privilege) to both the session role and the service or application owner role.

For example, to use AI Functions inside a Snowflake Park Container Services (SPCS) service that runs with Restricted Caller’s Rights:

1. Grant the USE AI FUNCTIONS privilege to the role used in the SPCS session (for example, CHATBOT_USER_ROLE):

   Copy codeExpand code block

   GRANT USE AI FUNCTIONS ON ACCOUNT TO ROLE CHATBOT_USER_ROLE;

   Show lessSee more

   Scroll to top

2. Grant the caller version of the privilege to the service owner role:

   Copy codeExpand code block

   GRANT CALLER USE AI FUNCTIONS ON ACCOUNT TO ROLE <service_owner_role>;

   Show lessSee more

   Scroll to top

CORTEX_USER database role¶

The CORTEX_USER database role in the SNOWFLAKE database includes the privileges that allow users to call Snowflake Cortex AI Functions. By default, the CORTEX_USER role is granted to the PUBLIC role. The PUBLIC role is automatically granted to all users and roles, so this allows all users in your account to use the Snowflake Cortex AI functions.

If you don’t want all users to have this privilege, you can revoke access to the PUBLIC role and grant access to other roles. The SNOWFLAKE.CORTEX_USER database role cannot be granted directly to a user. For more information, see Using SNOWFLAKE database roles.

To revoke the CORTEX_USER database role from the PUBLIC role, run the following commands using the ACCOUNTADMIN role:

REVOKE DATABASE ROLE SNOWFLAKE.CORTEX_USER
  FROM ROLE PUBLIC;

REVOKE IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE
  FROM ROLE PUBLIC;

You can then selectively provide access to specific roles. A user with the ACCOUNTADMIN role can grant this role to a custom role in order to allow users to access Cortex AI functions. In the following example, use the ACCOUNTADMIN role and grant the user some_user the CORTEX_USER database role via the account role cortex_user_role, which you create for this purpose.

USE ROLE ACCOUNTADMIN;

CREATE ROLE cortex_user_role;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE cortex_user_role;

GRANT ROLE cortex_user_role TO USER some_user;

You can also grant access to Snowflake Cortex AI functions through existing roles commonly used by specific groups of users. (See User roles.) For example, if you have created an analyst role that is used as a default role by analysts in your organization, you can easily grant these users access to Snowflake Cortex AI Functions with a single GRANT statement.

GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE analyst;

AI_FUNCTIONS_USER database role¶

The AI_FUNCTIONS_USER database role in the SNOWFLAKE database allows users to call Snowflake Cortex scalar AI functions (all Cortex AI functions except the aggregate functions AI_AGG and AI_SUMMARIZE_AGG) without granting access to Cortex services such as Cortex Agent, Cortex Analyst, Cortex Fine-tuning, or Cortex Search.

AI_FUNCTIONS_USER role is not granted to the PUBLIC role by default. Accountadmin must explicitly grant this role to roles that require access to AI functions. The AI_FUNCTIONS_USER database role cannot be granted directly to users but must be granted to roles that users can assume. For more information, see Using SNOWFLAKE database roles.

The following example creates a custom role, grants the AI_FUNCTIONS_USER database role to it, and assigns the role to a user.

USE ROLE ACCOUNTADMIN;

CREATE ROLE analyst_rl;
GRANT DATABASE ROLE SNOWFLAKE.AI_FUNCTIONS_USER TO ROLE analyst_rl;

GRANT ROLE analyst_rl TO USER some_user;

Alternatively, to give all users access to scalar AI function capabilities, grant the AI_FUNCTIONS_USER role to the PUBLIC role.

USE ROLE ACCOUNTADMIN;

GRANT DATABASE ROLE SNOWFLAKE.AI_FUNCTIONS_USER TO ROLE PUBLIC;

CORTEX_EMBED_USER database role¶

The CORTEX_EMBED_USER database role in the SNOWFLAKE database includes the privileges that allow users to call the text embedding functions AI_EMBED, EMBED_TEXT_768, and EMBED_TEXT_1024 and to create Cortex Search Services with managed vector embeddings. CORTEX_EMBED_USER allows you to grant embedding privileges separately from other Cortex AI capabilities.

Unlike the CORTEX_USER role, the CORTEX_EMBED_USER role is not granted to the PUBLIC role by default. You must explicitly grant this role to roles that require embedding capabilities if you have revoked the CORTEX_USER role. The CORTEX_EMBED_USER database role cannot be granted directly to users but must be granted to roles that users can assume. The following example illustrates this process.

USE ROLE ACCOUNTADMIN;

CREATE ROLE cortex_embed_user_role;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_EMBED_USER TO ROLE cortex_embed_user_role;

GRANT ROLE cortex_embed_user_role TO USER some_user;

Alternatively, to give all users access to embedding capabilities, grant the CORTEX_EMBED_USER role to the PUBLIC role as follows.

USE ROLE ACCOUNTADMIN;

GRANT DATABASE ROLE SNOWFLAKE.CORTEX_EMBED_USER TO ROLE PUBLIC;

Using AI Functions in stored procedures with EXECUTE AS RESTRICTED CALLER¶

To use AI Functions inside stored procedures with EXECUTE AS RESTRICTED CALLER, grant the following privileges to the role that created the stored procedure:

GRANT INHERITED CALLER USAGE ON ALL SCHEMAS IN DATABASE snowflake TO ROLE <role_that_created_the_stored_procedure>;
GRANT INHERITED CALLER USAGE ON ALL FUNCTIONS IN DATABASE snowflake TO ROLE <role_that_created_the_stored_procedure>;
GRANT CALLER USAGE ON DATABASE snowflake TO ROLE <role_that_created_the_stored_procedure>;

Control model access¶

Snowflake Cortex provides two independent mechanisms to enforce access to models:

• Account-level allowlist parameter (simple, broad control)
• Role-based access control (RBAC) (fine-grained control)

You can use the account-level allowlist to control model access across your entire account, or you can use RBAC to control model access on a per-role basis. For maximum flexibility, you can also use both mechanisms together, if you can accept additional management complexity.

Account-level allowlist parameter¶

You can control model access across your entire account using the CORTEX_MODELS_ALLOWLIST parameter. Supported features respect the value of this parameter and prevent use of models that are not in the allowlist.

The CORTEX_MODELS_ALLOWLIST parameter can be set to 'All', 'None', or to a comma-separated list of model names. Model names are case-sensitive and must be specified in lowercase (for example, 'mistral-large2' rather than 'MISTRAL-LARGE2'). This parameter can only be set at the account level, not at the user or session levels. Only the ACCOUNTADMIN role can set the parameter using the ALTER ACCOUNT command.

Examples:

• To allow access to all models:

  Copy codeExpand code block

  ALTER ACCOUNT SET CORTEX_MODELS_ALLOWLIST = 'All';

  Show lessSee more

  Scroll to top

• To allow access to the mistral-large2 and llama3.1-70b models:

  Copy codeExpand code block

  ALTER ACCOUNT SET CORTEX_MODELS_ALLOWLIST = 'mistral-large2,llama3.1-70b';

  Show lessSee more

  Scroll to top

• To prevent access to any model:

  Copy codeExpand code block

  ALTER ACCOUNT SET CORTEX_MODELS_ALLOWLIST = 'None';

  Show lessSee more

  Scroll to top

Use RBAC, as described in the following section, to provide specific roles with access beyond what you’ve specified in the allowlist.

Role-based access control (RBAC)¶

Although Cortex models are not themselves Snowflake objects, Snowflake lets you create model objects in the SNOWFLAKE.MODELS schema that represent the Cortex models. By applying RBAC to these objects, you can control access to models the same way you would any other Snowflake object. Supported features accept the identifiers of objects in SNOWFLAKE.MODELS wherever a model can be specified.

Refresh model objects and application roles¶

SNOWFLAKE.MODELS is not automatically populated with the objects that represent Cortex models. You must create these objects when you first set up model RBAC, and refresh them when you want to apply RBAC to new models.

As ACCOUNTADMIN, run the SNOWFLAKE.MODELS.CORTEX_BASE_MODELS_REFRESH stored procedure to populate the SNOWFLAKE.MODELS schema with objects representing currently available Cortex models, and to create application roles that correspond to the models. The procedure also creates CORTEX-MODEL-ROLE-ALL, a role that covers all models.

CALL SNOWFLAKE.MODELS.CORTEX_BASE_MODELS_REFRESH();

After refreshing the model objects, you can verify that the models appear in the SNOWFLAKE.MODELS schema as follows:

SHOW MODELS IN SNOWFLAKE.MODELS;

The returned list of models resembles the following:

To verify that you can see the application roles associated with these models, use the SHOW APPLICATION ROLES command, as in the following example:

SHOW APPLICATION ROLES IN APPLICATION SNOWFLAKE;

The list of application roles resembles the following:

Grant application roles to user roles¶

After you create the model objects and application roles, you can grant the application roles to specific user roles in your account.

• To grant a role access to a specific model:

  Copy codeExpand code block

  GRANT APPLICATION ROLE SNOWFLAKE."CORTEX-MODEL-ROLE-LLAMA3.1-70B" TO ROLE MY_ROLE;

  Show lessSee more

  Scroll to top

• To grant a role access to all current and future models:

  Copy codeExpand code block

  GRANT APPLICATION ROLE SNOWFLAKE."CORTEX-MODEL-ROLE-ALL" TO ROLE MY_ROLE;

  Show lessSee more

  Scroll to top

Use model objects with supported features¶

To use model objects with supported Cortex features, specify the identifier of the model object in SNOWFLAKE.MODELS as the model argument. You can use a fully-qualified identifier, a partial identifier, or a simple model name that will be automatically resolved to SNOWFLAKE.MODELS.

• Using a fully-qualified identifier:

  Copy codeExpand code block

  SELECT AI_COMPLETE('SNOWFLAKE.MODELS."LLAMA3.1-70B"', 'Hello');

  Show lessSee more

  Scroll to top

• Using a partial identifier:

  Copy codeExpand code block

  USE DATABASE SNOWFLAKE;
  USE SCHEMA MODELS;
  SELECT AI_COMPLETE('LLAMA3.1-70B', 'Hello');

  Show lessSee more

  Scroll to top

• Using automatic lookup with a simple model name:

  Copy codeExpand code block

  -- Automatically resolves to SNOWFLAKE.MODELS."LLAMA3.1-70B"
  SELECT AI_COMPLETE('llama3.1-70b', 'Hello');

  Show lessSee more

  Scroll to top

Using RBAC on the account allowlist¶

A number of Cortex features accept a model name as a string argument, for example AI_COMPLETE('model', 'prompt'). When you provide a model name:

1. Cortex first attempts to locate a matching model object in SNOWFLAKE.MODELS. If you provide an unqualified name like 'x', it automatically looks for SNOWFLAKE.MODELS."X".
2. If the model object is found, RBAC is applied to determine whether the user can use the model.
3. If no model object is found, the provided string is matched against the account-level allowlist.

The following example illustrates the use of allowlist and RBAC together. In this example, the allowlist is set to allow the mistral-large2 model, and the user has access to the LLAMA3.1-70B model object through RBAC.

-- set up access
USE SECONDARY ROLES NONE;
USE ROLE ACCOUNTADMIN;
ALTER ACCOUNT SET CORTEX_MODELS_ALLOWLIST = 'MISTRAL-LARGE2';
CALL SNOWFLAKE.MODELS.CORTEX_BASE_MODELS_REFRESH();
GRANT APPLICATION ROLE SNOWFLAKE."CORTEX-MODEL-ROLE-LLAMA3.1-70B" TO ROLE PUBLIC;

-- test access
USE ROLE PUBLIC;

-- this succeeds because mistral-large2 is in the allowlist
SELECT AI_COMPLETE('MISTRAL-LARGE2', 'Hello');

-- this succeeds because the role has access to the model object
SELECT AI_COMPLETE('SNOWFLAKE.MODELS."LLAMA3.1-70B"', 'Hello');

-- this fails because the first argument is
-- neither an identifier for an accessible model object
-- nor is it a model name in the allowlist
SELECT AI_COMPLETE('claude-sonnet-4-6', 'Hello');

Common pitfalls¶

• Access to a model (whether by allowlist or RBAC) does not always mean that it can be used. It may still be subject to cross-region, deprecation, or other availability constraints. These restrictions can result in error messages that seem similar to model access errors.
• Model access controls only govern the use of a model and not the use of a feature itself. A feature can have its own access controls. For example, access to AI_COMPLETE is governed by the CORTEX_USER or AI_FUNCTIONS_USER database role and the USE AI FUNCTIONS account-level privilege. For more information, see Cortex LLM privileges.
• Not all features support model access controls. For more information about what a feature supports, see the supported features table.
• Secondary roles can obscure permissions. For example, if a user has ACCOUNTADMIN as a secondary role, all model objects may appear accessible. Disable secondary roles temporarily when verifying permissions.
• Qualified model object identifiers are quoted and therefore case-sensitive. For more information, see QUOTED_IDENTIFIERS_IGNORE_CASE.

Supported features¶

Model access controls are supported by the following features: