RBAC, Simplified: Grant Once, Inherit Everywhere, and Don’t Lose an Access Request Again

Role-based access control (RBAC) is how nearly every Snowflake customer enforces least privilege. The promise is elegant: model your organization as roles, grant each role only what it needs, and audit access cleanly. But anyone who has administered RBAC at scale knows the reality — hundreds of roles, thousands of objects, scripts to keep grants in sync, and access requests buried in ticket queues.

Today we're announcing three capabilities that simplify RBAC administration end to end: Inherited Grants (generally available), Container-level Manage Grants (generally available) and Request Access in Workspaces (public preview). Together, they turn role hierarchy into your single source of truth, give administrators one place to see and manage every privilege, and let users get the data access they need without filing a ticket.

The problem: RBAC administration doesn't scale with your AI data estate.

Three pain points dominate RBAC maturity conversations we have with customers:

Grant sprawl: When multiple roles need the same access, granting SELECT independently on each object can create substantial administrative overhead. A shared access role with one inherited grant can cover all current and future tables in a container, while the role hierarchy distributes that access to the appropriate analyst roles — reducing the need for per-object re-grants and synchronization scripts.

Lack of scoped delegation: Access management traditionally relies on account-level MANAGE GRANTS privileges. To allow database or schema administrators to manage access within their domains, security teams may be forced to overprovision them with account-wide grant authority. This increases security risks from excess privileges and turns central security teams into administrative bottlenecks for everyday grant operations.

Access friction: An analyst discovers exactly the table they need, then waits days for a ticket to reach a data engineer who can run the GRANT. Data teams become the bottleneck for the very self-service analytics they're meant to enable.

Inherited grants: grant once, inherit everywhere (GA)

Inherited grants reduce grant sprawl at the container level. Grant a privilege once on an account, database or schema, and Snowflake automatically applies it to every current and future object of the specified type within that container — without per-object re-grants or maintenance scripts. The privilege is then available to the grantee and roles that inherit from it through the role hierarchy.

Security teams keep full control: Define shared access once at the account, database or schema level, while retaining direct grants for narrower access requirements. Existing role hierarchies work with the new model: When an inherited grant is assigned to a role, roles that inherit from that role can also exercise the privilege. Existing direct or future grants are not automatically converted; migrate them explicitly when the container-wide access pattern is appropriate.

Container-level manage grants: scoped delegation (GA)

While Inherited Grants reduce grant sprawl, container-level manage grants make privilege administration delegable across your data estate.

With container-level MANAGE GRANTS, security teams can grant access administration authority, scoped specifically to a database or schema. Database and schema administrators can manage direct and inherited grants within their assigned containers without requiring overprovisioned, account-level grant privileges — upholding least privilege while removing security team bottlenecks.

Request access in Workspaces: self-service without losing control (public preview)

The third capability addresses the access friction problem — with governance controls built in. Before surfacing the request form, Snowflake automatically checks whether switching to an existing role resolves the error — so users only see the request flow when self-service isn't already possible. When a role-switch fix exists, users resolve their own access errors 72% of the time — no ticket, no wait. The feature is on by default for all customer accounts. In the 30 days from Sept. 10 to Oct. 10, 2026, when Workspaces users opened a suggested role-switch fix, about 73% completed the switch in-product based on internal usage.

In public preview, users working in Snowflake Workspaces can request access to data they discover but can't yet use, without leaving their flow:

1. A user hits an access error and clicks Resolve Access Error — if no role-switch fix exists, they're prompted to request access — without leaving Workspaces.
2. The admin is notified with full context — who's asking, from which workspace and why.
3. The approver grants access directly from the review interface.

Snowflake logs every request, approval and grant, so the same audit trail security teams rely on extends to self-service access. Data owners keep control of what's shared; users stop waiting on tickets; and the Slack message "Can someone grant me access to this?" finally has a system of record.

What these mean together

RBAC administration becomes a lifecycle instead of a set of workarounds: model your organization as a role hierarchy, grant privileges to parents and let inheritance do the propagation, delegate grant management without worrying about excess access, and let users self-serve the long tail of access through governed requests.

To get started:

• Review the Inherited Grants and try it out.
• Review the Container-level Manage Grants and try it out.
• Enable Request Access in your Workspaces and designate data owners for approval routing.

We built these capabilities because our customers told us RBAC's power was being taxed by its administration. That tax is now dramatically lower — and this is one step in a broader roadmap to make Snowflake the easiest data platform to govern. Stay tuned.