Open the 13 May release note and you are reading about a new lever. Open SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES in the same browser tab and you are reading about a door that has been ajar since the account was provisioned. Two paragraphs, five tabs apart. Both true. We ran the query first, then went back to the release note — and only then noticed the difference between what was being announced and what was already the case.

The lever is the lever the docs lead with: per-function USE AI FUNCTION <name> privileges, GA on 2026-05-13, scoped to each entry in the Cortex catalog. AI_COMPLETE (legacy SNOWFLAKE.CORTEX.COMPLETE), AI_SUMMARIZE (legacy SNOWFLAKE.CORTEX.SUMMARIZE), AI_CLASSIFY, AI_TRANSLATE, AI_EMBED — each grantable to a role on its own. On paper this is the privilege a security review has been asking for: a summarisation pipeline can be trusted with AI_SUMMARIZE without inheriting arbitrary AI_COMPLETE against a foundation model. The lock is well-designed.

The door is the SNOWFLAKE.CORTEX_USER database role, granted to PUBLIC at account creation. Every user the account has ever provisioned, and every user it ever will, inherits the right to call any Cortex function on first connection. The new privilege refines access along a path the default has already opened. Granting the new one without revoking the old changes nothing about who can spend.

The shape of the gap is three integers. We pulled them in the order below because each one reframes the previous: the first tells you the surface area, the second tells you how much of that surface is actually used, and the third tells you how much is governed by anything other than the default. Read in sequence, they are the “here is your Cortex exposure” report most security reviews would have asked for if they knew the views existed.

The triplet our worksheet returned matches the shape we expect every production account to return on first audit: n_can_today is essentially the active-user count (12 of 14 here), n_did_30d is a small fraction of that (6), and n_per_function_grants is exactly 0 because the new privilege has existed for under two weeks and nobody has touched it. The default did the granting. No human ratified the list.

-- Returns the row that says "yes, every user can call Cortex."
-- If the result is non-empty, n_can_today is the count of active users.
SELECT grantee_name,
       privilege,
       granted_on,
       name,
       created_on
FROM   snowflake.account_usage.grants_to_roles
WHERE  grantee_name = 'PUBLIC'
  AND  name ILIKE '%CORTEX_USER%'
  AND  deleted_on IS NULL
ORDER BY created_on DESC;

-- n_did_30d is the COUNT(DISTINCT user_name) of this result.
-- The per-function breakdown is the second cut: what is the entitled
-- population actually using? Pull query_id too so any one call can be
-- traced back through QUERY_HISTORY.
SELECT user_name,
       function_name,
       COUNT(*) AS call_count,
       SUM(tokens) AS tokens,
       MAX(query_id) AS last_query_id
FROM   snowflake.account_usage.cortex_ai_functions_usage_history
WHERE  start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY 3 DESC
LIMIT 20;

-- The GA privilege is granted on the SNOWFLAKE database object.
-- Filter the result of SHOW GRANTS for "USE AI FUNCTION" rows;
-- n_per_function_grants is the count of those rows.
SHOW GRANTS ON DATABASE snowflake;

SELECT "privilege",
       "granted_on",
       "name",
       "grantee_name",
       "granted_by"
FROM   TABLE(RESULT_SCAN(LAST_QUERY_ID()))
WHERE  "privilege" ILIKE 'USE AI FUNCTION%';

Three queries, one account, fifteen minutes. The triplet is the “here is your Cortex exposure” report most security reviews would have asked for if they knew the view existed. — Field report, §2

USE AI FUNCTION is granted on the SNOWFLAKE database, scoped to a named Cortex function. The grammar is regular SQL and the semantics are ordinary RBAC. Two grants below: one narrow, one as broad as the old database role:

CREATE OR REPLACE ROLE cortex_summariser;

-- Either form works; the AI_* form aligns with current docs.
GRANT USE AI FUNCTION snowflake.cortex.summarize
  ON DATABASE snowflake
  TO ROLE cortex_summariser;
-- or, equivalently:
-- GRANT USE AI FUNCTION snowflake.ai.ai_summarize
--   ON DATABASE snowflake
--   TO ROLE cortex_summariser;

-- The role can call AI_SUMMARIZE (legacy SNOWFLAKE.CORTEX.SUMMARIZE),
-- and only that. AI_COMPLETE, AI_CLASSIFY, AI_TRANSLATE, AI_EMBED
-- (and their legacy SNOWFLAKE.CORTEX.* aliases) all return
-- "insufficient privileges" on this role.
GRANT ROLE cortex_summariser TO USER svc_summary_pipeline;

GRANT USE AI FUNCTION ON ALL ai_functions
  IN DATABASE snowflake
  TO ROLE cortex_power_user;

-- Equivalent surface to the old SNOWFLAKE.CORTEX_USER database role,
-- but now an explicit, named, auditable act — not a default.

The model surface is correct. Each privilege is a row in SHOW GRANTS; each call traces to the function and the granting role in CORTEX_AI_FUNCTIONS_USAGE_HISTORY; an Auditor role can review the lot without elevated access. Snowflake’s docs land this clearly. The piece they understate is what stays in place while you adopt the new privilege: the PUBLIC → CORTEX_USER grant is not revoked by adopting USE AI FUNCTION. You revoke it yourself, or it persists.

Read the docs top-down and you reach the new privilege first, the default-grant footnote later, the actual remediation last. That order leaves the default in place the whole time. The order that closes the door is the reverse: revoke the default, enumerate who actually used Cortex, re-grant per function against the named list. Revoke. Inventory. Grant. The only sequence that ends with a governed account.

Revoke. Remove the default CORTEX_USER grant from PUBLIC. This is a one-line statement. It is also the only step that is irreversible without a re-grant, and the only one that produces an immediate behaviour change for the population in n_can_today − n_did_30d. The expected outcome is “nothing breaks”, because by construction those users have not called Cortex in the audit window.

REVOKE DATABASE ROLE snowflake.cortex_user
  FROM ROLE "PUBLIC";

Inventory. Run query 2 from §2 with a wider window (90 days, not 30) to surface every user, function, and pipeline that has actually used Cortex. Group by warehouse_name as well as user_name to catch pipelines that use a service warehouse but a human principal. That list is the candidate set for the next step.

Grant. For each name on the inventory, decide: is this a human worksheet user (probably gets a single cortex_summariser-like role granting one function), a service principal (gets a tightly-scoped role with only the functions its pipeline calls), or an exploratory data-science role (gets USE AI FUNCTION ON ALL ai_functions, but only that role, only those users). Re-grant on the basis of the inventory, not on the basis of who used to have it.

The docs lead with the new privilege because that is what is new. The audit leads with the revoke, because that is what is unsafe. The order matters because in between the two reads, the bill keeps running. — Field report, §4

The audit runs on any Snowflake account a SECURITYADMIN-equivalent role can read. Open a worksheet, run the three queries from §2, write down the triplet. If n_can_today − n_did_30d is large, you have a decision in front of you: revoke and re-grant, or document why the default was acceptable. The point is not the answer; it is to make the decision an act, rather than a non-act.

The Crosshire version of the audit adds warehouse spend attribution per Cortex function over the same 30-day window, plus a join against SNOWFLAKE.ACCOUNT_USAGE.USERS so the entitled set names its members rather than just counting them. The discipline is the same either way.

Every number above traces to a row in ACCOUNT_USAGE. A model never produces the numbers; a human ratifies every revoke. The audit is honest because the queries are.