Support Snowflake Cortex permissions: DRG fetch fix + USE AI FUNCTIONS + CORTEX SEARCH SERVICE grants

[usbrandon]

Summary

Adds native modeling for Snowflake Cortex permissions in snowcap YAML, addressing three related gaps surfaced while trying to manage Cortex Code and Cortex AI access for a dbt developer role.

1. Fix fetch_database_role_grant returning the wrong row (commit)

A database role granted to multiple grantees (e.g. SNOWFLAKE.CORTEX_USER is granted to ACCOUNTADMIN, PUBLIC, and any custom role) cannot be modeled correctly because fetch_database_role_grant filters role_grants by the requested grantee but then returns show_result[0] — the unfiltered first row. Every per-grantee fetch returns the same data (the first SHOW GRANTS OF DATABASE ROLE row), so declaring a second grantee in YAML produces a spurious UpdateResource(to_role: ACCOUNTADMIN → DBT_DEVELOPER) diff instead of a clean CreateResource. There is no update_database_role_grant lifecycle hook, so applying that update emits invalid ALTER DATABASE_ROLE_GRANT ... SET to_role ... SQL.

The fix is a one-line change in snowcap/data_provider.py (data = show_result[0] → data = role_grants[0]). An integration regression test (test_fetch_grant_of_database_role_multiple_grantees) creates one database role, grants it to two account roles, and fetches each grantee independently — which previously returned identical data.

2. Add USE AI FUNCTIONS to AccountPriv (same commit)

Per Snowflake's Cortex AI SQL docs, Cortex AI functions require the account-level privilege USE AI FUNCTIONS in addition to a database role (SNOWFLAKE.CORTEX_USER or SNOWFLAKE.AI_FUNCTIONS_USER). It is granted to PUBLIC by default, but declarative management requires it in the enum to parse priv: USE AI FUNCTIONS / on: account / to: <role> from YAML. Added as AccountPriv.USE_AI_FUNCTIONS.

3. Add CORTEX SEARCH SERVICE as a grantable resource type (commit)

Cortex Search is a schema-scoped service with USAGE (query the service), MONITOR (access AI observability logs), and OWNERSHIP privileges. Users naturally want to write priv: USAGE on cortex search service db.sch.svc / to: r in YAML — but CORTEX SEARCH SERVICE wasn't in ResourceType and had no Priv enum, so the parser rejected those grants.

Following the precedent set by the generic INTEGRATION umbrella scope (introduced earlier in this fork): adds ResourceType.CORTEX_SEARCH_SERVICE, CortexSearchServicePriv(ALL/USAGE/MONITOR/OWNERSHIP), a PRIVS_FOR_RESOURCE_TYPE mapping, and a SchemaScope() registration in RESOURCE_SCOPES. No concrete CortexSearchService resource class — full DDL modeling (CREATE CORTEX SEARCH SERVICE ... AS <query> with embedding model and target_lag) is left for a separate PR; this change covers grants only.

Also drops CREATE CORTEX SEARCH SERVICE from the "Skip undocumented privs" filter in list_grants — that privilege is already in SchemaPriv and should round-trip like any other documented priv. CANCEL QUERY (genuinely undocumented) stays filtered.

Test plan

• uv run pytest tests/ --ignore=tests/integration -q → 1498 passed, 0 failed
• New unit tests for AccountPriv.USE_AI_FUNCTIONS, CortexSearchServicePriv enum values, and Grant(priv=USAGE, on cortex search service ...) SQL rendering
• New integration test (test_fetch_grant_of_database_role_multiple_grantees) creating one database role granted to two account roles and verifying each fetch returns its own grantee — would have caught the regression
• Live validation against a real account: calling fetch_database_role_grant against SNOWFLAKE.CORTEX_USER (granted to ACCOUNTADMIN, DBT_DEVELOPER, PUBLIC in that account) — each grantee URN now returns its own to_role. Before the fix, all three returned ACCOUNTADMIN's row.
• End-to-end snowcap plan against a real account: previously emitted ~ UPDATE: CORTEX_USER to_role ACCOUNTADMIN → DBT_DEVELOPER whenever the YAML added a second grantee; now emits a clean 0 to update plan.

References

• Snowflake docs: Cortex AI SQL — Required Privileges, Cortex Code — Access control, Cortex Search Service — Access, Cortex Search Monitor logs

🤖 Generated with Claude Code

[noel]

Thanks for the contribution. I will merge this