check-agent-access

Overview

This skill performs an end-to-end privilege audit for Cortex Agents. It discovers every agent in the account, reads each agent's live spec to build a dependency tree, then runs parallel SHOW GRANTS checks to identify privilege gaps for a target role. Results are presented per-agent with ✅ / ❌ status and a one-click remediation script is generated for any gaps found.

When to Use

Use this skill when you need to:

• Verify that a role (e.g. PUBLIC, READER, a custom app role) can call one or more Cortex Agents end-to-end.
• Identify missing USAGE grants on agents, semantic views, Cortex Search services, UDFs, or warehouses.
• Generate a ready-to-run remediation script for access gaps.
• Audit a newly created agent before rolling it out to users.

When NOT to Use

Workflow

1. Discover agents — Run SHOW AGENTS IN ACCOUNT;. Fall back to

SELECT agentcatalog, agentschema, agentname FROM SNOWFLAKE.ACCOUNTUSAGE.CORTEX_AGENTS if that errors. Present the list and confirm scope with the user (all agents or a subset).

1. Ask for the role — Ask: "Which role should I audit? (e.g. PUBLIC, READER, MYCUSTOMROLE)"

Wait for the answer before proceeding.

1. Read agent specs in parallel — For every agent in scope call semantic_studio with

action: cortexagentread, source: snowflake, fqn: <DB.SCHEMA.AGENT>. Extract all dependencies: semantic views, Cortex Search services, UDFs, warehouses, and any table FQNs found in instructions.

⚠️ If a spec result is trimmed or unavailable, fall back to fetching that agent's spec individually in a separate call rather than skipping it. Never assume an empty spec means no dependencies.

1. Check grants in parallel — For each dependency run the matching

SHOW GRANTS ON <object_type> <fqn>:

Also run SHOW GRANTS TO ROLE <targetrole> and recurse up parent roles via SHOW GRANTS TO ROLE <parentrole>. Inherited grants are sufficient — only flag a gap when neither the role itself nor any ancestor holds the required privilege.

1. Present the gap report — Produce a Markdown table grouped by agent with columns

Object | Type | Required Privilege | Status. Summarise: agents checked, dependencies checked, gaps found. Stop here if there are no gaps.

1. Offer remediation — Generate one GRANT statement per gap. Ask:

"Found N gap(s) — execute the GRANTs now (Yes) or show for copy-paste (No)?" On Yes, run each statement and confirm success or report the error. On failure, suggest switching to SYSADMIN or ACCOUNTADMIN.

Common Mistakes

• Missing inherited grants — Always resolve the full role hierarchy before flagging a

gap; a privilege on any parent role is sufficient.

• Inventing FQNs — Only audit objects confirmed in the agent spec or via catalog search.

Never guess object names.

• Wrong role for GRANTs — GRANT statements require SYSADMIN or ACCOUNTADMIN.

Remind the user to switch roles if a GRANT fails with an insufficient-privileges error.

• SELECT vs REFERENCES on semantic views — Both privileges appear in grants output;

either counts as sufficient read access.

Examples

Audit all agents for PUBLIC:

"Check which Cortex Agents the PUBLIC role can access."

Expected output: a gap table grouped by agent showing ✅ / ❌ for every dependency (agent USAGE, semantic view SELECT, search service USAGE, function USAGE, warehouse USAGE), followed by a remediation script for any gaps.

Audit a single agent for a custom role:

"Can the ANALYST role call the FUNDRAISING_ANALYST agent?"

Expected output: single-agent gap table; if all grants are present, reports no gaps and stops.

Execute remediation:

"Fix the missing grants for PUBLIC on CONSUME.ELTERNBRIEF.ELTERNBRIEF_ANALYST."

Expected output: targeted GRANT statements executed one by one, each confirmed or the error reported.

Stopping Points

⚠️ STOPPING POINT — After presenting the agent list (Step 1), confirm scope before proceeding.

⚠️ STOPPING POINT — After the role is confirmed (Step 2), wait for explicit approval before reading any agent specs.

⚠️ STOPPING POINT — After presenting the gap report (Step 5), wait for explicit user confirmation before executing any GRANT statements. RBAC changes are easy to apply but can inadvertently expose sensitive data if the wrong role is targeted.