Snowflake Extends Data Lineage to AI Agents: Semantic Layer Becomes Governance Boundary

Snowflake Extends Data Lineage to Cortex Agents

On September 2, Snowflake launched Data Lineage for Cortex Agents. When a Cortex Agent uses a Cortex Analyst Tool that references a Semantic View, Snowflake now includes that dependency in the lineage graph. Since Semantic Views already trace downstream to underlying tables, the lineage chain extends from Table → Semantic View → Cortex Analyst Tool → Cortex Agent.

Snowflake defines this capability conservatively: lineage shows the data a Cortex Agent can reach based on its current specification — not a full runtime trace of which tables and columns were actually read for a specific answer. The relationships are recorded and calibrated when an agent is created or when ALTER AGENT … COMMIT VERSION is executed; removing a tool from the specification removes the corresponding lineage edge on the next version commit.

This reachability view is valuable because it treats the agent as a formal downstream data consumer. Traditional lineage stops at dashboards (Table → View → Dashboard); now the chain continues to the agent. Enterprises previously struggled to answer "which data can this AI ultimately reach?" across fragmented permission layers (database, BI, model prompts, agent tools). Snowflake's update provides that map.

Semantic View as the Governance Guardrail

Snowflake does not let agents query raw tables directly. Cortex Agents bind to Semantic Views via Cortex Analyst Tools. After an April 2025 execution update, agents generate SQL directly from Semantic Views, but the Semantic View still governs joins, dimensions, and metric calculations. Routing Mode prioritizes Semantic View definitions, ensuring metrics, joins, and filters adhere to governed semantics.

The Semantic View acts as an enterprise semantic guardrail: an agent may have database permissions but should not freely invent business definitions. A sales agent with valid data access could still compute "customer count" as account count or "revenue" as order amount — syntactically correct SQL that is semantically wrong. The issue is not access control but semantic control.

Snowflake's product direction is consistent: on August 28, 2025, Snowflake recommended migrating from standalone Cortex Analyst to Cortex Agents, noting that existing Semantic Views need not be rebuilt and Verified Queries are retained because agents continue using the same Semantic Views. The agent layer grows upward while the semantic layer remains between AI and enterprise data. In the BI era, it prevented two dashboards from calculating different revenues; in the agent era, it also prevents AI from inventing a third revenue definition.

Databricks Converges via Unity Catalog and Genie Ontology

Databricks' Genie One and Genie Ontology approach the same architectural position from a different angle. Genie Ontology is defined as a unified context layer giving Genie a "business-aware organizational map." It combines:

Governed, certified Unity Catalog semantics: Metric Views, Domains, Pages, certification/deprecation signals.

Inferred context automatically extracted from existing assets and usage: Metric Views, Dashboards, SQL Queries, knowledge embedded in Genie Agents.

Context snippets can be specific: how "Active User" is deduplicated, which authoritative asset defines "Revenue," conditions for "Qualified Lead." Genie assigns authority scores, ranks by relevance, resolves conflicts, and enforces Unity Catalog permissions on every request — users cannot bypass permissions via AI.

Genie One MCP Server allows external MCP clients or agents to send natural language questions; Genie uses the Ontology to locate enterprise data, write SQL, and return sourced answers. Databricks explicitly states: Unity Catalog permissions are enforced on every request .

Both platforms answer the same architectural question: what sits between the agent and raw data? The answer is not just a vector database or a prompt, but a governed semantic layer.

Agent Governance Introduces "Semantic Permissions"

Traditional data permissions are straightforward: user A can read Sales table, user B cannot. Agents complicate this because "can read data" and "allowed to interpret data in what way" become separate questions. A finance agent with revenue table access should not arbitrarily choose among ARR, GAAP Revenue, Bookings, or Cash Collection. A sales agent with CRM access should not ad-hoc define "churned customer." As agents plan, discover data, and write SQL autonomously, this freedom needs constraints.

Enterprise Data Agent governance thus becomes a continuous chain:

Data — determines what the agent can touch.

Semantics — determines how that data is interpreted via business definitions.

Agent — determines who consumes the data and definitions.

Trace and Lineage — determines whether relationships can be reconstructed when issues arise.

Snowflake placing Semantic View into Cortex Agent lineage addresses this. Future audits will ask not only "Who accessed this table?" but also "Which agent could reach this data, through which governed semantic definition?" The former is traditional data governance; the latter approaches agent governance.

The term "Agent Governance Boundary" is not an official product term from Snowflake or Databricks, but an architectural abstraction from both product paths: the semantic layer increasingly sits at the intersection of data permissions, business meaning, and agent behavior. It is not the only boundary, but a critical one that is hard to bypass.

Semantic Layer Persists with a Changed KPI

Recently, the semantic layer has been questioned: if LLMs can read schemas, documentation, write SQL, and even auto-generate semantic models, do enterprises still need to maintain this layer long-term? If its only value is reusing a few metrics for dashboards, the skepticism is valid — stronger AI may automate traditional modeling.

Snowflake and Databricks' recent moves suggest a different answer: the semantic layer's value shifts from "helping AI find answers more easily" to "ensuring AI can only find answers within approved enterprise semantics." The difference is subtle but architecturally significant. The former pursues Accuracy ; the latter simultaneously addresses Accuracy, Authorization, Consistency, and Auditability .

The semantic layer is not a silver bullet. Production agents still require IAM, table/column permissions, tool permissions, MCP policies, authentication, runtime trace, action approval, etc. Snowflake's agents are constrained by Snowflake privileges and tool execution context; Databricks' MCP and Genie One embed Unity Catalog permissions in the request path. The semantic layer is a crucial puzzle piece, not a universal pass.

The nature of failure changes. Previously, a poorly governed semantic layer led to mismatched dashboard numbers and meetings arguing over definitions. Now, an agent acting on wrong semantics can generate reports, call tools, modify workflows, and trigger downstream business actions. A semantic error propagates along the agent's execution chain. An agent with valid permissions but misunderstood business definitions is more dangerous than a system that simply errors — because everything looks normal.

As agents enter production data systems, the semantic layer's KPI evolves: not just making everyone compute the same number, but ensuring AI knows which enterprise facts to act upon and that issues remain traceable.