[New Feature] I tried out Snowflake-provided tags, which have entered public preview

This is Kawabata.

On August 31, 2026, Snowflake-provided tags entered Public Preview.
This feature automatically creates 6 types of ready-made governance tags in the SNOWFLAKE.TAGS schema of all accounts.

https://docs.snowflake.com/en/user-guide/object-tagging/snowflake-provided-tags

Until now, tags for cost centers and sensitivity levels had to be designed and operated with CREATE TAG for each account, but this feature allows you to use a common vocabulary across all accounts as-is. Since I actually tried it out, I'll summarize the steps and results.

【Update】
I was selected as a finalist in the "RISING COMMUNITY LEADER OF THE YEAR" category, APJ region, of the Snowflake Community Awards.
Please check the details below.

https://dev.classmethod.jp/articles/snowflake-community-awards-finalist-activities-review/

Feature Overview

Snowflake-provided tags are ready-made tags that Snowflake automatically creates in the SNOWFLAKE.TAGS schema of all accounts (referred to as "provided tags" in this article). They cannot be created or deleted by users. The following 6 types are provided.

The nature of each tag differs, and it's easiest to understand them in the following 4 categories.

• Fixed allowed values: CERTIFICATION_STATUS
• Initially defined allowed values, can be added/removed: SENSITIVITY / ENVIRONMENT
• No pre-defined allowed values (any string): COST_CENTER / PROJECT
• Controls special behavior rather than values: SKIP_TAG_PROPAGATION

Note that these are different from the classification system tags in SNOWFLAKE.CORE (such as SEMANTIC_CATEGORY) used by the auto-classification feature.

Differences from User-Defined Tags

The main differences from conventional user-defined tags are as follows.

Intended Use Cases

By using the provided tag vocabulary as-is, you can start the following governance operations using only standard tags.

• Sensitive data protection: Attach a tag-based masking policy to SENSITIVITY for automatic masking (implemented in the verification below)
• Cost allocation: Attach COST_CENTER / PROJECT to warehouses etc., and aggregate costs by tag
• Data asset certification management: Manage review status with CERTIFICATION_STATUS so users can filter for CERTIFIED data
• Environment clarification: Use ENVIRONMENT to distinguish production and development resources, useful for inventory and preventing accidental operations

For cost allocation, there is an official pattern of joining TAG_REFERENCES in ACCOUNT_USAGE with metering views (such as WAREHOUSE_METERING_HISTORY) for aggregation. The official Doc example uses user-defined tags, but in this verification, I confirmed that attaching SNOWFLAKE.TAGS.COST_CENTER to a warehouse is also possible.

https://docs.snowflake.com/en/user-guide/cost-attributing

Limitations

• As of September 2, 2026, this is a Public Preview feature. Specifications may change before GA.
• Deleting provided tags and adding tags to the SNOWFLAKE.TAGS schema are not possible.
• Allowed values of CERTIFICATION_STATUS cannot be changed even with OOB_TAG_ADMIN.
• SKIP_TAG_PROPAGATION and automatic tag propagation require Enterprise Edition or higher.
• In the verification environment, propagation stopping via SKIP_TAG_PROPAGATION could not be reproduced (described later).

Verification Environment

• Snowflake: Trial account, AWS Tokyo region
• Edition: Enterprise Edition
• Required Permissions: ACCOUNTADMIN (granting application roles, creating verification objects)

Prerequisites

Create a verification DB/schema and a customer table (20 records) containing PII-equivalent columns.

USE ROLE ACCOUNTADMIN;
USE WAREHOUSE COMPUTE_WH;

CREATE DATABASE IF NOT EXISTS PROVIDED_TAGS_VERIFY_DB;
CREATE SCHEMA IF NOT EXISTS PROVIDED_TAGS_VERIFY_DB.VERIFY;
USE SCHEMA PROVIDED_TAGS_VERIFY_DB.VERIFY;

-- Verification table (e-commerce customer data)
CREATE OR REPLACE TABLE CUSTOMERS (
    CUSTOMER_ID   NUMBER        COMMENT 'Customer ID',
    CUSTOMER_NAME VARCHAR(100)  COMMENT 'Name (PII equivalent)',
    EMAIL         VARCHAR(200)  COMMENT 'Email address (PII equivalent)',
    PHONE         VARCHAR(20)   COMMENT 'Phone number (PII equivalent)',
    PREFECTURE    VARCHAR(20)   COMMENT 'Prefecture',
    PLAN_TYPE     VARCHAR(20)   COMMENT 'Contract plan',
    SIGNUP_DATE   DATE          COMMENT 'Registration date',
    MONTHLY_FEE   NUMBER(10,0)  COMMENT 'Monthly fee'
);

INSERT INTO CUSTOMERS VALUES
    (1,  'Taro Yamada',    'taro.yamada@example.com',    '090-1111-0001', 'Tokyo',    'PREMIUM',  '2025-01-15', 3000),
    (2,  'Hanako Sato',    'hanako.sato@example.com',    '090-1111-0002', 'Osaka',    'STANDARD', '2025-02-01', 1500),
    (3,  'Ichiro Suzuki',  'ichiro.suzuki@example.com',  '090-1111-0003', 'Aichi',    'FREE',     '2025-02-14', 0),
    (4,  'Yuki Tanaka',    'yuki.tanaka@example.com',    '090-1111-0004', 'Hokkaido', 'STANDARD', '2025-03-03', 1500),
    (5,  'Kenji Watanabe', 'kenji.watanabe@example.com', '090-1111-0005', 'Fukuoka',  'PREMIUM',  '2025-03-20', 3000),
    (6,  'Mika Ito',       'mika.ito@example.com',       '090-1111-0006', 'Tokyo',    'FREE',     '2025-04-01', 0),
    (7,  'Shota Kato',     'shota.kato@example.com',     '090-1111-0007', 'Kanagawa', 'STANDARD', '2025-04-18', 1500),
    (8,  'Aoi Kobayashi',  'aoi.kobayashi@example.com',  '090-1111-0008', 'Kyoto',    'PREMIUM',  '2025-05-02', 3000),
    (9,  'Ren Yoshida',    'ren.yoshida@example.com',    '090-1111-0009', 'Hyogo',    'FREE',     '2025-05-25', 0),
    (10, 'Sakura Yamamoto','sakura.yamamoto@example.com','090-1111-0010', 'Tokyo',    'STANDARD', '2025-06-10', 1500),
    (11, 'Daiki Nakamura', 'daiki.nakamura@example.com', '090-1111-0011', 'Saitama',  'PREMIUM',  '2025-06-28', 3000),
    (12, 'Rin Hayashi',    'rin.hayashi@example.com',    '090-1111-0012', 'Chiba',    'FREE',     '2025-07-07', 0),
    (13, 'Sota Shimizu',   'sota.shimizu@example.com',   '090-1111-0013', 'Osaka',    'STANDARD', '2025-07-19', 1500),
    (14, 'Mei Mori',       'mei.mori@example.com',       '090-1111-0014', 'Miyagi',   'PREMIUM',  '2025-08-04', 3000),
    (15, 'Haruto Ikeda',   'haruto.ikeda@example.com',   '090-1111-0015', 'Hiroshima','FREE',     '2025-08-22', 0),
    (16, 'Yua Hashimoto',  'yua.hashimoto@example.com',  '090-1111-0016', 'Tokyo',    'STANDARD', '2025-09-09', 1500),
    (17, 'Kaito Abe',      'kaito.abe@example.com',      '090-1111-0017', 'Niigata',  'PREMIUM',  '2025-09-30', 3000),
    (18, 'Hina Ishikawa',  'hina.ishikawa@example.com',  '090-1111-0018', 'Okinawa',  'FREE',     '2025-10-11', 0),
    (19, 'Yamato Ogawa',   'yamato.ogawa@example.com',   '090-1111-0019', 'Nagano',   'STANDARD', '2025-10-27', 1500),
    (20, 'Koharu Goto',    'koharu.goto@example.com',    '090-1111-0020', 'Shizuoka', 'PREMIUM',  '2025-11-15', 3000);

Let's Try It

Checking the Provided Tags

First, let's check the contents of the SNOWFLAKE.TAGS schema.

SHOW TAGS IN SCHEMA SNOWFLAKE.TAGS;

If 6 types of tags are displayed, there is no problem. You can see that owner is SNOWFLAKE and owner_role_type is APPLICATION, indicating a structure that cannot be owned or deleted by regular roles.

The comment on SENSITIVITY included a notice that "on Enterprise Edition or higher, automatic propagation can be enabled with ALTER TAG SNOWFLAKE.TAGS.SENSITIVITY SET PROPAGATE = ON_DEPENDENCY_AND_DATA_MOVEMENT ON_CONFLICT = ALLOWED_VALUES_SEQUENCE."
The initial allowed values are defined in the order RESTRICTED, CONFIDENTIAL, INTERNAL, PUBLIC (from highest to lowest sensitivity). When ON_CONFLICT = ALLOWED_VALUES_SEQUENCE is set, conflicts during propagation are resolved in this order, with values defined earlier taking precedence.

Applying Tags and Viewing Them

Apply tags to a schema, table, and columns respectively.

-- Apply to schema (inherited by objects below)
ALTER SCHEMA PROVIDED_TAGS_VERIFY_DB.VERIFY SET TAG SNOWFLAKE.TAGS.ENVIRONMENT = 'DEVELOPMENT';

-- Apply 3 tags at once to a table
ALTER TABLE CUSTOMERS SET TAG
  SNOWFLAKE.TAGS.CERTIFICATION_STATUS = 'IN REVIEW',
  SNOWFLAKE.TAGS.COST_CENTER = 'DATA-PLATFORM',
  SNOWFLAKE.TAGS.PROJECT = 'CUSTOMER-ANALYTICS';

-- Apply to columns
ALTER TABLE CUSTOMERS MODIFY COLUMN EMAIL SET TAG SNOWFLAKE.TAGS.SENSITIVITY = 'CONFIDENTIAL';
ALTER TABLE CUSTOMERS MODIFY COLUMN PHONE SET TAG SNOWFLAKE.TAGS.SENSITIVITY = 'CONFIDENTIAL';
ALTER TABLE CUSTOMERS MODIFY COLUMN CUSTOMER_NAME SET TAG SNOWFLAKE.TAGS.SENSITIVITY = 'INTERNAL';

There is no problem if SYSTEM$GET_TAG returns the set value.

SELECT SYSTEM$GET_TAG('SNOWFLAKE.TAGS.CERTIFICATION_STATUS', 'PROVIDED_TAGS_VERIFY_DB.VERIFY.CUSTOMERS', 'table');

With the TAG_REFERENCES table function, you can check how a tag was applied using the APPLY_METHOD column.

SELECT TAG_NAME, TAG_VALUE, LEVEL, OBJECT_NAME, APPLY_METHOD
FROM TABLE(PROVIDED_TAGS_VERIFY_DB.INFORMATION_SCHEMA.TAG_REFERENCES('PROVIDED_TAGS_VERIFY_DB.VERIFY.CUSTOMERS', 'TABLE'))
ORDER BY TAG_NAME;

The execution result is as follows. Directly applied tags show MANUAL, and ENVIRONMENT inherited from the schema shows INHERITED.

Use TAG_REFERENCES_ALL_COLUMNS for bulk checking at the column level. Whether targeting a table or view, specify TABLE as the second argument.

Setting a tag to a value not in the allowed values will result in an error.

ALTER TABLE CUSTOMERS SET TAG SNOWFLAKE.TAGS.ENVIRONMENT = 'INVALID_ENV';

Checking the Permission Model

Provided tag permissions are managed not by regular tag permissions, but by 3 types of application roles from the SNOWFLAKE application.

In the results of SHOW GRANTS OF APPLICATION ROLE, I confirmed in this account that OOB_TAG_ADMIN → OOB_TAG_APPLY → OOB_TAG_READ are nested in that order. Granting a higher-level role includes the permissions of lower-level roles.

SHOW GRANTS OF APPLICATION ROLE SNOWFLAKE.OOB_TAG_READ;
-- Shows granted_to APPLICATION_ROLE PUBLIC / OOB_TAG_APPLY etc.

Customizing Allowed Values

Let's try adding an allowed value to SENSITIVITY using a role with OOB_TAG_ADMIN granted.

USE ROLE TAG_ADMIN_ROLE;
USE SECONDARY ROLES NONE;

ALTER TAG SNOWFLAKE.TAGS.SENSITIVITY ADD ALLOWED_VALUES '__VERIFY_20260902__';

I confirmed with SHOW TAGS that it was added to the allowed values, and tag application with the added value also succeeded. After verification, I restored it with DROP ALLOWED_VALUES.

ALTER TAG SNOWFLAKE.TAGS.SENSITIVITY DROP ALLOWED_VALUES '__VERIFY_20260902__';

Similarly for ENVIRONMENT, I was able to add allowed values and restore them with DROP ALLOWED_VALUES.

On the other hand, changing the allowed values of CERTIFICATION_STATUS is rejected even with OOB_TAG_ADMIN.

ALTER TAG SNOWFLAKE.TAGS.CERTIFICATION_STATUS ADD ALLOWED_VALUES 'MY_STATUS';

The allowed values of provided tags are a shared setting across the entire account.

Checking Automatic Tag Propagation and SKIP_TAG_PROPAGATION

Let's try combining with automatic tag propagation. Automatic tag propagation and tag-based masking policies are Enterprise Edition or higher features (tag application and reference themselves are available in all editions). First, I'll confirm the basic behavior of propagation using a user-defined tag with propagation settings.

USE ROLE ACCOUNTADMIN;
USE SCHEMA PROVIDED_TAGS_VERIFY_DB.VERIFY;

CREATE OR REPLACE TAG DATA_ORIGIN
  PROPAGATE = ON_DEPENDENCY_AND_DATA_MOVEMENT
  COMMENT = 'Propagation verification tag (user-defined)';
ALTER TABLE CUSTOMERS SET TAG DATA_ORIGIN = 'CRM';

-- View (propagation via object dependency)
CREATE OR REPLACE VIEW CUSTOMERS_VIEW AS
SELECT CUSTOMER_ID, CUSTOMER_NAME, EMAIL, PLAN_TYPE FROM CUSTOMERS;

-- CTAS (propagation via data movement)
CREATE OR REPLACE TABLE CUSTOMERS_COPY AS SELECT * FROM CUSTOMERS;

Check with TAG_REFERENCES.

SELECT TAG_NAME, TAG_VALUE, APPLY_METHOD
FROM TABLE(PROVIDED_TAGS_VERIFY_DB.INFORMATION_SCHEMA.TAG_REFERENCES('PROVIDED_TAGS_VERIFY_DB.VERIFY.CUSTOMERS_VIEW', 'TABLE'))
WHERE TAG_NAME = 'DATA_ORIGIN';

There is no problem if DATA_ORIGIN appears with APPLY_METHOD = PROPAGATED on both the view and the CTAS destination.

Propagation via INSERT (data movement) is verified in the SKIP_TAG_PROPAGATION verification described later.

Next is the propagation setting for the provided tags themselves. I'll execute the recommended command as written in the SENSITIVITY comment.

ALTER TAG SNOWFLAKE.TAGS.SENSITIVITY SET PROPAGATE = ON_DEPENDENCY_AND_DATA_MOVEMENT ON_CONFLICT = ALLOWED_VALUES_SEQUENCE;
ALTER TABLE CUSTOMERS SET TAG SNOWFLAKE.TAGS.SENSITIVITY = 'RESTRICTED';

CREATE OR REPLACE TABLE CUSTOMERS_COPY3 AS SELECT * FROM CUSTOMERS;

-- Column-level propagation check
SELECT TAG_NAME, TAG_VALUE, LEVEL, COLUMN_NAME, APPLY_METHOD
FROM TABLE(PROVIDED_TAGS_VERIFY_DB.INFORMATION_SCHEMA.TAG_REFERENCES_ALL_COLUMNS('PROVIDED_TAGS_VERIFY_DB.VERIFY.CUSTOMERS_COPY3', 'TABLE'))
WHERE TAG_NAME = 'SENSITIVITY'
ORDER BY COLUMN_NAME;

The configuration succeeded. On the source side, RESTRICTED was directly applied to the table, and CONFIDENTIAL etc. were already directly applied to columns like EMAIL in the earlier steps. When checking the CTAS destination with TAG_REFERENCES_ALL_COLUMNS, the directly applied tags had propagated with PROPAGATED at both table and column levels.

The CTAS destination table itself has RESTRICTED from the source table attached with PROPAGATED. The RESTRICTED shown on columns without column tags is inheritance (INHERITED) from that table tag.

Finally, SKIP_TAG_PROPAGATION. As described in the official Doc, set an empty string on the downstream object where you want to stop propagation. At this point, CUSTOMERS_COPY / CUSTOMERS_VIEW already have DATA_ORIGIN propagated.

ALTER TABLE CUSTOMERS_COPY SET TAG SNOWFLAKE.TAGS.SKIP_TAG_PROPAGATION = '';
ALTER VIEW  CUSTOMERS_VIEW SET TAG SNOWFLAKE.TAGS.SKIP_TAG_PROPAGATION = '';

After setting, add a new propagation tag to the source and confirm it does not propagate to the SKIP-configured destinations.

-- Add a second propagation tag to the source (to distinguish it as a tag added after the SKIP setting)
CREATE OR REPLACE TAG DATA_QUALITY
  PROPAGATE = ON_DEPENDENCY_AND_DATA_MOVEMENT;
ALTER TABLE CUSTOMERS SET TAG DATA_QUALITY = 'VALIDATED';

-- Trigger data movement (INSERT) to the SKIP-configured table
INSERT INTO CUSTOMERS_COPY SELECT * FROM CUSTOMERS WHERE CUSTOMER_ID <= 2;

-- Check: expected behavior is that DATA_QUALITY is not attached
SELECT TAG_NAME, TAG_VALUE, APPLY_METHOD
FROM TABLE(PROVIDED_TAGS_VERIFY_DB.INFORMATION_SCHEMA.TAG_REFERENCES('PROVIDED_TAGS_VERIFY_DB.VERIFY.CUSTOMERS_COPY', 'TABLE'))
ORDER BY TAG_NAME;

SELECT TAG_NAME, TAG_VALUE, APPLY_METHOD
FROM TABLE(PROVIDED_TAGS_VERIFY_DB.INFORMATION_SCHEMA.TAG_REFERENCES('PROVIDED_TAGS_VERIFY_DB.VERIFY.CUSTOMERS_VIEW', 'TABLE'))
ORDER BY TAG_NAME;

The expectation was "already-propagated DATA_ORIGIN remains, and DATA_QUALITY added after the setting does not propagate." However, in the actual measurement, DATA_QUALITY appeared with PROPAGATED on both the view (dependency) and the table (data movement via INSERT).

After verification, restore the propagation settings of the provided tags. I confirmed that after execution, SHOW TAGS shows propagate returned to NONE and on_conflict returned to None.

ALTER TAG SNOWFLAKE.TAGS.SENSITIVITY UNSET PROPAGATE;

Could Not Reproduce SKIP_TAG_PROPAGATION's Propagation Stopping in the Verification Environment

According to the official Doc specification, "when set on an object, it pauses all subsequent tag propagation to that object (does not delete already-propagated tags; resume by UNSET)." However, as of September 2, 2026, in the verification environment, tag propagation occurred even after the setting, contrary to the official specification. The actual measured results are as follows.

• It was confirmed as per specification that tags already propagated before the setting (DATA_ORIGIN) were not deleted and remained.
• Propagation tags added to the source after the setting (DATA_QUALITY etc.) propagated via dependency (view).
• The same tag also propagated via INSERT (data movement).
• Propagation was not stopped for either user-defined tags or provided tags (SENSITIVITY).
• Even when using an object with SKIP_TAG_PROPAGATION set as the source for CTAS, tag propagation to downstream objects was not stopped (SQL below).

-- CTAS using SKIP-configured CUSTOMERS_COPY as source
CREATE OR REPLACE TABLE CUSTOMERS_CHAIN AS SELECT * FROM CUSTOMERS_COPY;

-- Check: propagation tags were also attached to CUSTOMERS_CHAIN with PROPAGATED
SELECT TAG_NAME, TAG_VALUE, APPLY_METHOD
FROM TABLE(PROVIDED_TAGS_VERIFY_DB.INFORMATION_SCHEMA.TAG_REFERENCES('PROVIDED_TAGS_VERIFY_DB.VERIFY.CUSTOMERS_CHAIN', 'TABLE'))
ORDER BY TAG_NAME;

The setting itself was confirmed on TAG_REFERENCES with SKIP_TAG_PROPAGATION showing as an empty string with APPLY_METHOD = MANUAL, and the behavior did not change even after waiting several minutes from the setting. It was confirmed that the SKIP_TAG_PROPAGATION tag itself does not propagate downstream.

These results are observations from a specific account, region, and Preview environment as of September 2, 2026, and do not indicate that all accounts will behave the same way. There is a possibility of differences due to Preview limitations or verification conditions, and the current results alone are not enough to conclude a specification defect. However, for the time being, it seems prudent to be careful about propagation exclusion designs that rely on SKIP_TAG_PROPAGATION until at least GA.

Use Case: Attaching a Masking Policy to SENSITIVITY

As a representative intended use case, let's try combining with tag-based masking policies (Enterprise Edition or higher).

https://docs.snowflake.com/en/user-guide/tag-based-masking-policies

Create a policy that evaluates the tag value with SYSTEM$GET_TAG_ON_CURRENT_COLUMN and attach it to the provided tag.

-- Masking policy that evaluates by tag value
CREATE OR REPLACE MASKING POLICY SENSITIVITY_STRING_MASK AS (VAL STRING) RETURNS STRING ->
  CASE
    WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('SNOWFLAKE.TAGS.SENSITIVITY') IN ('RESTRICTED', 'CONFIDENTIAL')
      THEN '*** MASKED ***'
    ELSE VAL
  END;

-- Attach to provided tag
ALTER TAG SNOWFLAKE.TAGS.SENSITIVITY SET MASKING POLICY SENSITIVITY_STRING_MASK;

The attachment succeeded. Let's reference the table containing columns with SENSITIVITY already applied.

SELECT CUSTOMER_NAME, EMAIL, PHONE FROM CUSTOMERS;

There is no problem if only the email and phone number with CONFIDENTIAL applied are masked, and the name with INTERNAL remains visible. The allowed values of the provided tags function as a common vocabulary for protection levels as-is.

Since this policy does not include role conditions, masking applies to all roles. In actual operation, combine with role conditions such as IS_ROLE_IN_SESSION so that only authorized roles can view the actual data. Note that only one masking policy per data type can be attached to a single tag. Since this policy is for STRING type, columns of NUMBER type such as MONTHLY_FEE are not covered. To protect NUMBER type as well, create a policy for NUMBER type and attach it to the same tag.

Closing Thoughts

By trying Snowflake-provided tags, I was able to confirm common vocabulary tag application, permission management via application roles, allowed value customization, and propagation settings. Since the initial design cost for tags is reduced, it is recommended to start by applying SENSITIVITY and ENVIRONMENT first. Please be careful about the behavior of SKIP_TAG_PROPAGATION during preview.

I believe the benefits of using Snowflake-provided tags are as follows.

• No tag design or creation required, immediately usable, and becomes a common vocabulary with the same names and allowed values across all accounts.
• Permission management is consolidated into 3 application roles (OOB_TAG_READ / OOB_TAG_APPLY / OOB_TAG_ADMIN), requiring no design.
• No concern about accidental deletion.

I hope this article is helpful in some way!