[New Feature] Trying Out Snowflake's "Inherited Grants" and "Container-level MANAGE GRANTS"

This is the English translation of the following article:
https://dev.classmethod.jp/articles/snowflake-try-ingerited-grants/

This is Sagara.

When managing permissions in Snowflake, you often run into cases like "I want to grant SELECT on both existing and future tables under a given database, all at once." Previously, this required combining GRANT ... ON ALL and GRANT ... ON FUTURE, but Snowflake now provides a feature called Inherited Grants that lets you combine these two into a single GRANT statement.

Additionally, by enabling the same Preview Feature as Inherited Grants, you can also use a feature called Container-level MANAGE GRANTS, which lets you delegate permission management itself to another role at the database or schema level.

(Interestingly, I couldn't find any mention of these features in the release notes, but it seems they were quietly released at some point.)

https://docs.snowflake.com/en/user-guide/inherited-grants-intro

https://docs.snowflake.com/en/user-guide/inherited-grants-using

https://docs.snowflake.com/en/user-guide/container-manage-grants-intro

I tried out how far these features actually go—the scope of application to existing and future objects, control per object type, auditing methods, and even delegating grant management via Container-level MANAGE GRANTS—and I've summarized my findings in this article.

:::message
As of July 17, 2026, both Inherited Grants and Container-level MANAGE GRANTS are Preview Features. Please note that the specifications may change before GA.
:::

Feature Overview

Inherited Grants is a feature that lets you define a single grant on a container-type object—such as ACCOUNT/DATABASE/SCHEMA—that automatically applies to both currently existing and future objects created underneath it. You execute this with the INHERITED keyword added to a normal GRANT statement.

GRANT INHERITED SELECT ON ALL TABLES
  IN DATABASE some_db
  TO ROLE some_reader_role;

Granting permissions this way applies SELECT automatically not only to existing tables in some_db, but also to tables created in the future. The biggest advantage is being able to replace the traditional combination of ON ALL + ON FUTURE with this single statement.

I'll also touch on Container-level MANAGE GRANTS, which becomes available under the same Preview Feature. Traditionally, MANAGE GRANTS was a global privilege that applied to the entire account, but with Container-level MANAGE GRANTS, you can delegate grant management itself to another role, scoped to a specific database or schema.

GRANT MANAGE GRANTS ON DATABASE some_db TO ROLE some_admin_role;

This allows some_admin_role to manage grants (including Inherited Grants) on objects under some_db without going through ACCOUNTADMIN.

Limitations

• As of July 17, 2026, both features are Preview Features. To use them, you need to enable Preview Features on your account and set ALTER ACCOUNT SET FEATURE_RBAC_INHERITED_GRANTS = 'ENABLED' (this single parameter enables both Inherited Grants and Container-level MANAGE GRANTS)
• Inherited Grants must be granted per object type. Granting on TABLES does not apply to VIEWS or DYNAMIC TABLES; you need a separate GRANT INHERITED for each target type
• OWNERSHIP is not covered by Inherited Grants. Also excluded are ORGANIZATION, APPLICATION, APPLICATION PACKAGE, SHARE, INTEGRATION, and USAGE on ROLE/USER
• If you want different access control for only some objects under a database or schema, Inherited Grants alone cannot fully handle that
• Container-level MANAGE GRANTS is a delegation feature scoped to a database or schema, and does not replace the global MANAGE GRANTS privilege that applies to the entire account

Preparation

For testing, I'll set up a role, database, schema, tables, and a warehouse. The objects prepared here will be used in common across both the "Inherited Grants" and "Container-level MANAGE GRANTS" verifications below. First, I'll change the account settings to enable Inherited Grants.

Enabling the Preview Feature

USE ROLE ACCOUNTADMIN;

ALTER ACCOUNT SET FEATURE_RBAC_INHERITED_GRANTS = 'ENABLED';

If this executes without error, you're good.

Note that enabling this parameter makes not only Inherited Grants available, but also Container-level MANAGE GRANTS, which lets you delegate permission management at the database or schema level.

https://docs.snowflake.com/en/user-guide/container-manage-grants-intro

Test Roles

All basic verification steps—creating test objects, granting/revoking Inherited Grants—are performed as ACCOUNTADMIN. IG_DEMO_ADMIN is used in the Container-level MANAGE GRANTS verification.

Test Database, Schema, and Tables

Test Warehouse

First, as ACCOUNTADMIN, I'll create the warehouse, database, schema, existing table, and view.

USE ROLE ACCOUNTADMIN;

-- Test warehouse
CREATE OR REPLACE WAREHOUSE IG_DEMO_WH
  WAREHOUSE_SIZE = XSMALL
  AUTO_SUSPEND = 60
  INITIALLY_SUSPENDED = TRUE;

-- Test database / schema
CREATE OR REPLACE DATABASE IG_DEMO_DB;
CREATE OR REPLACE SCHEMA IG_DEMO_DB.DOMAIN_A;

-- Table that existed before Inherited Grants was applied
CREATE OR REPLACE TABLE IG_DEMO_DB.DOMAIN_A.T_EXISTING (
  ID NUMBER,
  NAME STRING
);

INSERT INTO IG_DEMO_DB.DOMAIN_A.T_EXISTING VALUES
  (1, 'alice'),
  (2, 'bob');

-- View for checking the difference between TABLES and VIEWS
CREATE OR REPLACE VIEW IG_DEMO_DB.DOMAIN_A.V_EXISTING AS
SELECT * FROM IG_DEMO_DB.DOMAIN_A.T_EXISTING;

Next, I'll create the test roles used in both verifications and grant them warehouse usage.

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE ROLE IG_DEMO_READER;
CREATE OR REPLACE ROLE IG_DEMO_ADMIN;

-- Grant the test roles to the current user
SET MY_USER = CURRENT_USER();

GRANT ROLE IG_DEMO_READER TO USER IDENTIFIER($MY_USER);
GRANT ROLE IG_DEMO_ADMIN TO USER IDENTIFIER($MY_USER);

-- Usage on the test warehouse
GRANT USAGE ON WAREHOUSE IG_DEMO_WH TO ROLE IG_DEMO_READER;
GRANT USAGE ON WAREHOUSE IG_DEMO_WH TO ROLE IG_DEMO_ADMIN;

-- Let IG_DEMO_ADMIN resolve the DB itself
GRANT USAGE ON DATABASE IG_DEMO_DB TO ROLE IG_DEMO_ADMIN;

From here, I'll run two verifications: "Inherited Grants" and "Container-level MANAGE GRANTS." The basic verification steps are all executed as ACCOUNTADMIN, and delegating Container-level MANAGE GRANTS to IG_DEMO_ADMIN is done later in the verification.

Trying It Out (Inherited Grants)

1. Granting Inherited Grants

I'll grant IG_DEMO_READER the following three things:

• Regular USAGE on IG_DEMO_DB
• Inherited USAGE on all schemas in IG_DEMO_DB
• Inherited SELECT on all tables in IG_DEMO_DB

USE ROLE ACCOUNTADMIN;

-- The DB itself requires a normal USAGE grant
GRANT USAGE ON DATABASE IG_DEMO_DB TO ROLE IG_DEMO_READER;

-- USAGE on current and future schemas under the DB
GRANT INHERITED USAGE ON ALL SCHEMAS
  IN DATABASE IG_DEMO_DB
  TO ROLE IG_DEMO_READER;

-- SELECT on current and future tables under the DB
GRANT INHERITED SELECT ON ALL TABLES
  IN DATABASE IG_DEMO_DB
  TO ROLE IG_DEMO_READER;

If all three statements execute without error, you're good.

2. Confirming Access to an Existing Table

First, let's check whether we can access the T_EXISTING table, which existed before Inherited Grants was applied.

USE ROLE IG_DEMO_READER;
USE WAREHOUSE IG_DEMO_WH;

SELECT * FROM IG_DEMO_DB.DOMAIN_A.T_EXISTING;

If results are returned as shown below, you're good.

I confirmed that the SELECT permission also applies to a table that already existed at the time Inherited Grants was granted.

3. Confirming Access to a Future Table

Next, let's check whether we can access a table newly created after Inherited Grants was applied. First, create a new table as ACCOUNTADMIN.

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE TABLE IG_DEMO_DB.DOMAIN_A.T_FUTURE (
  ID NUMBER,
  VALUE STRING
);

INSERT INTO IG_DEMO_DB.DOMAIN_A.T_FUTURE VALUES
  (100, 'created after inherited grant');

Switch to IG_DEMO_READER to query it.

USE ROLE IG_DEMO_READER;
USE WAREHOUSE IG_DEMO_WH;

SELECT * FROM IG_DEMO_DB.DOMAIN_A.T_FUTURE;

If results are returned as shown below, you're good.

I confirmed that a table created after Inherited Grants was granted can be accessed without any additional GRANT.

4. Confirming Access to a Table in a Future Schema

Let's extend the scope further and check whether we can access a table under a newly created schema. Create a new schema and table as ACCOUNTADMIN.

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE SCHEMA IG_DEMO_DB.DOMAIN_B;

CREATE OR REPLACE TABLE IG_DEMO_DB.DOMAIN_B.T_FUTURE_SCHEMA (
  ID NUMBER,
  VALUE STRING
);

INSERT INTO IG_DEMO_DB.DOMAIN_B.T_FUTURE_SCHEMA VALUES
  (200, 'new schema and new table');

Query it as IG_DEMO_READER.

USE ROLE IG_DEMO_READER;
USE WAREHOUSE IG_DEMO_WH;

SELECT * FROM IG_DEMO_DB.DOMAIN_B.T_FUTURE_SCHEMA;

If results are returned as shown below, you're good.

The key point here is that we had previously granted these two:

GRANT INHERITED USAGE ON ALL SCHEMAS IN DATABASE IG_DEMO_DB TO ROLE IG_DEMO_READER;
GRANT INHERITED SELECT ON ALL TABLES IN DATABASE IG_DEMO_DB TO ROLE IG_DEMO_READER;

The former covers USAGE on future schemas, and the latter covers SELECT on future tables, so even a table under a newly created schema can be queried without any additional GRANT.

5. Confirming Object-Type-Level Control (TABLES Alone Does Not Cover VIEWS)

The Inherited Grants applied so far are only for ALL TABLES, so SELECT on views has not yet been granted. Let's check whether we can access a view.

USE ROLE IG_DEMO_READER;
USE WAREHOUSE IG_DEMO_WH;

SELECT * FROM IG_DEMO_DB.DOMAIN_A.V_EXISTING;

If this results in an error as shown below, that's expected.

If you want to allow access to views as well, you need to explicitly grant Inherited Grants on VIEWS too.

USE ROLE ACCOUNTADMIN;

GRANT INHERITED SELECT ON ALL VIEWS
  IN DATABASE IG_DEMO_DB
  TO ROLE IG_DEMO_READER;

Checking again, if results are returned as shown below, you're good.

USE ROLE IG_DEMO_READER;
USE WAREHOUSE IG_DEMO_WH;

SELECT * FROM IG_DEMO_DB.DOMAIN_A.V_EXISTING;

Since Inherited Grants apply per object type, if you want to cover tables, views, dynamic tables, Iceberg tables, and so on all at once, you need to issue a separate GRANT INHERITED for each object type.

6. Confirming How to Audit Inherited Grants

Inherited Grants can be checked using the following three commands and one view.

Checking Inherited Grants defined on a database/schema

USE ROLE ACCOUNTADMIN;

SHOW INHERITED GRANTS IN DATABASE IG_DEMO_DB;

Checking grants applied to a specific object

SHOW GRANTS ON TABLE IG_DEMO_DB.DOMAIN_A.T_EXISTING;

Checking grants given to a role

SHOW GRANTS TO ROLE IG_DEMO_READER;

7. Confirming a Caveat with Information Schema Visibility

Information Schema views may not take Inherited Grants into account when determining visibility. As a result, objects accessible only via Inherited Grants may not appear in the Information Schema even though they can actually be queried.

USE ROLE IG_DEMO_READER;

SELECT
  TABLE_SCHEMA,
  TABLE_NAME
FROM IG_DEMO_DB.INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME IN ('T_EXISTING', 'T_FUTURE', 'T_FUTURE_SCHEMA')
ORDER BY TABLE_SCHEMA, TABLE_NAME;

I confirmed that even though SELECT * FROM IG_DEMO_DB.DOMAIN_A.T_EXISTING itself succeeds, the target table does not appear in the Information Schema, as shown below. This could be a pitfall in operational use, so be careful.

8. Confirming Access Is Lost After Revoking

Finally, let's revoke the Inherited Grants on TABLES and confirm that access is lost.

USE ROLE ACCOUNTADMIN;

REVOKE INHERITED SELECT ON ALL TABLES
  IN DATABASE IG_DEMO_DB
  FROM ROLE IG_DEMO_READER;

Query the table again.

USE ROLE IG_DEMO_READER;
USE WAREHOUSE IG_DEMO_WH;

SELECT * FROM IG_DEMO_DB.DOMAIN_A.T_EXISTING;

If this results in an error as shown below, you're good.

I confirmed that revoking Inherited Grants removes access to both existing and future tables.

9. Comparison with the Traditional ON ALL + ON FUTURE Approach

Previously, you had to issue separate GRANTs for existing and future objects.

-- Traditional approach
GRANT SELECT ON ALL TABLES IN DATABASE IG_DEMO_DB TO ROLE IG_DEMO_READER;
GRANT SELECT ON FUTURE TABLES IN DATABASE IG_DEMO_DB TO ROLE IG_DEMO_READER;

-- Inherited Grants approach
GRANT INHERITED SELECT ON ALL TABLES
  IN DATABASE IG_DEMO_DB
  TO ROLE IG_DEMO_READER;

However, this substitution is only valid when all of the following are true:

• The permission granted to existing and future objects is identical
• The grantee role is identical
• There are no objects you want to exclude

If you want to exclude only certain objects, you'll need to consider combining Inherited Grants with the traditional, more granular GRANT approach instead.

Trying It Out (Container-level MANAGE GRANTS)

All the verification so far has involved granting and revoking Inherited Grants as ACCOUNTADMIN, but in real-world operations, you'd likely want to delegate permission management at the database level to a specific role rather than using ACCOUNTADMIN every time. The Container-level MANAGE GRANTS feature we enabled in the preparation step makes this delegation possible.

1. Granting Container-level MANAGE GRANTS

Let's grant MANAGE GRANTS on IG_DEMO_DB to the IG_DEMO_ADMIN role we created earlier.

USE ROLE ACCOUNTADMIN;

-- Delegate MANAGE GRANTS on IG_DEMO_DB to IG_DEMO_ADMIN (Container-level MANAGE GRANTS)
GRANT MANAGE GRANTS ON DATABASE IG_DEMO_DB TO ROLE IG_DEMO_ADMIN;

If this executes without error, you're good.

2. Confirming the Delegated MANAGE GRANTS

SHOW GRANTS ON DATABASE IG_DEMO_DB;

If there's a row where the PRIVILEGE column is MANAGE GRANTS and the GRANTEE_NAME column is IG_DEMO_ADMIN, you're good.

3. Confirming IG_DEMO_ADMIN Can Grant Inherited Grants

Let's check whether IG_DEMO_ADMIN can grant Inherited Grants without going through ACCOUNTADMIN. Note that since Inherited Grants on TABLES were already revoked in step 8 of the "Trying It Out (Inherited Grants)" section, here we'll confirm by re-granting it as IG_DEMO_ADMIN.

USE ROLE IG_DEMO_ADMIN;

GRANT INHERITED SELECT ON ALL TABLES
  IN DATABASE IG_DEMO_DB
  TO ROLE IG_DEMO_READER;

If this executes without error, you're good. I confirmed that IG_DEMO_ADMIN, having been delegated MANAGE GRANTS, can manage Inherited Grants on its own, without using ACCOUNTADMIN.

4. Confirming a Role Without MANAGE GRANTS Cannot Do This

For comparison, let's try the same operation with IG_DEMO_READER, which has not been granted MANAGE GRANTS.

USE ROLE IG_DEMO_READER;

GRANT INHERITED SELECT ON ALL TABLES
  IN DATABASE IG_DEMO_DB
  TO ROLE IG_DEMO_READER;

If this results in an insufficient-privileges error as shown below, you're good.

5. Revoking the Delegation and Confirming the Result

Finally, let's revoke the MANAGE GRANTS delegation to IG_DEMO_ADMIN and confirm it can no longer manage Inherited Grants.

USE ROLE ACCOUNTADMIN;

REVOKE MANAGE GRANTS ON DATABASE IG_DEMO_DB FROM ROLE IG_DEMO_ADMIN;

Try granting Inherited Grants as IG_DEMO_ADMIN again.

USE ROLE IG_DEMO_ADMIN;

GRANT INHERITED SELECT ON ALL VIEWS
  IN DATABASE IG_DEMO_DB
  TO ROLE IG_DEMO_READER;

If this results in the same kind of insufficient-privileges error as before, you're good. I confirmed that once the MANAGE GRANTS delegation is revoked, no role other than ACCOUNTADMIN can manage Inherited Grants.

Cleanup

After verification, let's clean up all the objects used in both the Inherited Grants and Container-level MANAGE GRANTS verifications with the following SQL.

USE ROLE ACCOUNTADMIN;

DROP DATABASE IF EXISTS IG_DEMO_DB;
DROP WAREHOUSE IF EXISTS IG_DEMO_WH;

DROP ROLE IF EXISTS IG_DEMO_READER;
DROP ROLE IF EXISTS IG_DEMO_ADMIN;

Conclusion

By trying out Snowflake's Inherited Grants, I confirmed that you can manage permissions on both existing and future objects with a single GRANT INHERITED statement. In particular, for cases where you want to grant consistent read permissions at the database or schema level, this feels much simpler to manage than the traditional combination of ON ALL and ON FUTURE.

Furthermore, by combining this with Container-level MANAGE GRANTS, I confirmed that you can delegate management of Inherited Grants at the database level without relying on ACCOUNTADMIN. The delegated role could grant and revoke Inherited Grants without issue, while a role without MANAGE GRANTS was correctly denied—giving the impression that the permission boundaries are designed clearly and sensibly.

As of July 17, 2026, both Inherited Grants and Container-level MANAGE GRANTS are Preview Features, so their specifications may change on the way to GA. If you're considering improving your permission management operations, I'd recommend trying these out in a test environment first.