Snowflake tag-based policies now support aggregation, row access, projection, and join policies (Public Preview), so I tried all four types together

This is Kawabata.

In data governance operations, it is not uncommon for the task of assigning policies to each table to become burdensome as the number of tables to be protected increases. While tag-based application of masking policies has been available for some time, row access policies, aggregation policies, and others required direct assignment to target objects.

On July 21, 2026, tag-based application of Aggregation Policy, Row Access Policy, Projection Policy, and Join Policy entered public preview. By setting a policy on a tag, objects assigned that tag will automatically be protected.

In this article, we verify these four types of tag-based policies using a trial account (Enterprise Edition). We cover everything from setting policies on tags, assigning tags to objects, and confirming application with restricted roles, introducing the behavior of all four types as well as detailed specifications confirmed during verification (policy replacement with the FORCE option, the constraint of one policy per tag, etc.).

https://docs.snowflake.com/en/release-notes/2026/other/2026-07-21-tag-based-policies-preview

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

Note: This article reflects verification results as of August 4, 2026, during the public preview stage. As this is a preview, behavior may change in the future.

Note that during verification conducted on July 24, 2026, immediately after the preview release, there was an issue where tag-based control for types applied to tables/views (aggregation, row access, join) could not be confirmed in this verification environment. In the re-verification on August 4, 2026, the issue no longer reproduced in the same environment. The cause has not been identified, but since it occurred immediately after release, the timing of feature rollout to the environment may have been a factor.

Overview of Tag-Based Policies

Tag-based policies are a mechanism that combines the object tag feature with data protection policies. By setting a policy on a tag using ALTER TAG ... SET <POLICY_TYPE> POLICY, that policy is automatically applied to all objects assigned that tag.

With this release, the policy types that can be set on a tag are now the following five:

The levels at which tags can be assigned differ depending on the policy type.

When a tag is assigned to a database or schema, the tables and views underneath inherit the tag and are protected collectively.

Prerequisites

• Tag-based aggregation, row access, projection, and join policies are available on Enterprise Edition or higher
• Creating tags requires CREATE TAG privilege at the schema level
• Creating policies requires CREATE <POLICY_TYPE> privilege at the schema level
• Setting a policy on a tag requires APPLY <POLICY_TYPE> privilege at the account level
• Assigning tags to objects requires APPLY TAG privilege (or a tag-specific APPLY privilege)

Verification was conducted using Snowflake CLI 3.23.0 against a trial account (Enterprise Edition).

Preparation

We create a SALES schema for data and a GOVERNANCE schema for tag and policy management, kept separate.

USE ROLE SYSADMIN;

CREATE DATABASE IF NOT EXISTS TAG_POLICY_DEMO;
CREATE SCHEMA IF NOT EXISTS TAG_POLICY_DEMO.SALES;
CREATE SCHEMA IF NOT EXISTS TAG_POLICY_DEMO.GOVERNANCE;

USE SCHEMA TAG_POLICY_DEMO.SALES;

CREATE OR REPLACE TABLE customers (
  customer_id   INT,
  customer_name VARCHAR,
  email         VARCHAR,
  region        VARCHAR
);

INSERT INTO customers VALUES
  (1, 'Sato',      'sato@example.com',      'EAST'),
  (2, 'Suzuki',    'suzuki@example.com',    'EAST'),
  (3, 'Takahashi', 'takahashi@example.com', 'WEST'),
  (4, 'Tanaka',    'tanaka@example.com',    'WEST'),
  (5, 'Ito',       'ito@example.com',       'NORTH'),
  (6, 'Watanabe',  'watanabe@example.com',  'EAST');

CREATE OR REPLACE TABLE orders (
  order_id    INT,
  customer_id INT,
  order_date  DATE,
  amount      INT,
  region      VARCHAR
);

INSERT INTO orders VALUES
  (101, 1, '2026-07-01', 1000, 'EAST'),
  (102, 2, '2026-07-02', 1500, 'EAST'),
  (103, 6, '2026-07-03', 2000, 'EAST'),
  (104, 1, '2026-07-04', 1200, 'EAST'),
  (105, 2, '2026-07-05', 1800, 'EAST'),
  (106, 3, '2026-07-06', 3000, 'WEST'),
  (107, 4, '2026-07-07', 2500, 'WEST'),
  (108, 3, '2026-07-08', 1100, 'WEST'),
  (109, 4, '2026-07-09',  900, 'WEST'),
  (110, 5, '2026-07-10', 4000, 'NORTH'),
  (111, 5, '2026-07-11',  600, 'NORTH');

The count of orders by region is 5 for EAST, 4 for WEST, and 2 for NORTH. Since we set the minimum group size for the aggregation policy to 3, this design allows us to confirm the case where NORTH is merged into the remainder group.

We create a role TAG_POLICY_ANALYST as the role subject to policy restrictions. Within the policy definition, SYSADMIN is excluded from restrictions.

USE ROLE SECURITYADMIN;
CREATE ROLE IF NOT EXISTS TAG_POLICY_ANALYST;
GRANT USAGE ON DATABASE TAG_POLICY_DEMO TO ROLE TAG_POLICY_ANALYST;
GRANT USAGE ON ALL SCHEMAS IN DATABASE TAG_POLICY_DEMO TO ROLE TAG_POLICY_ANALYST;
GRANT SELECT ON ALL TABLES IN DATABASE TAG_POLICY_DEMO TO ROLE TAG_POLICY_ANALYST;
GRANT SELECT ON FUTURE TABLES IN DATABASE TAG_POLICY_DEMO TO ROLE TAG_POLICY_ANALYST;
GRANT USAGE ON WAREHOUSE compute_wh TO ROLE TAG_POLICY_ANALYST;
GRANT ROLE TAG_POLICY_ANALYST TO USER <verification username>;

Setting a policy on a tag requires APPLY <POLICY_TYPE> privilege at the account level, and assigning tags to objects requires APPLY TAG privilege. In this article, to simplify verification, we grant these to SYSADMIN.

USE ROLE SECURITYADMIN;
GRANT APPLY TAG ON ACCOUNT TO ROLE SYSADMIN;
GRANT APPLY AGGREGATION POLICY ON ACCOUNT TO ROLE SYSADMIN;
GRANT APPLY ROW ACCESS POLICY ON ACCOUNT TO ROLE SYSADMIN;
GRANT APPLY PROJECTION POLICY ON ACCOUNT TO ROLE SYSADMIN;
GRANT APPLY JOIN POLICY ON ACCOUNT TO ROLE SYSADMIN;

Note: The above grants are for simplifying verification. In production use, it is recommended to manage with dedicated roles with separation of duties, such as separating the tag administrator role from the policy administrator role.

Let's Try It

Tag-Based Aggregation Policy

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

First, we create a tag and an aggregation policy, then set the policy on the tag using ALTER TAG ... SET AGGREGATION POLICY. This policy places no restrictions on SYSADMIN, while requiring a minimum group size of 3 for all other roles.

USE ROLE SYSADMIN;
USE SCHEMA TAG_POLICY_DEMO.GOVERNANCE;

CREATE OR REPLACE TAG agg_protection;

CREATE OR REPLACE AGGREGATION POLICY min3_agg_policy
AS () RETURNS AGGREGATION_CONSTRAINT ->
  CASE
    WHEN CURRENT_ROLE() = 'SYSADMIN' THEN NO_AGGREGATION_CONSTRAINT()
    ELSE AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => 3)
  END;

ALTER TAG agg_protection SET AGGREGATION POLICY min3_agg_policy;

ALTER TABLE TAG_POLICY_DEMO.SALES.orders SET TAG agg_protection = 'protected';

When the TAG_POLICY_ANALYST role executes a query without aggregation, the aggregation policy is applied via the tag, resulting in an error.

USE ROLE TAG_POLICY_ANALYST;
SELECT * FROM TAG_POLICY_DEMO.SALES.orders;

An aggregate query that satisfies the minimum group size of 3 constraint succeeds. Since the count by region is 5 for EAST, 4 for WEST, and 2 for NORTH, NORTH, which is below the minimum group size of 3, should be merged into the remainder group and returned.

SELECT region, COUNT(*) AS cnt
FROM TAG_POLICY_DEMO.SALES.orders
GROUP BY region;

Confirming the Tag-Based Association

Tag-based policy associations can be confirmed using the POLICY_REFERENCES table function. The TAG_NAME column shows which tag the policy is being applied through.

SELECT policy_name, policy_kind, ref_entity_name, tag_name, policy_status
FROM TABLE(TAG_POLICY_DEMO.INFORMATION_SCHEMA.POLICY_REFERENCES(
  REF_ENTITY_DOMAIN => 'TABLE',
  REF_ENTITY_NAME => 'TAG_POLICY_DEMO.SALES.ORDERS'
));

Note that TAG_NAME and POLICY_STATUS in POLICY_REFERENCES can be used to confirm tag-based policy associations. However, the official definition of POLICY_STATUS = 'ACTIVE' is described with column-level associations in mind. Especially when introducing preview features, in addition to checking metadata, it is recommended to execute actual queries with the restricted role and confirm that control is working as expected.

Tag-Based Row Access Policy

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

Row access policies follow the same flow. We apply it tag-based to orders, which has a column (region) with the same name and type as the policy argument.

CREATE OR REPLACE TAG row_protection;

CREATE OR REPLACE ROW ACCESS POLICY region_rap
AS (region VARCHAR) RETURNS BOOLEAN ->
  CURRENT_ROLE() = 'SYSADMIN'
  OR region = 'EAST';

ALTER TAG row_protection SET ROW ACCESS POLICY region_rap;
ALTER TABLE TAG_POLICY_DEMO.SALES.orders SET TAG row_protection = 'protected';

When querying with the TAG_POLICY_ANALYST role, only EAST rows are returned.

USE ROLE TAG_POLICY_ANALYST;
SELECT region, COUNT(*) AS cnt
FROM TAG_POLICY_DEMO.SALES.orders
GROUP BY region;

For tables with different column names, you can specify a signature alias using the ON clause when setting the policy on the tag. Alias tuples are matched in the specified order, and the first tuple that can be resolved to the column name and data type of the table is used. The official documentation states that if multiple tuples can be resolved to the same table, an error occurs, and if no tuple can be resolved, the policy is not applied to that table. We prepare a table with a column named sales_area to test this.

CREATE OR REPLACE TABLE TAG_POLICY_DEMO.SALES.orders_by_area (
  order_id   INT,
  sales_area VARCHAR,
  amount     INT
);

INSERT INTO TAG_POLICY_DEMO.SALES.orders_by_area VALUES
  (201, 'EAST', 1000),
  (202, 'WEST', 2000),
  (203, 'EAST', 1500),
  (204, 'NORTH', 3000);

CREATE OR REPLACE TAG row_protection_alias;

ALTER TAG row_protection_alias SET ROW ACCESS POLICY region_rap
  ON (region VARCHAR), (sales_area VARCHAR);

ALTER TABLE TAG_POLICY_DEMO.SALES.orders_by_area
  SET TAG row_protection_alias = 'protected';

Since the sales_area column resolves to the second tuple, only the 2 EAST rows are returned for orders_by_area as well.

Tag-Based Join Policy

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

A join policy is a policy that prohibits standalone queries on a table and makes joins mandatory. When setting it on a tag, you can also restrict the allowed join keys with ALLOWED JOIN KEYS.

CREATE OR REPLACE TAG join_protection;

CREATE OR REPLACE JOIN POLICY customer_join_policy
AS () RETURNS JOIN_CONSTRAINT ->
  CASE
    WHEN CURRENT_ROLE() = 'SYSADMIN' THEN JOIN_CONSTRAINT(JOIN_REQUIRED => FALSE)
    ELSE JOIN_CONSTRAINT(JOIN_REQUIRED => TRUE)
  END;

ALTER TAG join_protection SET JOIN POLICY customer_join_policy
  ALLOWED JOIN KEYS (customer_id);

ALTER TABLE TAG_POLICY_DEMO.SALES.customers SET TAG join_protection = 'protected';

When the TAG_POLICY_ANALYST role executes a standalone SELECT, the join policy is applied via the tag, resulting in an error.

USE ROLE TAG_POLICY_ANALYST;
SELECT customer_id, region FROM TAG_POLICY_DEMO.SALES.customers;

A query that joins with orders using the allowed join key (customer_id) succeeds.

SELECT c.region, COUNT(*) AS cnt
FROM TAG_POLICY_DEMO.SALES.customers c
JOIN TAG_POLICY_DEMO.SALES.orders o
  ON c.customer_id = o.customer_id
GROUP BY c.region;

After confirming this, we remove the join policy tag from customers for subsequent verification (projection, masking) where standalone queries on customers will be used. If left on, subsequent standalone SELECT statements will result in a join-required error.

USE ROLE SYSADMIN;
ALTER TABLE TAG_POLICY_DEMO.SALES.customers
  UNSET TAG TAG_POLICY_DEMO.GOVERNANCE.join_protection;

Tag-Based Projection Policy

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

The projection policy is the only one of the four types that also allows tags to be assigned at the column level. This enables the control of "not showing the value itself, but allowing it to be used in filtering" to be applied column by column.

USE ROLE SYSADMIN;
USE SCHEMA TAG_POLICY_DEMO.GOVERNANCE;

CREATE OR REPLACE TAG pii_column;

CREATE OR REPLACE PROJECTION POLICY pii_proj_policy
AS () RETURNS PROJECTION_CONSTRAINT ->
  CASE
    WHEN CURRENT_ROLE() = 'SYSADMIN' THEN PROJECTION_CONSTRAINT(ALLOW => TRUE)
    ELSE PROJECTION_CONSTRAINT(ALLOW => FALSE)
  END;

ALTER TAG pii_column SET PROJECTION POLICY pii_proj_policy;

ALTER TABLE TAG_POLICY_DEMO.SALES.customers
  ALTER COLUMN email SET TAG pii_column = 'email';

When the TAG_POLICY_ANALYST role tries to project the email column, an error occurs immediately after the tag is assigned.

USE ROLE TAG_POLICY_ANALYST;
SELECT customer_name, email FROM TAG_POLICY_DEMO.SALES.customers;

Both a query that does not include the email column and a query that uses it only as a WHERE clause condition without projecting it succeed. The original behavior of projection policies — "not showing the value itself, but allowing it to be used in filtering" — works via tags as well.

-- Succeeds
SELECT customer_name, region FROM TAG_POLICY_DEMO.SALES.customers;

-- Using in WHERE clause is allowed as long as it is not projected
SELECT customer_name FROM TAG_POLICY_DEMO.SALES.customers
WHERE email LIKE '%example.com';

We also tested with a table-level tag, and it was similarly applied, making all columns of the table non-projectable.

Reference: Tag-Based Masking Policy (GA)

For reference, we also confirmed the tag-based masking policy, which has been available as GA since before, in the same environment.

USE ROLE SYSADMIN;
USE SCHEMA TAG_POLICY_DEMO.GOVERNANCE;

CREATE OR REPLACE TAG mask_test;

CREATE OR REPLACE MASKING POLICY mask_string AS (val STRING) RETURNS STRING ->
  CASE WHEN CURRENT_ROLE() = 'SYSADMIN' THEN val ELSE '***MASKED***' END;

ALTER TAG mask_test SET MASKING POLICY mask_string;
ALTER TABLE TAG_POLICY_DEMO.SALES.customers
  MODIFY COLUMN customer_name SET TAG mask_test = 'on';

Immediately after the tag was assigned, customer_name became ***MASKED***.

Schema-Level Tag Inheritance and Priority Over Direct Assignment

When a tag is assigned to a schema, the tables and views underneath inherit the tag and are protected collectively. Tables created after the tag is assigned should also have the policy automatically applied. We prepare a dedicated schema SALES_PROTECTED for verification (assigning directly to the SALES schema would apply the aggregation policy to customers and others, interfering with other verifications).

USE ROLE SYSADMIN;

CREATE SCHEMA IF NOT EXISTS TAG_POLICY_DEMO.SALES_PROTECTED;

CREATE OR REPLACE TABLE TAG_POLICY_DEMO.SALES_PROTECTED.orders_copy AS
SELECT * FROM TAG_POLICY_DEMO.SALES.orders;

-- Assign a tag to the schema → tables underneath inherit and are protected
ALTER SCHEMA TAG_POLICY_DEMO.SALES_PROTECTED
  SET TAG TAG_POLICY_DEMO.GOVERNANCE.agg_protection = 'protected';

-- Table newly created after the tag was assigned
CREATE OR REPLACE TABLE TAG_POLICY_DEMO.SALES_PROTECTED.new_table AS
SELECT 1 AS id UNION ALL SELECT 2;

New Table

This schema inheritance is especially important when combined with dbt. In the typical table materialization of dbt-snowflake, models are recreated with the equivalent of CREATE OR REPLACE on every dbt run, so tags and policies directly assigned to tables are not retained after recreation (the actual DDL issued depends on the dbt version, materialization, and project customization). On the other hand, with schema inheritance, protection should be automatically applied to recreated models as well. We simulate dbt's recreation with CREATE OR REPLACE to confirm this.

-- Simulating model recreation by dbt run
CREATE OR REPLACE TABLE TAG_POLICY_DEMO.SALES_PROTECTED.orders_copy AS
SELECT * FROM TAG_POLICY_DEMO.SALES.orders;

Also, when a directly assigned policy and a tag-based policy conflict, the directly assigned policy takes precedence (for aggregation policies, this applies only when the entity keys match; if they don't match, both may be applied). We confirm this by directly assigning a separate policy with a minimum group size of 5 to orders, which has the tag-based (min3) applied.

USE ROLE SYSADMIN;

-- Remove the row access policy tag temporarily since it would show only EAST, making the difference hard to see
ALTER TABLE TAG_POLICY_DEMO.SALES.orders UNSET TAG TAG_POLICY_DEMO.GOVERNANCE.row_protection;

CREATE OR REPLACE AGGREGATION POLICY TAG_POLICY_DEMO.GOVERNANCE.min5_agg_policy
AS () RETURNS AGGREGATION_CONSTRAINT ->
  CASE
    WHEN CURRENT_ROLE() = 'SYSADMIN' THEN NO_AGGREGATION_CONSTRAINT()
    ELSE AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => 5)
  END;

ALTER TABLE TAG_POLICY_DEMO.SALES.orders
  SET AGGREGATION POLICY TAG_POLICY_DEMO.GOVERNANCE.min5_agg_policy;

If the tag-based min3 were still in effect, EAST (5 rows) and WEST (4 rows) would be displayed, but the following confirms that the directly assigned min5 takes precedence.

Confirming Restrictions on Actual Hardware

We confirmed what errors occur for the restrictions described in the official documentation.

A tag with a policy set cannot be dropped.

DROP TAG TAG_POLICY_DEMO.GOVERNANCE.agg_protection;

A policy set on a tag also cannot be dropped.

DROP AGGREGATION POLICY TAG_POLICY_DEMO.GOVERNANCE.min3_agg_policy;

You cannot set multiple policies of the same type on a single tag. The error message suggests replacement using the FORCE option.

ALTER TAG agg_protection SET AGGREGATION POLICY min5_agg_policy;

When actually executed with FORCE, it succeeded, and checking with POLICY_REFERENCES confirmed that the policy associated with the tag had been replaced with MIN5_AGG_POLICY. The official documentation also describes using FORCE when you want to replace in a single statement, since splitting into two statements (UNSET→SET) can result in a period where the tag-based policy protection is absent. This is an option we would actively want to use when replacing policies.

ALTER TAG agg_protection SET AGGREGATION POLICY min5_agg_policy FORCE;

Also, coexistence of different types of policies on the same tag is not allowed. Attempting to set a row access policy on a tag that already has an aggregation policy set results in the following error. When you want to use multiple types together, a design that separates tags by type is necessary. Note that masking policies are an exception; as the official documentation states, "A tag can have only one masking policy per data type," meaning one per data type can be set on a single tag.

ALTER TAG agg_protection SET ROW ACCESS POLICY region_rap;

A schema containing a tag with a policy also cannot be dropped. The error message reveals that the reason for the deletion block is that the tag is assigned to (in use by) objects in other schemas.

DROP SCHEMA TAG_POLICY_DEMO.GOVERNANCE;

To drop it, you first need to disassociate the tag and policy using ALTER TAG ... UNSET <POLICY_TYPE> POLICY.

Restrictions and Notes

Key points are summarized from verification and the official documentation.

Closing

With the support for the four tag-based policy types, it becomes possible to consolidate data protection policy management from "per-object" to "per-tag." In our verification, we confirmed that for all four types — aggregation, row access, projection, and join — simply setting a policy on a tag and assigning the tag to an object applies protection. Combined with schema-level tag inheritance, it becomes possible to realize a governance operation where "attaching a tag to a schema automatically protects tables created later."

My impression is that what was previously only possible with masking policies can now be done with four policies as well, greatly expanding the scope of application.
I'm looking forward to GA.

I hope this article is helpful in some way!