Data governance for Snowflake Intelligence agents

Snowflake Intelligence is Snowflake's ready-to-use agentic application. Business users submit natural language questions, and the system queries structured data, searches documents, and synthesizes a cited response, without requiring SQL or data engineering involvement. It went GA in November 2025 and expanded significantly in April 2026 with multi-step reasoning, personalization, and support for external data sources via MCP connectors.

Data governance for Snowflake Intelligence agents starts with understanding the architecture behind the product, because the governance questions flow directly from how agents access data. The product is one layer in a stack, and each layer introduces different governance considerations.

How Snowflake Intelligence works: the product stack

Snowflake Intelligence is the end-user-facing product. Behind it is a stack of three distinct components.

Cortex Agents is the orchestration layer. When a user submits a question, the agent plans which tools to call, executes them in sequence, and synthesizes a response. Cortex Agents is the intelligence layer that decides what to do and in what order.

Cortex Analyst is the text-to-SQL engine. It translates a natural language question into SQL using a semantic model, runs the query against Snowflake tables and views, and returns structured data. Cortex Analyst handles queries against structured data.

Cortex Search is the retrieval layer for unstructured content: documents, PDFs, emails, and other text sources. It uses hybrid semantic and keyword search to surface relevant context.

Cortex Agents routes between these tools based on the question. A question about a revenue figure goes to Cortex Analyst for a SQL query. A question referencing a policy document goes to Cortex Search. A question that requires both gets both. Snowflake Intelligence exposes this as a single conversational interface.

The system can also connect to external enterprise data sources via MCP connectors: Gmail, Google Calendar, Jira, Salesforce, Slack, and Google Docs are supported in the current release. Snowflake's pending acquisition of Natoma, announced May 27, 2026, is specifically designed to bring centralized identity, policy enforcement, and audit controls to this MCP connectivity layer.

How Snowflake Intelligence agents access your data

This is the governance-critical detail. Cortex Agents inherit the privileges of the Snowflake role that invokes them. If a business user's role has SELECT access on a broad set of tables, the agent running on their behalf has the same access. The agent doesn't scope down to the minimum required for the specific task it's performing.

In practice, this means the effective access model for Snowflake Intelligence agents is a function of how carefully your Snowflake RBAC is designed. An over-scoped role becomes an over-scoped agent. The agent's query can reach any table the role can reach, including tables with sensitive data that the user wasn't explicitly intended to access through a conversational interface.

This is a known issue in the Snowflake practitioner community. The recommended approach is to create dedicated service accounts for agent workloads with tightly scoped roles. But most organizations haven't yet operationalized that pattern across every agent deployment, and Snowflake Intelligence makes it easy for business users to spin up agents without IT involvement, which means new agents regularly appear with whatever role the user already has.

What Snowflake provides natively

Snowflake has built meaningful governance tooling into its platform, and it's worth understanding what each piece covers.

AI Observability. Snowflake's native AI observability capability traces every step of agent execution: input prompts, retrieved context, tool calls, LLM inference. Trace data is stored in the SNOWFLAKE.LOCAL.AI_OBSERVABILITY_EVENTS table, which records tool names called, token usage, execution duration, model used, evaluation scores, user feedback, and agent planning steps. Organizations and third-party tools can query this table to understand what agents are doing.

One important change: a breaking change in April 2026 redacted prompts and completions from this table by default. To read unredacted conversation content (what the user asked and what the agent returned), a role must be explicitly granted the READ UNREDACTED AI OBSERVABILITY EVENTS TABLE account-level privilege. This is a deliberate governance control: even Snowflake administrators can't see full conversation content without it.

Horizon Catalog. Snowflake's universal AI catalog supports RBAC, ABAC, sensitive data classification, tagging, monitoring, lineage, and AI agent support within the Snowflake environment. The AI_REDACT function can identify and mask PII in unstructured text before it enters agent context. Coverage is Snowflake-native; data and agents outside the platform are out of scope.

Cortex AI function cost monitoring. GA'd in March 2026, this gives organizations visibility into Cortex AI function spending by function, model, user, role, and warehouse. This addresses one of the top practitioner pain points: Cortex AI queries can be expensive, and without monitoring, costs accumulate without warning before a month-end bill arrives.

Budget controls. Snowflake provides resource monitors and budget controls for Cortex AI function consumption, allowing teams to set spend limits at the account, warehouse, or team level.

What native tooling doesn't cover

Three things fall outside what Snowflake's native tools address.

Data quality signals. Snowflake Intelligence has no native mechanism to validate that the tables Cortex Analyst is querying are fresh, complete, or anomaly-free before the agent uses them as the basis for its answers. If a data pipeline writes stale or incomplete data to a table and a Snowflake Intelligence agent queries that table, the agent answers confidently using bad data. There's no error signal. The answer looks like a correct answer. The reliability of Snowflake Intelligence answers is a direct function of the reliability of the underlying data, and that reliability has to be tracked upstream of the agent, not by the agent itself.

Cross-agent registry. Native Snowflake tooling doesn't provide a registry-level view of all Snowflake Intelligence agents connected across an organization, who owns each, what scope they have, and what each has done. The AI Observability table records events, but transforming that event stream into a live agent registry with ownership, authorization scope, and activity history requires additional tooling.

Enforcement at query time based on data sensitivity. Snowflake's classification and tagging capabilities can mark sensitive columns, but they don't intercept agent queries before execution to check whether the agent is authorized to access a classified field. Enforcement that prevents an agent from reading a Restricted column requires a control layer that operates between the agent's request and the query execution, not a policy applied after the fact.

How Bigeye integrates with Snowflake Intelligence

Bigeye's integration with Snowflake Intelligence connects through the SNOWFLAKE.LOCAL.AI_OBSERVABILITY_EVENTS table and the broader Snowflake data environment. The integration surfaces two layers of trust signal that the native tooling doesn't provide: data quality as a precondition for reliable agent answers, and enforcement controls over what agents can reach at query time.

Agent visibility. When a Snowflake Intelligence agent interacts with your data through the Agent Trust Hub, it appears in the agent registry with its identity, the tables it has accessed, the queries it has run, and its token consumption. Activity is attributed to the specific agent and user, giving you the audit trail that the raw event table provides in raw form but requires interpretation to use.

Data quality signals. Bigeye monitors the tables that Snowflake Intelligence agents query, tracking freshness, volume, and anomaly status using automated lineage to know which tables are in scope. When an agent queries a table, the trust layer knows whether that table's data was fresh and anomaly-free at query time. That signal appears alongside agent activity in the Trust Dashboard, so teams can see not just what agents did, but whether the data they acted on was trustworthy when they acted on it.

Classification and enforcement. AI Guardian intercepts Snowflake Intelligence agent queries before they execute and checks them against the current sensitivity classification of the requested data. An agent requesting access to a column tagged as Restricted gets blocked at the query layer, before the field is read. The enforcement runs on live signals from Data Classification, with full lineage context attached, so the check accounts for not just what a column is classified as but what it connects to upstream and downstream.

The result is an enforcement model that doesn't require redesigning Snowflake role configurations from scratch. When the role-based access model is broader than it should be for a given agent workload, AI Guardian provides the compensating control at the data layer.