What you will be able to do
- Explain the two independent gates a role must pass to call Cortex AI Functions
- Revoke default PUBLIC access and grant Cortex access to a custom role in the correct order
- Use per-function USE AI FUNCTION <name> privileges and predict how they interact with the blanket privilege
- Choose between CORTEX_USER, AI_FUNCTIONS_USER and CORTEX_EMBED_USER for a given access requirement
Key concept
Two-gate access to Cortex AI Functions — A role can call Cortex AI Functions only when two separate grants are both in place. The first is an account-level privilege, either the blanket USE AI FUNCTIONS or a per-function USE AI FUNCTION <name>. The second is a SNOWFLAKE database role, either CORTEX_USER or AI_FUNCTIONS_USER. Revoking either one closes access, and an audit has to check both.
1.Two gates: an account privilege and a database role
Cortex AI Functions such as AI_COMPLETE, AI_CLASSIFY and AI_EXTRACT are protected by two separate access controls, and a role needs to pass both. The first is an account-level privilege, USE AI FUNCTIONS. The second is one of two database roles that live in the shared SNOWFLAKE database, SNOWFLAKE.CORTEX_USER or SNOWFLAKE.AI_FUNCTIONS_USER. The documentation states the requirement directly: users need the account privilege and also one of the CORTEX_USER or AI_FUNCTIONS_USER database roles to use Snowflake Cortex AI Functions.
In a new account, both gates are already open to everyone. USE AI FUNCTIONS is granted to PUBLIC by default, and so is CORTEX_USER. Because PUBLIC is automatically granted to every user and role, every user can call AI functions until an administrator changes this. Only ACCOUNTADMIN can manage the USE AI FUNCTIONS privilege.
The two-gate rule has two exceptions you should know. The first is the aggregate functions: a role that has USE AI FUNCTIONS but not CORTEX_USER can still run AI_AGG and AI_SUMMARIZE_AGG. The second is native applications. USE AI FUNCTIONS is currently not enforced for AI function queries that run inside a Snowflake native application, so those queries succeed even when the role lacks the privilege.
One setup needs extra grants. When AI functions run under Restricted Caller’s Rights, for example inside a Snowpark Container Services service, the privilege must be granted to both the session role and the service or application owner role. The owner role receives the caller form of the privilege, GRANT CALLER USE AI FUNCTIONS.
Checkpoint 1 of 6· Exam question
A governance team wants ordinary business users to keep calling AI_COMPLETE and AI_CLASSIFY through Snowsight worksheets without gaining any ability to build chat-with-data apps, run searches, or use fine-tuning. Which single database role satisfies this exactly?
Correct answer: A — SNOWFLAKE.AI_FUNCTIONS_USER
- A. This is correct: AI_FUNCTIONS_USER grants scalar AI functions such as completion and classification but deliberately excludes Cortex Analyst, Agents, Search, and fine-tuning, matching the narrow scope requested.
- B. This is incorrect: CORTEX_USER is the broad role that unlocks all covered Cortex AI features, which is more access than the team wants to grant.
- C. This is incorrect: this role authorizes calling Cortex Agents specifically and has no bearing on plain scalar function access.
- D. This is incorrect: this role authorizes Cortex Analyst requests only and would not by itself cover general scalar function calls.
Checkpoint 2 of 6· Check yourself
A role has USE AI FUNCTIONS. A query that calls AI_COMPLETE runs inside a Snowflake native application. What happens?
Native applications are a documented exception: USE AI FUNCTIONS is not enforced for AI function queries that run inside them.
“Currently, USE AI FUNCTIONS does not apply to AI Function queries that are run inside Snowflake native applications.”Source: docs.snowflake.com
Sources1
2.Revoking from PUBLIC and granting to custom roles
To limit Cortex access, use the same pattern for both gates. First revoke the grant from PUBLIC, then grant it to a role that only the intended users hold. There is one constraint on how you grant it: the SNOWFLAKE.CORTEX_USER database role cannot be granted directly to a user. You grant it to an account role and then grant that account role to users.
To close the database-role gate, run this as ACCOUNTADMIN:
REVOKE DATABASE ROLE SNOWFLAKE.CORTEX_USER FROM ROLE PUBLIC;Some guidance also recommends REVOKE IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE FROM ROLE PUBLIC. That revocation is optional, and it reaches beyond Cortex: it also removes PUBLIC’s access to other objects in the shared SNOWFLAKE database, such as ACCOUNT_USAGE views. Run it only if you intend to remove that access as well.
After revoking, give access back to the right people through a custom role. You can also grant to a role that already exists, such as an analyst role, with a single GRANT statement.
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;Checkpoint 3 of 6· Exam question
Which account-level privilege, in addition to a Cortex database role, must a role hold for its users to invoke Snowflake Cortex AI functions at all?
Correct answer: A — USE AI FUNCTIONS
- A. This is correct: calling Cortex AI functions requires the account-level USE AI FUNCTIONS privilege (or a per-function equivalent) together with a Cortex database role such as CORTEX_USER.
- B. This is incorrect: a warehouse is only needed to run the query that invokes the function; it does not itself authorize access to Cortex functions.
- C. This is incorrect: this privilege only governs creating a search service object and is unrelated to calling scalar AI functions.
- D. This is incorrect: this administrative privilege lets a role manage grants on objects but grants no function-calling capability by itself.
Checkpoint 4 of 6· Put it in order
Put these steps in order to move AI-function access from everyone to selected users.
- 1.Grant the custom role to the users who need access
- 2.Create a custom account role
- 3.Grant USE AI FUNCTIONS and the SNOWFLAKE.CORTEX_USER database role to the custom role
- 4.As ACCOUNTADMIN, revoke USE AI FUNCTIONS on the account from PUBLIC
You remove the default PUBLIC grant first, then create the role that will receive the grants. Users get access only when the finished role is granted to them, because database roles cannot be granted to users directly.
“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”Source: docs.snowflake.com
3.Per-function privileges: USE AI FUNCTION <name>
USE AI FUNCTIONS gives a role every Cortex AI function at once. When a role should get only some of them, ACCOUNTADMIN can grant per-function privileges with GRANT USE AI FUNCTION <function_name> ON ACCOUNT TO ROLE <role_name>. Each function has its own privilege name. Newer functions use their own name (AI_COMPLETE, AI_EMBED, AI_REDACT). Legacy SNOWFLAKE.CORTEX functions use their short name, so SNOWFLAKE.CORTEX.COMPLETE becomes COMPLETE and SNOWFLAKE.CORTEX.TRY_COMPLETE becomes TRY_COMPLETE.
A per-function privilege replaces only the first gate. The role still needs CORTEX_USER or AI_FUNCTIONS_USER, as the example below shows.
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;The blanket privilege and the per-function privileges are combined with OR: a role has access if either one allows it. This has a practical effect on revocation. If a role holds USE AI FUNCTIONS, it can call every function no matter which per-function grants it has or has lost. Revoking USE AI FUNCTION AI_COMPLETE from such a role changes nothing. Revoking it from a role that has no blanket privilege does stop AI_COMPLETE.
You can grant several per-function privileges to one role to build a custom set of allowed functions. To audit them, run SHOW GRANTS TO ROLE <role> or SHOW GRANTS ON ACCOUNT. Per-function grants appear under the privilege name USE AI FUNCTION <function_name>.
Checkpoint 5 of 6· Check yourself
A role holds USE AI FUNCTIONS, USE AI FUNCTION AI_COMPLETE and CORTEX_USER. The administrator runs REVOKE USE AI FUNCTION AI_COMPLETE ON ACCOUNT FROM ROLE for that role. Can the role still call AI_COMPLETE?
The two privileges are combined with OR, so a role with the blanket privilege can call every function regardless of per-function revocations.
“If a role has USE AI FUNCTIONS, it can call all Cortex AI functions, regardless of any per-function grants or revocations.”Source: docs.snowflake.com
Sources1
4.Narrower database roles: AI_FUNCTIONS_USER and CORTEX_EMBED_USER
CORTEX_USER is broad. Besides the AI functions, it also opens Cortex services such as Agents, Analyst and Search. Two narrower database roles in the SNOWFLAKE database cover the cases where that is too much.
AI_FUNCTIONS_USER allows the scalar AI functions, which means every Cortex AI function except the aggregates AI_AGG and AI_SUMMARIZE_AGG. It does not grant access to Cortex Agent, Cortex Analyst, Cortex Fine-tuning or Cortex Search. CORTEX_EMBED_USER covers only embedding: the AI_EMBED, EMBED_TEXT_768 and EMBED_TEXT_1024 functions, plus creating Cortex Search Services that use managed vector embeddings. If you generate embeddings yourself outside Snowflake and load them into a table, you can create a Search Service with those user-provided embeddings without CORTEX_EMBED_USER.
Neither narrow role is granted to PUBLIC by default. CORTEX_EMBED_USER only matters once you have revoked CORTEX_USER, because CORTEX_USER already includes embedding. Like CORTEX_USER, neither narrow role can be granted directly to a user; grant it to a role that users can assume.
| Database role | What it unlocks | Granted to PUBLIC by default? |
|---|---|---|
| SNOWFLAKE.CORTEX_USER | Cortex AI functions and Cortex services such as Agents, Analyst and Search | Yes |
| SNOWFLAKE.AI_FUNCTIONS_USER | Scalar AI functions only (not AI_AGG or AI_SUMMARIZE_AGG); no Cortex services | No |
| SNOWFLAKE.CORTEX_EMBED_USER | AI_EMBED, EMBED_TEXT_768, EMBED_TEXT_1024, and Cortex Search Services with managed embeddings | No |
Checkpoint 6 of 6· Match them up
Match each database role to the access it is designed to give
Tap a term, then the definition that fits it.
CORTEX_USER is the broad default role. The other two each grant a narrow slice and are not granted to PUBLIC.
“without granting access to Cortex services such as Cortex Agent, Cortex Analyst, Cortex Fine-tuning, or Cortex Search”Source: docs.snowflake.com
Sources1
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.You can run GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO USER to give one person Cortex access.Why is that wrong?
SNOWFLAKE database roles cannot be granted to users. Grant the database role to an account role, then grant that account role to the user.
Covered in Revoking from PUBLIC and granting to custom roles
2.Granting USE AI FUNCTION AI_COMPLETE is enough for a role to call AI_COMPLETE.Why is that wrong?
A per-function grant replaces only the account-privilege gate. The role still needs CORTEX_USER or AI_FUNCTIONS_USER.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“one of the CORTEX_USER or AI_FUNCTIONS_USER database roles to use Snowflake Cortex AI Functions”
↩︎ Two gates: an account privilege and a database role“By default, the USE AI FUNCTIONS privilege is granted to the PUBLIC role.”
↩︎ Two gates: an account privilege and a database role“You must use the ACCOUNTADMIN role to manage the USE AI FUNCTIONS account-level privilege.”
↩︎ Two gates: an account privilege and a database role“to both the session role and the service or application owner role”
↩︎ Two gates: an account privilege and a database role“By default, the CORTEX_USER role is granted to the PUBLIC role.”
↩︎ Revoking from PUBLIC and granting to custom roles“The per-function privilege and the blanket USE AI FUNCTIONS privilege have an OR relationship”
↩︎ Per-function privileges: USE AI FUNCTION <name>“Per-function grants appear with the privilege name USE AI FUNCTION <function_name>”
↩︎ Per-function privileges: USE AI FUNCTION <name>“call the text embedding functions AI_EMBED, EMBED_TEXT_768, and EMBED_TEXT_1024 and to create Cortex Search Services with managed vector embeddings”
↩︎ Narrower database roles: AI_FUNCTIONS_USER and CORTEX_EMBED_USER“AI_FUNCTIONS_USER role is not granted to the PUBLIC role by default.”
↩︎ Narrower database roles: AI_FUNCTIONS_USER and CORTEX_EMBED_USER“You must explicitly grant this role to roles that require embedding capabilities if you have revoked the CORTEX_USER role.”
↩︎ Narrower database roles: AI_FUNCTIONS_USER and CORTEX_EMBED_USER“You can create Cortex Search Services with user-provided embeddings without the CORTEX_EMBED_USER role.”
↩︎ Narrower database roles: AI_FUNCTIONS_USER and CORTEX_EMBED_USER“Your users need both the USE AI FUNCTIONS account-level privilege (or a per-function USE AI FUNCTION <name> privilege)”
↩︎ Key concept“The SNOWFLAKE.CORTEX_USER database role cannot be granted directly to a user.”
↩︎ Exam trap 1“Per-function privileges require the same CORTEX_USER (or AI_FUNCTIONS_USER) database role as the blanket USE AI FUNCTIONS privilege.”
↩︎ Exam trap 2“doesn’t have the CORTEX_USER role, they can still use the AI_AGG and AI_SUMMARIZE_AGG functions”
↩︎ Prediction“Currently, USE AI FUNCTIONS does not apply to AI Function queries that are run inside Snowflake native applications.”
↩︎ Checkpoint“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”
↩︎ Checkpoint“If a role has USE AI FUNCTIONS, it can call all Cortex AI functions, regardless of any per-function grants or revocations.”
↩︎ Checkpoint“without granting access to Cortex services such as Cortex Agent, Cortex Analyst, Cortex Fine-tuning, or Cortex Search”
↩︎ Checkpoint - 2.
“it also removes PUBLIC’s access to other objects in the shared SNOWFLAKE database, such as ACCOUNT_USAGE views.”
↩︎ Revoking from PUBLIC and granting to custom roles