Snowflake read-only roles for a semantic layer

A semantic layer on Snowflake is only as safe as the role that runs its queries. If that role can create tables, modify data, or see every raw schema, agents and BI tools inherit that power. datahashi expects a read-only Snowflake posture: least privilege for query execution, separate roles for modeling work, and clear boundaries between semantic reads and warehouse admin.

Separate builders from runners

Keep at least two roles in mind. A modeling or admin role owns semantic definitions, integrations, and warehouse objects you intentionally manage. A runtime role used by run_semantic_query should only select from the objects the semantic layer needs. Agents and Cursor MCP sessions should use the runtime path, never the builder role.

That split limits blast radius. A bad agent prompt cannot drop a table if the role cannot drop tables. A leaked runtime token cannot rewrite production data if grants are select-only.

What the runtime role should include

Grant usage on the warehouse and the database or schemas that hold governed sources and any views the semantic layer reads. Grant select on those objects. Avoid future grants that quietly expand access into new raw schemas unless you intend that expansion and review it.

Do not grant insert, update, delete, truncate, or create on runtime roles. Do not grant ownership. If the semantic layer needs a write path for materializations, that is a different job with a different role and a human-owned schedule, not something agents call through MCP.

Warehouses and resource controls

Point the runtime role at a warehouse sized for interactive semantic queries, with auto-suspend enabled. Use resource monitors or account-level controls so runaway agent traffic cannot burn the monthly budget unnoticed. Pair Snowflake controls with datahashi query limits so both the platform and the tool layer enforce bounds.

Secondary warehouses for heavy exploration are fine for humans. Keep agent MCP traffic on the constrained warehouse unless you have a deliberate, monitored exception.

Network and identity hygiene

Prefer key-pair or SSO-backed service identities over long-lived passwords in agent hosts. Scope network policies if your account uses them. Store secrets in your secret manager; do not embed Snowflake credentials in Cursor rules files or chat history.

Map each consumer to an identity you can audit: interactive user, CI bot, or MCP service. When run_semantic_query runs, you want Snowflake history and datahashi logs to agree on who asked.

Align grants with catalog exposure

If list_catalog does not expose a domain, the runtime role should not need that domain’s tables. Drift between catalog and grants creates two failure modes: agents that cannot run metrics they can see, or agents that can query data the catalog never intended to publish. Review grants when you add metrics.

Use describe_metric as the human-readable contract for what a metric needs. When a metric adds a dimension backed by a new table, update grants in the same change as the metric definition.

A minimal checklist before agents go live

• Runtime role is select-only on required objects
• Builder role is not configured in MCP or Cursor
• Warehouse auto-suspend and monitoring are on
• Secrets are rotated and not checked into repos
• A test agent can list_catalog, describe_metric, and run_semantic_query on a known metric
• The same agent cannot create or modify Snowflake objects

Snowflake read-only roles will not replace semantic validation, but they make validation meaningful. Combine them with datahashi’s MCP tools and you get a stack where agents can ask governed questions without inheriting the keys to the warehouse.