CORTEX_MODELS_ALLOWLIST deprecation and embedding model RBAC enforcement (Pending)¶

Snowflake is converging Cortex model access on model role-based access control (RBAC). The CORTEX_MODELS_ALLOWLIST account parameter is being deprecated, and model RBAC authorization is being enforced for embedding models, including AI_EMBED and Cortex Search. This change rolls out in phases: an unbundled behavior change that deprecates the allowlist and migrates accounts to model RBAC, followed by embedding model RBAC enforcement in the 2026_07 behavior change bundle.

Before the change:

When a Cortex call arrives, Snowflake checks model RBAC first. If the calling role doesn’t have access to the corresponding model object in SNOWFLAKE.MODELS, Snowflake falls back to the CORTEX_MODELS_ALLOWLIST parameter. You can set the allowlist to 'All', 'None', or a comma-separated list of models, and model RBAC isn’t enforced for embedding models.

After the change:

Cortex model access is determined exclusively through model RBAC. CORTEX_MODELS_ALLOWLIST is no longer consulted during authorization, and you can only set it to 'None'. Model RBAC is enforced for embedding models, including AI_EMBED and Cortex Search.

Existing accounts retain access through an automatic backfill of embedding model application roles, and newly created accounts receive access through the automatic CORTEX-MODEL-ROLE-ALL bootstrap grant.

What you need to do¶

If CORTEX_MODELS_ALLOWLIST is already set to 'None' in your account, you’re already using model RBAC exclusively and no action is required.

If you receive the automatic CORTEX-MODEL-ROLE-ALL bootstrap grant through SNOWFLAKE.PUBLIC and you want to restrict model access, use the stored procedures in this section. Don’t use a raw REVOKE APPLICATION ROLE ... FROM ROLE PUBLIC statement. That statement doesn’t remove the bootstrap grant from SNOWFLAKE.PUBLIC, and it doesn’t persist that intent across Snowflake upgrades.

SNOWFLAKE.PUBLIC is an application role on the SNOWFLAKE database. It is not the same object as the account-level PUBLIC role. SHOW GRANTS TO ROLE PUBLIC might not show the bootstrap path.

To confirm that CORTEX-MODEL-ROLE-ALL is granted through SNOWFLAKE.PUBLIC, run the following as ACCOUNTADMIN:

SHOW GRANTS TO APPLICATION ROLE SNOWFLAKE.PUBLIC;

To revoke the bootstrap grant, call the following procedure as ACCOUNTADMIN:

CALL SNOWFLAKE.LOCAL.REVOKE_FROM_PUBLIC_APPLICATION_ROLE(
  'APP_ROLE',
  'CORTEX-MODEL-ROLE-ALL'
);

After the revoke, re-run SHOW GRANTS TO APPLICATION ROLE SNOWFLAKE.PUBLIC and confirm that CORTEX-MODEL-ROLE-ALL is no longer listed. Then grant specific model application roles to the roles that need them.

To restore the bootstrap grant after you’ve revoked it:

CALL SNOWFLAKE.LOCAL.GRANT_TO_PUBLIC_APPLICATION_ROLE(
  'APP_ROLE',
  'CORTEX-MODEL-ROLE-ALL'
);

For more context, including the difference between this bootstrap path and grants you make yourself to the account-level PUBLIC role, see Default bootstrap of CORTEX-MODEL-ROLE-ALL.

Otherwise, to ensure uninterrupted access to models after enforcement begins, choose one of the following migration options. For detailed steps, including how to identify affected workloads and grant the equivalent model application roles, see Migrate from the allowlist to RBAC.

• Option 1: Migrate yourself. Configure model access using model RBAC application roles, validate that the configuration provides the required model access, and then set the allowlist to 'None':

  Copy code

  ALTER ACCOUNT SET CORTEX_MODELS_ALLOWLIST = 'None';
  

• Option 2: Wait for Snowflake’s one-time migration. Snowflake maps your existing CORTEX_MODELS_ALLOWLIST configuration to model RBAC application roles between August 17 and September 4, 2026. After the migration completes, validate the migrated grants, then set the allowlist to 'None'.

While you wait for the Snowflake migration, model RBAC and the allowlist continue to work together, with no change from the current behavior, until the migration begins on August 17, 2026. Test in a non-production account before confirming the migration.

Validate the Snowflake migration¶

After Snowflake completes the one-time migration for your account, confirm that the backfilled model application roles match your previous allowlist. Then disable the allowlist and test existing workloads.

Compare the allowlist with PUBLIC grants¶

As ACCOUNTADMIN, retrieve the allowlist value and the model application roles granted to PUBLIC:

SHOW PARAMETERS LIKE 'CORTEX_MODELS_ALLOWLIST' IN ACCOUNT;
SHOW GRANTS TO ROLE PUBLIC;

Compare the two results:

• If the allowlist is a comma-separated list of models, each listed model should have a corresponding CORTEX-MODEL-ROLE-<model> application role granted to PUBLIC. Additional embedding-model roles in the PUBLIC grants are expected; the migration also backfills embedding models.
• If the allowlist is 'All', look for CORTEX-MODEL-ROLE-ALL. That grant might appear on SNOWFLAKE.PUBLIC rather than on the account-level PUBLIC role. Confirm the bootstrap path with SHOW GRANTS TO APPLICATION ROLE SNOWFLAKE.PUBLIC.
• If the allowlist is already 'None', you’re already using model RBAC exclusively.

Disable the allowlist and test workloads¶

When the grants match your expected access, set the allowlist to 'None' so that only model RBAC is used, then rerun your existing Cortex workloads:

ALTER ACCOUNT SET CORTEX_MODELS_ALLOWLIST = 'None';

Test with a role other than ACCOUNTADMIN. The ACCOUNTADMIN role always has access to all models, regardless of the allowlist or model RBAC grants. Disable secondary roles with USE SECONDARY ROLES NONE when you need to verify that a specific role’s grants are sufficient.

If a workload fails after you disable the allowlist, grant the required model application role to the execution role, not only to PUBLIC. For more information, see the note later on this page and Migrate from the allowlist to RBAC.

Enforcement through the 2026_07 behavior change bundle¶

Model RBAC enforcement for embedding models is delivered through the 2026_07 behavior change bundle. The bundle follows the standard bundle lifecycle: a default opt-out period beginning around September 8, 2026, followed by a default opt-in period beginning around October 13, 2026, with the rollout completing on November 18, 2026. More detailed documentation accompanies the 2026_07 bundle when it’s published.

Ref: 2378