To prepare Snowflake data for AI, work through seven steps in dependency order: scope one domain with about 10 test questions, classify and mask sensitive columns by tag, describe tables and name owners, set data metric functions, build a semantic view, redact and index documents for Cortex Search, then give the agent’s users a least-privilege access role and trace what the agent reads.
Call the result an agent-ready table: a Snowflake table with classification tags, masking by tag, reviewed descriptions, a named owner, quality expectations and a place in a semantic view. Each step below ends with a check you can run before moving on.
- Cortex Agents is the consumer, generally available since 2025-11-04 (Snowflake release notes).
- On 2026-08-28 Snowflake recommended moving from Cortex Analyst to Cortex Agents, adding: “Your semantic views carry over unchanged.”
- Tag-based masking, classification, data metric functions, access history and lineage require Enterprise Edition or higher.
| Item | Detail |
|---|---|
| Scope | One business domain, 5 to 10 tables, per Snowflake’s semantic views best-practices guide |
| Difficulty | Intermediate: SQL plus role administration |
| Prerequisites | Enterprise Edition for Steps 2, 4 and 7; a role with the create privileges in the checklist below; about 10 test questions |
| Tools | Snowsight or SQL, Cortex Agents, optionally the Snowflake-managed MCP server |
Why does Snowflake data need preparation before an AI agent can use it?
An agent in Snowflake generates SQL from the semantic view and the metadata behind it. Preparing data for AI means encoding meaning, permissions and quality as Snowflake objects before the agent reads them.
Snowflake’s Horizon Catalog documentation puts the problem plainly: “Without business context, AI agents cannot distinguish authoritative assets from noise.” A column called amt in three schemas looks identical to a model until a description and an owner tell them apart.
Permissions follow the person asking. The Cortex Agents documentation says the service “determines permissions from the Snowflake context of the request,” so loose grants on your users’ roles become loose answers.
Snowflake also publishes a scoring model. Its AI-Ready Data Framework guide (as of its Apr 7, 2026 update) “provides six factors, 62 measurable requirements, and five workload profiles,” and the agents profile carries 37 of those requirements. The framework “ships as an installable agent skill” that “scores every requirement 0–1, and guides you through remediation.” Snowflake marks the guide as not maintained on an ongoing basis. Use the framework to score a domain; the run order below sequences the Snowflake objects for one domain.
For the platform-neutral view, start with what makes data AI-ready or a broader AI readiness assessment. The map of where Snowflake’s native context ends covers the boundary question.
What order should you prepare Snowflake data for AI in?
Prepare Snowflake data for AI in dependency order, because each object builds on the one before it: masking needs tags, semantic views draw on described columns, and agent access needs both.
Classification applies your own tag through a tag map, and the masking policy attaches to that tag. Descriptions feed the semantic view. Lineage comes last because it can only trace objects you have already built, and an agent appears in lineage only if it was created, or had a new version committed, after the 2026-09-02 change. The shape matches a platform-neutral prep guide and preparing data for natural language analytics; the table maps it to Snowflake objects, numbered by step.
| Step | What you are doing | Snowflake object or command | Status (as of 2026-11-02) | Source |
|---|---|---|---|---|
| 1 | Pick one domain and 10 test questions before touching a table | Evaluation set; start with 5 to 10 tables | Guidance | Best-practices guide (Feb 3, 2026) |
| 2a | Find sensitive columns automatically | SNOWFLAKE.DATA_PRIVACY.CLASSIFICATION_PROFILE with 'auto_tag': true and a tag_map, then ALTER DATABASE ... SET CLASSIFICATION_PROFILE |
AI mode: Public Preview (2026-08-17) | Use SQL to set up sensitive data classification; 2026-08-17 note |
| 2b | Protect them once, by tag | CREATE TAG, CREATE MASKING POLICY, ALTER TAG ... SET MASKING POLICY |
Tag-based masking documented; tag-based row access, aggregation, projection and join policies: Public Preview (2026-07-21) | Tag-based masking; Object tagging; 2026-07-21 note |
| 3a | Say what each table and column means | COMMENT ON ... IS, or CALL AI_GENERATE_TABLE_DESC(...) then review |
SQL descriptions GA (2025-09-29) | COMMENT; SQL descriptions; 2025-09-29 note |
| 3b | Name an owner the agent’s answers trace back to | CREATE CONTACT, ALTER TABLE ... SET CONTACT STEWARD = ... |
GA (2025-08-08) | Using Contacts; 2025-08-08 note |
| 4 | Put a measurable quality floor under the table | ALTER TABLE ... ADD DATA METRIC FUNCTION ... EXPECTATION, DATA_METRIC_SCHEDULE |
Cortex Data Quality suggestions and Snowsight UI: Preview (2026-02-23); dashboard: Public Preview (2026-07-29) | Use SQL to set up DMFs; Expectations; 2026-02-23 note; 2026-07-29 note |
| 5 | Encode business meaning the agent generates SQL from | CREATE SEMANTIC VIEW with relationships, facts, metrics, SAMPLE_VALUES/IS_ENUM, AI_SQL_GENERATION, AI_VERIFIED_QUERIES, TAG |
Querying GA (release 9.25, Aug 2025); verified queries in DDL 2026-04-05; sample values in DDL 2026-06-25; range joins and USING relationship option: Preview |
CREATE SEMANTIC VIEW; SQL guide; Release 9.25 |
| 6 | Make documents and free text retrievable | AI_PARSE_DOCUMENT, AI_REDACT, CREATE CORTEX SEARCH SERVICE; WITH CORTEX SEARCH SERVICE on fuzzy-matched dimensions |
AI_REDACT GA (2025-12-08); multi-index search GA (2026-03-12) | CREATE CORTEX SEARCH SERVICE; AI_REDACT; 2025-12-08 note; 2026-03-12 note |
| 7a | Expose it to the agent with least privilege | CREATE AGENT with Cortex Analyst and Cortex Search tools; optionally CREATE MCP SERVER; grants to an access role |
Cortex Agents GA (2025-11-04); managed MCP server GA (2025-11-04) | 2025-11-04 Cortex Agents note; 2025-11-04 MCP note; MCP server docs |
| 7b | Make every answer traceable | SNOWFLAKE.CORE.GET_LINEAGE; external lineage through OpenLineage events |
Agent lineage (2026-09-02); external lineage GA (2026-09-03); semantic views: object-level lineage, for views created from early Feb 2026 | Data lineage; GET_LINEAGE; 2026-09-02 note; 2026-09-03 note |
| 7c | Watch what the agent actually reads | SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY, including the agents_info column |
Documented; Enterprise Edition; agents_info added 2026-08-03 |
Access History; 2026-08-03 note |
What do you need before you start preparing Snowflake data for AI?
Before you start, confirm your Snowflake edition, your role’s privileges and your test questions, because three of the seven steps rely on Enterprise Edition features.
Edition check
| Prep capability | Edition requirement (Snowflake docs, verbatim) | Source |
|---|---|---|
| Create and set tags | “Creating and setting tags is available to all accounts.” | Introduction to object tagging |
| Tag propagation, tag-based masking | “Your account must be Enterprise Edition or higher to use the following capabilities:” followed by “Tag propagation” and “Tag-based masking policies” | Introduction to object tagging |
| Sensitive data classification | “Sensitive data classification requires Enterprise Edition or higher.” | Sensitive data classification |
| DMFs and data quality monitoring | “Data Quality Monitoring requires Enterprise Edition.” | Introduction to data quality checks |
| Access history | “Access History requires Enterprise Edition (or higher).” | Access History |
| Data lineage | “This feature requires Enterprise Edition (or higher).” | Data Lineage |
The data quality introduction calls out trial accounts as unsupported for DMFs, so plan Step 4 on a paid Enterprise account.
Access and people checklist
- [ ] A role that can create tags and masking policies (tag-based masking), semantic views (CREATE SEMANTIC VIEW), Cortex Search services (CREATE CORTEX SEARCH SERVICE) and agents (CREATE AGENT)
- [ ] A named steward or distribution list for the Step 3 contact
- [ ] One business domain and 5 to 10 tables
- [ ] About 10 representative questions with known-good answers, the evaluation set you reuse in Step 7
Scope and ownership are context engineering decisions you make before any SQL runs. They are part of a context layer, too.
The SQL on this page follows the syntax in Snowflake’s documentation code blocks; it was not run against a live account, so test each block in a dev account first.
Step 1: Pick one domain and write ten test questions
Start by choosing one business domain and writing about ten questions the agent must answer correctly, so every later step has a test.
Scope keeps the semantic view small. Snowflake’s best-practices guide for semantic views recommends starting with 5 to 10 tables and building an evaluation set of representative questions.
Pick a domain that already has an owner. Then write questions that probe the failure points in the symptom table further down:
- one filter on a category value, such as revenue for one region
- one loosely typed customer or product name
- one fiscal-period question
Check it: every question has an expected answer written down, and the table list sits inside the 5 to 10 range. Don’t model the whole warehouse at once. When the steps are done, test the result with the AI-ready data checklist.
Step 2: Classify sensitive columns and mask them by tag
Classify sensitive columns automatically, map them to your own tag, then attach one masking policy to that tag so every column carrying it is masked.
Cortex Agents take permissions from the request, so masking applies to the role of the user asking (how agent identity maps to a role). Masking by tag protects every column that carries the tag. Add a tag map to the classification profile and the classifier applies that tag to new sensitive columns too, including columns added next quarter.
A classification profile with 'auto_tag': true, set on the database, applies Snowflake’s system classification tags as it classifies. A masking policy can’t be assigned to a system tag, so add a tag_map that maps categories such as EMAIL to your own tag. Then create the tag and the policy, and attach the policy with ALTER TAG ... SET MASKING POLICY, per the tag-based masking docs. To scope rows by user as well, add a row access policy.
Two limits matter. On wide tables, “the maximum number of unique tag-entity associations is 100” per CREATE or ALTER TABLE statement (object tagging introduction). And once the policy sits on the tag, neither can be dropped. To swap the policy, use ALTER TAG ... SET MASKING POLICY ... FORCE; an unset followed by a set leaves the column unprotected in between, which the docs warn could lead to a data leak.
SQL for this step
-- Step 2, tag and masking policy (Enterprise). Shape from tag-based-masking-policies (Example 1 and the column SET TAG example).
CREATE TAG IF NOT EXISTS governance.tags.pii;
CREATE MASKING POLICY IF NOT EXISTS governance.policies.email_mask
AS (val string) RETURNS string ->
CASE
WHEN CURRENT_ROLE() IN ('SALES_ADMIN') THEN val
ELSE '***MASKED***'
END;
ALTER TAG governance.tags.pii SET MASKING POLICY governance.policies.email_mask;
ALTER TABLE analytics.sales.orders MODIFY COLUMN
customer_email SET TAG governance.tags.pii = 'email';
Sources: Tag-based masking policies; IF NOT EXISTS from CREATE TAG and CREATE MASKING POLICY. For role hierarchy, the CREATE MASKING POLICY page points to IS_ROLE_IN_SESSION over CURRENT_ROLE.
To classify at scale and map the classifier’s EMAIL category to the masked tag:
-- Step 2, classification profile with a tag map. From classify-auto and CREATE CLASSIFICATION_PROFILE.
-- Run it in schema analytics.sch, the schema the ALTER DATABASE line names.
CREATE OR REPLACE SNOWFLAKE.DATA_PRIVACY.CLASSIFICATION_PROFILE
my_classification_profile(
{
'minimum_object_age_for_classification_days': 0,
'maximum_classification_validity_days': 30,
'auto_tag': true,
'tag_map': {
'column_tag_map': [
{
'tag_name': 'governance.tags.pii',
'tag_value': 'email',
'semantic_categories': ['EMAIL']
}
]
},
'classify_views': false
});
ALTER DATABASE analytics
SET CLASSIFICATION_PROFILE = 'analytics.sch.my_classification_profile';
Sources: Use SQL to set up sensitive data classification; CREATE CLASSIFICATION_PROFILE.
Check it: a query run under a role other than SALES_ADMIN returns ***MASKED*** for customer_email, and after the next classification run a newly added email column carries governance.tags.pii and returns ***MASKED*** too. Masking column by column instead of by tag is how new PII columns slip through. For the wider pattern, see how teams handle PII in AI pipelines.
Step 3: Describe every table and column, and name an owner
Write a description for each table and column the agent will use and attach a named owner, because Semantic View Autopilot extracts those descriptions when it drafts a semantic view, and the owner is who checks a wrong answer.
Draft first, then review. AI_GENERATE_TABLE_DESC generates table and column descriptions in SQL. It returns a draft: to save one, “you must manually execute a SQL statement that includes the SET COMMENT parameter.” Set 'use_table_data' to true to sample table data, which the docs present as a way to improve accuracy. In Snowsight, bulk generation works “with a limit of 50 columns at a time,” and a saved description “is preserved in the COMMENT property of the column, table, or view” (Generate descriptions with Snowflake Cortex).
The docs’ own sample output reads: “A column holding data of type DecimalType representing age values.” It describes the column’s type, so review drafts before saving them.
Save the reviewed text with COMMENT ON TABLE and COMMENT ON COLUMN. Since the 2026-10-12 Horizon Context preview, “The APPLY COMMENT privilege lets data stewards curate descriptions without MODIFY or OWNERSHIP.” Then make ownership an object: Snowflake Contacts let you CREATE CONTACT and attach it with SET CONTACT STEWARD, and SNOWFLAKE.CORE.GET_CONTACTS shows who is attached.
An owner plus an expectation is the start of a data contract for AI.
SQL for this step
-- 3a. Describe it. AI draft from sql-cortex-descriptions; COMMENT syntax from sql-reference/sql/comment.
-- The CALL returns a draft and does not save it.
CALL AI_GENERATE_TABLE_DESC(
'analytics.sales.orders',
{
'describe_columns': true,
'use_table_data': false
});
COMMENT ON TABLE analytics.sales.orders IS 'One row per confirmed customer order, net of cancellations.';
COMMENT ON COLUMN analytics.sales.orders.amount IS 'Order value in USD after discounts, before tax.';
-- 3b. Owner. From contacts-using.
CREATE CONTACT sales_data_stewards EMAIL_DISTRIBUTION_LIST = '[email protected]';
ALTER TABLE analytics.sales.orders SET CONTACT STEWARD = sales_data_stewards;
Sources: Using SQL to generate object descriptions; COMMENT; Using Contacts.
Check it: every in-scope column has a non-empty COMMENT a business user would recognize, and GET_CONTACTS returns the steward.
Step 4: Set a data quality floor with data metric functions
Attach data metric functions with expectations to each table, so stale, duplicated or null-heavy data shows up as a failed expectation you can alert on.
“A DMF measures an attribute of your data such as how many NULL values exist in a column,” and “By default, the DMF schedule runs a DMF once every hour” (data quality introduction). For a table loaded every few minutes, set a short interval such as DATA_METRIC_SCHEDULE = '5 MINUTE' or a CRON schedule, per Use SQL to set up data metric functions. TRIGGER_ON_CHANGES runs only when DML modifies the table, so a FRESHNESS check on it never fires once loads stop. “All data metric functions on a table or view follow the same schedule,” so the interval you pick covers every check below.
The system DMFs include the three checks used below: NULL_COUNT, DUPLICATE_COUNT and FRESHNESS. Add an EXPECTATION to each and test with SYSTEM$EVALUATE_DATA_QUALITY_EXPECTATIONS, as the expectations page shows. DMFs “use serverless compute resources that incur costs,” listed under Data Quality Monitoring on the monthly bill, so weigh that when you pick the interval.
SQL for this step
-- 4. Quality floor (Enterprise). From data-quality-working and data-quality-expectations.
ALTER TABLE analytics.sales.orders SET
DATA_METRIC_SCHEDULE = '5 MINUTE';
ALTER TABLE analytics.sales.orders
ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.NULL_COUNT ON (customer_id)
EXPECTATION no_null_customers (VALUE = 0);
ALTER TABLE analytics.sales.orders
ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.DUPLICATE_COUNT ON (order_id)
EXPECTATION no_duplicate_orders (VALUE = 0);
ALTER TABLE analytics.sales.orders
ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.FRESHNESS ON (loaded_at)
EXPECTATION lessThan30Mins (VALUE < 1800);
SELECT *
FROM TABLE(SYSTEM$EVALUATE_DATA_QUALITY_EXPECTATIONS(
REF_ENTITY_NAME => 'analytics.sales.orders'));
Sources: Use SQL to set up data metric functions; Use SQL to work with expectations.
Check it: the evaluate call returns all three expectations passing. DMFs test the data; context evals test the answer, and you want both. More on thresholds in data quality for AI agents.
Step 5: Build a semantic view the agent generates SQL from
Define a semantic view over your described tables, because Cortex Agents generate SQL from it.
“Semantic views improve accuracy by combining LLM reasoning with rule-based definitions,” says the semantic views overview. The view carries its own COMMENT clauses, so you copy the Step 3 text into it. Have one owner keep both current. Build it in this order, using CREATE SEMANTIC VIEW and the SQL guide for semantic views:
- TABLES, each with a primary key.
- RELATIONSHIPS. The best-practices guide says joins happen only when relationships are defined explicitly.
- FACTS, the row-level values metrics are built from.
- DIMENSIONS, with
WITH SYNONYMSfor the words people use andSAMPLE_VALUES (...) IS_ENUMon category columns. The 2026-06-25 release note states: “When IS_ENUM is set, Cortex Analyst only chooses from those values when filtering on the column.” A value missing from the list can’t be used as a filter, so update the list when a new region appears. - METRICS.
AI_SQL_GENERATIONcustom instructions, in the DDL since 2026-01-12, for conventions such as the guide’s example: “Our fiscal year starts on February 1st, not January 1st”.AI_QUESTION_CATEGORIZATIONfor questions the agent should decline (example in the symptom table below).AI_VERIFIED_QUERIESwithVERIFIED_BY, in the DDL since 2026-04-05. The best-practices guide suggests starting with 10 to 20.COPY GRANTS, so aCREATE OR REPLACEkeeps the Step 7 grants on the view.
For loosely typed product, customer or company names, add WITH CORTEX SEARCH SERVICE to the dimension; the best-practices guide reserves it for name columns over numeric or date columns. To skip the hand-written DDL, Semantic View Autopilot drafts a view in Snowsight, and Semantic Studio adds Git-backed versioning.
SQL for this step
-- 5. Semantic view. Clause order from CREATE SEMANTIC VIEW; SAMPLE_VALUES, IS_ENUM, WITH SYNONYMS and VERIFIED_BY forms from the SQL guide.
CREATE OR REPLACE SEMANTIC VIEW analytics.sales.orders_sv
TABLES (
orders AS analytics.sales.orders
PRIMARY KEY (order_id)
COMMENT = 'Confirmed customer orders',
customers AS analytics.sales.customers
PRIMARY KEY (customer_id)
COMMENT = 'One row per customer'
)
RELATIONSHIPS (
orders_to_customers AS
orders (customer_id) REFERENCES customers (customer_id)
)
FACTS (
orders.amount AS amount
COMMENT = 'Order value in USD after discounts, before tax'
)
DIMENSIONS (
orders.region AS region
WITH SYNONYMS = ('territory', 'sales region')
COMMENT = 'Sales region'
SAMPLE_VALUES ('AMER', 'EMEA', 'APAC')
IS_ENUM,
orders.order_date AS order_date
COMMENT = 'Date the order was placed'
)
METRICS (
orders.total_revenue AS SUM(orders.amount)
WITH SYNONYMS = ('revenue', 'sales')
COMMENT = 'Total order value in USD after discounts, before tax'
)
COMMENT = 'Revenue analysis for confirmed orders'
AI_SQL_GENERATION 'Our fiscal year starts on February 1st. Round currency to 2 decimal places.'
AI_VERIFIED_QUERIES (
revenue_by_region_fy2025 AS (
QUESTION 'What was total revenue by region in fiscal year 2025 (Feb 2025 to Jan 2026)?'
VERIFIED_BY '(STEWARD = sales_data_stewards)'
SQL 'SELECT region, SUM(amount) AS total_revenue FROM orders WHERE order_date >= ''2025-02-01'' AND order_date < ''2026-02-01'' GROUP BY region'
)
)
COPY GRANTS;
Sources: CREATE SEMANTIC VIEW; Using SQL commands to create and manage semantic views; SAMPLE_VALUES and IS_ENUM release note. The fiscal-year date range in the verified query is our example; it filters on the order_date column the view declares.
Check it: each Step 1 question returns its expected answer, and a filter on “EMEA” returns rows. Don’t skip RELATIONSHIPS: Cortex Analyst will not join tables unless relationships are explicitly defined. For a deeper walk through the DDL, read Snowflake semantic views in depth.
Step 6: Redact and index documents with Cortex Search
Parse documents and transcripts, redact personal data with AI_REDACT, then index only the clean text in a Cortex Search service.
Start with AI_PARSE_DOCUMENT for files or AI_TRANSCRIBE for audio, as the AI_REDACT docs suggest. Then redact. Snowflake states that AI_REDACT “performs detection and redaction in a best-effort manner using AI models,” so review a sample of the output before you index it. CREATE TABLE ... AS SELECT redacts the rows that exist today; new transcripts need the same AI_REDACT step on arrival before the service refreshes.
Index the redacted table with CREATE CORTEX SEARCH SERVICE, using ATTRIBUTES for filter columns and TARGET_LAG for refresh. “Cortex Search Services perform searches with owner’s rights,” and a querying role needs USAGE on the service, its database and its schema (Cortex Search overview). Create the service under a role that can read only the redacted table, and keep the raw transcripts table out of your users’ access role.
Lineage has a gap on this path. Since 2026-10-06, lineage links a stage to a Cortex Search service created from that stage in Snowsight, a creation path that is still in preview. A service created with CREATE CORTEX SEARCH SERVICE, as below, doesn’t record those stage relationships.
SQL for this step
-- 6. Unstructured text: redact, then index. From ai_redact and create-cortex-search.
CREATE OR REPLACE TABLE support_db.public.transcripts_clean AS
SELECT ticket_id, region, AI_REDACT(transcript_text) AS transcript_text
FROM support_db.public.transcripts_raw;
CREATE OR REPLACE CORTEX SEARCH SERVICE support_db.public.transcripts_svc
ON transcript_text
ATTRIBUTES region
WAREHOUSE = mywh
TARGET_LAG = '1 hour'
AS (
SELECT transcript_text, region, ticket_id
FROM support_db.public.transcripts_clean
);
Sources: AI_REDACT; CREATE CORTEX SEARCH SERVICE.
Check it: a search for a known customer email returns the redacted token. Indexing raw transcripts and redacting later is the order to avoid. The same discipline applies to all unstructured data for AI.
Step 7: Expose it to the agent with least privilege, then trace what it reads
Create the agent, grant its users an access role that reaches only the semantic view, the tables under it and the search service, then use lineage and access history to confirm what it reads.
Wire the agent
Create a Cortex Agent with a Cortex Analyst tool over the semantic view and a Cortex Search tool over the search service. The agent “determines permissions from the Snowflake context of the request,” and “If the caller’s role can’t use every configured tool, the run can still continue with the tools it can access” (Cortex Agents). Least privilege therefore lives on the users’ role.
Agents outside Snowflake reach it through the Snowflake-managed MCP server, GA since 2025-11-04, one of several MCP server options for Snowflake. The MCP docs say “By default, MCP OAuth sessions use the connecting user’s DEFAULT_ROLE as the primary role,” so set each user’s DEFAULT_ROLE to the access role. “OAuth scopes control only the primary role for the MCP session. Secondary roles are separate and are controlled by the OAuth security integration.” Grants are per tool, too: “Access to the MCP Server does not give access to the tools.”
Keep raw SQL apart. The MCP docs warn: “Exposing SYSTEM_EXECUTE_SQL on the same server allows the MCP client to bypass the agent’s semantic views, verified queries, and orchestration.” Put that tool on a separate server with a least-privileged role. For the pattern beyond Snowflake, see serving semantic definitions over MCP.
At run time, Cortex AI Guardrails for CoWork and Cortex Agents became GA on 2026-05-14 for prompt-injection protection, which matters once Snowflake CoWork users start asking questions.
-- 7a. Agent, MCP server and access role. Forms from create-agent and cortex-agents-mcp; replace <placeholders>.
-- The agent spec keeps only the models, tools and tool_resources keys from the docs' first example.
CREATE OR REPLACE AGENT analytics.sales.orders_agent
FROM SPECIFICATION
$$
models:
orchestration: auto
tools:
- tool_spec:
type: "cortex_analyst_text_to_sql"
name: "Analyst1"
description: "Answers revenue questions from the orders semantic view"
- tool_spec:
type: "cortex_search"
name: "Search1"
description: "Searches redacted support transcripts"
tool_resources:
Analyst1:
semantic_view: "analytics.sales.orders_sv"
Search1:
search_service: "support_db.public.transcripts_svc"
max_results: "5"
$$;
CREATE OR REPLACE MCP SERVER analytics.sales.orders_mcp
FROM SPECIFICATION $$
tools:
- title: "Governed business data agent"
name: "business_data_agent"
type: "CORTEX_AGENT_RUN"
identifier: "analytics.sales.orders_agent"
description: "Use this agent for governed business data questions."
$$;
CREATE ROLE <mcp_access_role>;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_AGENT_USER TO ROLE <mcp_access_role>;
GRANT USAGE ON WAREHOUSE <warehouse_name> TO ROLE <mcp_access_role>;
GRANT USAGE ON DATABASE <database_name> TO ROLE <mcp_access_role>;
GRANT USAGE ON SCHEMA <database_name>.<schema_name> TO ROLE <mcp_access_role>;
GRANT USAGE ON MCP SERVER analytics.sales.orders_mcp TO ROLE <mcp_access_role>;
GRANT USAGE ON AGENT analytics.sales.orders_agent TO ROLE <mcp_access_role>;
GRANT ROLE <mcp_access_role> TO USER <username>;
ALTER USER <username> SET DEFAULT_ROLE = '<mcp_access_role>' DEFAULT_WAREHOUSE = '<warehouse_name>';
-- Only the resources the agent uses: the semantic view, the tables it reads, and the search service.
GRANT SELECT ON SEMANTIC VIEW analytics.sales.orders_sv TO ROLE <mcp_access_role>;
GRANT SELECT ON TABLE analytics.sales.orders TO ROLE <mcp_access_role>;
GRANT SELECT ON TABLE analytics.sales.customers TO ROLE <mcp_access_role>;
GRANT USAGE ON DATABASE support_db TO ROLE <mcp_access_role>;
GRANT USAGE ON SCHEMA support_db.public TO ROLE <mcp_access_role>;
GRANT USAGE ON CORTEX SEARCH SERVICE support_db.public.transcripts_svc TO ROLE <mcp_access_role>;
Sources: CREATE AGENT; Snowflake-managed MCP server.
Trace and audit
GET_LINEAGE shows what sits downstream of a table, now including agents. The 2026-09-02 release note adds a catch: “an agent whose most recent version was committed before this change doesn’t appear in lineage until you commit a new version.” Semantic views have their own limit: per the lineage docs, lineage covers semantic views created from early February 2026 onward, at object level only, so recreate an older view to see it. External lineage became GA on 2026-09-03, so OpenLineage events from your transformation and orchestration tools join the same graph.
ACCESS_HISTORY records which objects each query read, by user, and since 2026-08-03 its agents_info column names the Cortex Agent that read data on a user’s behalf. The view can lag by up to 3 hours (Account Usage), so check after that window. See tracing AI answers to source and AI-ready data lineage.
-- 7b. Verify lineage and access. From get_lineage-snowflake-core, access-history and the 2026-08-03 agents_info note.
SELECT DISTANCE, SOURCE_OBJECT_NAME, TARGET_OBJECT_DOMAIN, TARGET_OBJECT_NAME
FROM TABLE (SNOWFLAKE.CORE.GET_LINEAGE('analytics.sales.orders', 'TABLE', 'DOWNSTREAM', 2));
SELECT user_name, query_id, query_start_time, direct_objects_accessed, base_objects_accessed, agents_info
FROM snowflake.account_usage.access_history
ORDER BY 1, 3 desc;
Sources: GET_LINEAGE; Access History; agents_info release note.
Check it: rerun the Step 1 evaluation set through the agent, then confirm the ACCESS_HISTORY rows whose agents_info names your agent show only in-scope objects.
Why is your Snowflake agent giving wrong answers?
Each row pairs a symptom with the prep step and the Snowflake feature that addresses it.
| What you see | Prep step that is missing | Snowflake feature that fixes it | Source |
|---|---|---|---|
| Filter uses a value that isn’t stored (asks for “Americas”, column holds “AMER”) | Representative values not declared | SAMPLE_VALUES (...) IS_ENUM on the dimension |
“When IS_ENUM is set, Cortex Analyst only chooses from those values when filtering on the column.” 2026-06-25 note |
| A loosely typed customer or product name never matches | Fuzzy text match not wired | WITH CORTEX SEARCH SERVICE on the dimension, for product, customer or company names over numeric or date columns |
SQL guide; Best-practices guide |
| A question that spans two tables fails or joins wrong | Relationships not declared | RELATIONSHIPS (...) in the semantic view |
Joins happen only when relationships are defined explicitly: Best-practices guide (Feb 3, 2026) |
| Fiscal-year or rounding conventions ignored | Org conventions not written down for the model | AI_SQL_GENERATION '<instructions>' |
2026-01-12 note; guide example “Our fiscal year starts on February 1st, not January 1st”. |
| Agent answers questions it should refuse or clarify | Question categorization not set | AI_QUESTION_CATEGORIZATION '<instructions>' |
“Reject all questions asking about users. Ask users to contact their admin.” SQL guide |
| Answers to common questions drift between runs | Common questions not pinned to verified answers | AI_VERIFIED_QUERIES (...); start with 10 to 20 |
2026-04-05 note; 10 to 20 from the Best-practices guide |
| Column descriptions read “A column holding data of type …” | AI descriptions saved without review | AI_GENERATE_TABLE_DESC output reviewed, then COMMENT ON COLUMN |
“A column holding data of type DecimalType representing age values.” SQL descriptions |
| Agent returns raw emails or names | Sensitive columns not classified and masked | Classification profile with auto_tag and a tag_map, plus a masking policy on the mapped tag |
Use SQL to set up sensitive data classification; Tag-based masking |
| PII appears in answers drawn from documents or transcripts | Unstructured text not redacted before indexing | AI_REDACT before CREATE CORTEX SEARCH SERVICE |
“AI_REDACT performs detection and redaction in a best-effort manner using AI models.” AI_REDACT |
| Confident answer from a table that stopped loading | Freshness floor not set on a time-based schedule | SNOWFLAKE.CORE.FRESHNESS DMF with an EXPECTATION, and DATA_METRIC_SCHEDULE = '5 MINUTE' or a CRON schedule |
Expectations; Use SQL to set up DMFs |
| MCP client gets answers that ignore the semantic view | Raw SQL tool exposed next to the governed tool | Keep SYSTEM_EXECUTE_SQL on a separate MCP server with a least-privileged role |
“Exposing SYSTEM_EXECUTE_SQL on the same server allows the MCP client to bypass the agent’s semantic views, verified queries, and orchestration” MCP server docs |
| You cannot tell which tables an agent can reach | Agent missing from lineage | Commit a new agent version after 2026-09-02 | “an agent whose most recent version was committed before this change doesn’t appear in lineage until you commit a new version.” 2026-09-02 note |
| Nobody knows who to ask when an answer looks wrong | Owner not attached to the object | CREATE CONTACT + SET CONTACT STEWARD; VERIFIED_BY '(STEWARD = data_stewards)' |
Using Contacts; SQL guide |
Prep built once decays as tables and owners change. Rerun the Step 1 evaluation set after every schema change, and use the symptom table as a triage list.
What changed in Snowflake’s AI data prep features in 2025 and 2026?
Between April 2025 and October 2026, Snowflake added the semantic view clauses, lineage and audit columns this page uses, and made Cortex Agents the recommended consumer. The run-order table carries the other dates.
| Date | Change | Why it matters for prep | Release note |
|---|---|---|---|
| 2025-04-17 | Semantic views (Preview) | Semantic models can be stored as schema-level objects | 2025-04-17 |
| 2025-08-25 to 08-28 | Querying semantic views GA (release 9.25) | SELECT … SEMANTIC_VIEW is production | Release 9.25 |
| 2025-11-04 | Cortex Agents GA; Snowflake-managed MCP server GA | The consumer of all this prep, inside and outside Snowflake | Agents; MCP |
| 2026-08-03 | agents_info column in ACCESS_HISTORY |
Names the agent behind each access | 2026-08-03 |
| 2026-08-28 | Snowflake recommends moving from Cortex Analyst to Cortex Agents | Prep targets the agent; “Your semantic views carry over unchanged.” | 2026-08-28 |
| 2026-09-02 | Data lineage for Cortex Agents | Trace table to semantic view to agent | 2026-09-02 |
| 2026-09-30 | Semantic Studio GA | Authoring and Git-backed versioning for semantic views | 2026-09-30 |
| 2026-10-12 | Horizon Context (Preview), APPLY COMMENT privilege | Horizon Catalog can browse external assets, trace column-level lineage across platforms, and manage tags and descriptions for 18 external sources | 2026-10-12 |
The biggest shift is the 2026-08-28 recommendation. The release note says Cortex Agents “supports every Cortex Analyst capability with higher answer quality,” and “Existing applications continue to work, and the Cortex Analyst REST API remains available.” Prep you did for Cortex Analyst still counts.
Snowflake Horizon Context, in Preview since 2026-10-12, “extends Horizon Catalog beyond Snowflake.” You can connect it to 18 sources, including BI tools and other databases, and manage their tags and descriptions in Horizon Catalog, per the release note. How Horizon Context and the Atlan context layer work together goes deeper.
How Atlan keeps Snowflake AI prep in sync with the rest of your context
Atlan, the Context Layer for AI, reads the tags and descriptions you set in Snowflake, syncs tags in both directions, and connects them to context from your other systems.
Inside a single Snowflake account, Horizon Catalog and Horizon Context hold this metadata. The design question is where definitions live when agents and data span more than one platform, which is what an enterprise context layer answers.
Per docs.atlan.com:
- Atlan’s Snowflake connector crawls Snowflake databases, schemas, tables, views and procedures, and “builds column-level lineage from query history automatically.”
- “Atlan reads object tags from Horizon and synchronizes them bidirectionally between Snowflake and Atlan” (crawl reference). Reverse sync updates tags that already exist in Snowflake, and tag sync relies on Enterprise Edition ACCOUNT_USAGE views.
- “Syncing Snowflake COMMENT fields into the Description field in Atlan is enabled by default,” so Step 3 seeds Atlan’s descriptions.
- Masking and row access policies stay defined in Snowflake and are enforced by its query engine: “Governance policies execute at the query engine layer, not the application layer” (Horizon Catalog docs).
- Atlan can “Monitor the quality of your Snowflake assets in Atlan using Snowflake’s native data metric functions” (Data Quality Studio docs). Configuring Snowflake DMFs for Atlan is labeled Private Preview on docs.atlan.com as of 2026-11-02, and is supported only on Enterprise and Business Critical editions.
- The Atlan MCP setup docs list Snowflake: “Connect from the Snowflake UI so CoWork agents can use Atlan tools, or register the server with the Cortex Code CLI.” Atlan MCP “is hosted and enabled for all Atlan tenants, with nothing to install or run.” See what the Atlan MCP server exposes.
For the architecture, see how the context layer works with Snowflake’s data plane.
FAQs about preparing Snowflake data for AI
1. What does AI-ready data mean in Snowflake?
Snowflake’s AI-Ready Data Framework defines it with six factors, 62 measurable requirements and five workload profiles, as of the guide’s Apr 7, 2026 update. The agents profile carries 37 of those requirements. In practice, AI-ready Snowflake data carries tags, masking, descriptions, owners, quality expectations and a semantic view an agent can generate SQL from.
2. Do you need Snowflake Enterprise Edition to prepare data for AI?
Tag-based masking, sensitive data classification, data metric functions, access history and lineage all require Enterprise Edition or higher, according to Snowflake’s docs. Creating and setting tags is available to all accounts. For other features, check the edition banner on each docs page.
3. Should you prepare data for Cortex Analyst or Cortex Agents?
Prepare for Cortex Agents. On 2026-08-28 Snowflake recommended transitioning to Cortex Agents, which it says supports every Cortex Analyst capability with higher answer quality. Your semantic views carry over unchanged, and the Cortex Analyst REST API remains available.
4. Can Snowflake write table and column descriptions for you?
Yes. AI_GENERATE_TABLE_DESC drafts descriptions in SQL, generally available since 2025-09-29, and Snowsight generates them in bulk, 50 columns at a time. Review each draft before saving, because the saved text lands in the COMMENT property, which Semantic View Autopilot extracts when it drafts a semantic view.
5. How many verified queries should a semantic view start with?
Start with 10 to 20 verified queries for the most common questions, per Snowflake’s best-practices guide for semantic views. Since 2026-04-05 they live in the AI_VERIFIED_QUERIES clause of the semantic view DDL, versioned with the view.
6. How do you keep PII out of answers from Snowflake agents?
Classify columns with a classification profile set to auto_tag, with a tag map that applies your own sensitivity tag, attach a masking policy to that tag, and run AI_REDACT on documents before indexing them in Cortex Search. Snowflake describes AI_REDACT as best-effort, so review a sample of its output.
7. When did Snowflake semantic views become generally available?
Querying semantic views became generally available in Snowflake release 9.25, in late August 2025. Semantic views entered Preview on 2025-04-17, and Semantic Studio, the authoring tool, became generally available on 2026-09-30.
Sources
-
AI-Ready Data Framework: Assess and Remediate Your Data for AI, Snowflake Developers
-
Best Practices for Creating Semantic Views for Cortex Analyst, Snowflake Developers
-
Using SQL commands to create and manage semantic views, Snowflake Documentation
-
Introduction to sensitive data classification, Snowflake Documentation
-
Use SQL to set up sensitive data classification, Snowflake Documentation
-
Introduction to data quality checks, Snowflake Documentation
-
Use SQL to set up data metric functions, Snowflake Documentation
-
Generate descriptions with Snowflake Cortex, Snowflake Documentation
-
Using SQL to automatically generate object descriptions, Snowflake Documentation
-
Apr 17, 2025: Semantic views (Preview), Snowflake Release Notes
-
Aug 08, 2025: Contacts (General availability), Snowflake Release Notes
-
9.25 Release notes: Aug 25, 2025-Aug 28, 2025, Snowflake Release Notes
-
Nov 04, 2025: Cortex Agents (General availability), Snowflake Release Notes
-
Nov 04, 2025: Snowflake-managed MCP server (General availability), Snowflake Release Notes
-
Jan 12, 2026: Specifying custom instructions in semantic views, Snowflake Release Notes
-
Feb 23, 2026: Simplified setup for Data Quality Monitoring, Snowflake Release Notes
-
Mar 12, 2026: Recent Cortex Search updates (Generally Available), Snowflake Release Notes
-
Apr 05, 2026: Support for verified queries in semantic views, Snowflake Release Notes
-
July 21, 2026: Tag-based data protection policies (Public Preview), Snowflake Release Notes
-
Jul 29, 2026: Data quality monitoring dashboard (Public preview), Snowflake Release Notes
-
Aug 3, 2026: ACCESS_HISTORY view: New agents_info column, Snowflake Release Notes
-
August 17, 2026: AI mode for sensitive data classification (Public Preview), Snowflake Release Notes
-
Sep 02, 2026: Data lineage for Cortex Agents, Snowflake Release Notes
-
Sep 03, 2026: External lineage (General availability), Snowflake Release Notes
-
Sep 30, 2026: Semantic Studio (General availability), Snowflake Release Notes
-
Oct 12, 2026: Horizon Context (Preview), Snowflake Release Notes
-
Configure Snowflake data metric functions, Atlan Documentation
