Audit your Snowflake roles before opening CoWork, because every query runs under the asking user's roles. Then set Cortex access and cross-region routing, confirm how Snowflake classifies prompts, and limit what external assistants can call.
When you need this
Evaluation criteria
Cortex access
Who can use Cortex Agents at all?
Look forCORTEX_USER is granted to PUBLIC by default. Revoke it and grant CORTEX_AGENT_USER to the roles that should use CoWork, which gives agent access without the other Cortex features.
CoWork-only users
Should some people reach CoWork but not the rest of Snowflake?
Look forALLOWED_INTERFACES set to CoWork only, through ALTER USER or the SCIM allowedInterfaces attribute, plus an IdP redirect. Snowflake's ALTER USER reference lists three values, ALL, SNOWFLAKE_INTELLIGENCE, and STREAMLIT, and a restricted user cannot reach Snowflake data outside the interfaces listed. A practitioner reports the setting blocks OAuth for the Claude connector, so leave ALLOWED_INTERFACES at ALL for anyone who will query Snowflake from Claude.
What the agent can read
Do answers respect existing data policies?
Look forQueries run with the user's credentials, so role-based access and masking policies apply. Users need SELECT on the tables behind a semantic view, and a Cortex Search service answers with its owner's rights, so create it under a narrow role.
Where inference runs
Can prompts leave your account's region?
Look forA CORTEX_ENABLED_CROSS_REGION setting chosen deliberately: any region, one cloud, a geography such as AWS_EU or AWS_JP, or disabled. Customer data stays stored in the account's region. Prompts and responses pass through the processing region transiently.
Data terms and guardrails
How are prompts classified, and what blocks prompt injection?
Look forSnowflake's legal notice classifies CoWork inputs as Usage Data and outputs as Customer Data, and Snowflake never uses Customer Data to train models it offers. Cortex AI Guardrails, on Enterprise Edition with cross-region inference, scan tool outputs for prompt injection and jailbreaks.
Outside clients
Which assistants can call the agents?
Look forA managed MCP server that exposes one governed Cortex Agent and no raw SQL tool. Clients sign in with OAuth and never with hardcoded tokens. Any programmatic access token gets a least-privilege role, and each tool gets its own grant, since access to the server does not grant its tools.
Questions to ask vendors
- Which roles hold CORTEX_USER today, through PUBLIC or directly?
- Does our data residency policy allow cross-region inference, and for which geography?
- Do our contract terms treat Usage Data the way legal expects for prompts?
- Which external assistants will call the agents, and under which role does each session run?
Red flags
- Cortex left open to every user through PUBLIC.
- A Cortex Search service created under ACCOUNTADMIN, which then answers with that role's rights.
- An MCP server exposing a SQL execution tool to business users when they should get a governed agent.
- Assuming Guardrails are on when the account is not on Enterprise Edition or has cross-region inference disabled.
Products in this piece
Sources
- Official documentation
- 9
- Public source
- 3
- Snowflake docs: User access and settings for agents
- Snowflake docs: Overview of Snowflake CoWork
- Snowflake docs: Cross-region inference
- Snowflake docs: Governance and availability
- Snowflake docs: Snowflake AI and ML
- Snowflake docs: Cortex AI Guardrails
- Snowflake docs: Snowflake-managed MCP server
- Snowflake docs: Snowflake CoWork troubleshooting
- Reddit post on CoWork and Claude connector permissions (Aug 12, 2026)
- Reddit post weighing Claude Desktop on a Snowflake MCP server against CoWork (Aug 12, 2026)
- GitHub issue from Xero: Snowflake Intelligence grants in Terraform (Feb 5, 2026)
- Snowflake docs: ALTER USER (ALLOWED_INTERFACES)