Design warehouse roles around jobs, not people: one role per function such as reader, transformer or loader, granted to individuals through a small number of group roles. Keep admin roles for administration only, and never run scheduled pipelines under a human's account or an all powerful role.
Learn the platform's model first
Snowflake blends discretionary and role based access control. Every object has one owner role that holds OWNERSHIP and can grant access to others. Privileges go to roles, and roles go to users or other roles. Roles can form hierarchies, so a higher role inherits what the roles beneath it can do.
The system roles matter. ACCOUNTADMIN sits at the top and encompasses SYSADMIN and SECURITYADMIN. USERADMIN manages users and roles, SYSADMIN creates warehouses and databases, and SECURITYADMIN manages grants. PUBLIC is given to every user and role automatically. Snowflake recommends attaching custom role hierarchies to SYSADMIN so administrators can manage all objects.
A workable layout
Start with three tiers.
- Access roles that hold privileges on data: for example raw reader, curated reader, curated writer.
- Functional roles that combine access roles for a job: analyst, analytics engineer, loader.
- Group roles or assignments that put people into functional roles.
People get functional roles. Functional roles get access roles. Access roles get privileges. When someone changes team, you change one assignment and the privilege set follows.
Rules that prevent most trouble
- Daily work never uses the top admin role. Use it for account level tasks and keep the number of people who can assume it small.
- Pipelines run under a service identity with its own functional role, never a person's login.
- Whoever creates an object owns it, so create objects through a transformer role and not a personal one. Otherwise ownership ends up with a user who later leaves.
- Anything granted to PUBLIC is visible to everyone, so audit it.
- Prefer granting on schemas with future grants over granting table by table, then review those grants like code.
Review cadence
Roles drift. Each quarter, list who holds each functional role, who owns critical objects, and which service identities exist. Remove what no one can justify. Save the output as evidence for audits.
A useful test: pick one analyst and write down, in plain words, the data they can read, write and administer. If that takes longer than a minute, the role design has too many paths.
Raw versus curated
A common pattern is to restrict raw landing data to loaders and transformers, since it often contains unmasked personal data, and give analysts access only to curated layers where masking and row policies have been applied. That makes the safe path the easy path.
How Safeguard helps
Safeguard handles the software side: dependency scanning of the repositories that define your transformations, policies and gates on pull requests, and compliance and evidence automation for access review records. Try the free scan at https://gold.safeguard.sh/scan.
Quick check
Should scheduled pipelines run as a named employee?
No. Use a service identity with a purpose built role, so a departure or password reset does not break or over-privilege the pipeline.
Why avoid creating objects with a personal role?
The creating role becomes the owner by default, and ownership then follows a person who may leave. Create through a shared transformer role.
Sources
Last reviewed: 19 October 2026.
