Three ways data warehouse access goes wrong, and how to fix them
Snowflake role-based access is a clean permission system. It stands out in the modern data stack, but people configure it wrong often. We review data platforms all the time. In every review, we find the exact same three problems. None of these mistakes are weird or strange. They are all quiet. You will not see bright red errors when they happen.
If you let your data warehouse grow for three years without checking it, you likely have at least one of these problems. This matters a lot for your business. When your data platform is a mess, your reps cannot get the clean data they need. They need this data to quote accurate prices to clients. If data access breaks, your renewals slow down and your pipeline stalls. Let us look at the three common mistakes we always see.
Anti-pattern one: functional roles bleeding into account roles
The intended Snowflake pattern uses two distinct tiers. First, you have functional roles that describe what a user does every day. These include an analyst for marketing, a data engineer, or a viewer of dashboards. You give these roles direct grants on your specific objects. Second, you have account roles that describe what a user is in the system. These include a system administrator, a security administrator, or a user administrator. You only give these account roles the power to manage other roles.
The mistake happens when someone takes a fast shortcut. Someone decides it is easier to attach an object grant directly to the system administrator role just for this one warehouse because they are in a rush. Six months pass by. Half a dozen functional roles now inherit from that system administrator role for unrelated reasons. Now, a junior analyst on your marketing team can query a highly sensitive payroll table through a hidden transitive grant that nobody ever traced.
You can find this mistake quickly. Walk the role graph downward from any privileged account role and look for anything that is not a role-management grant. If you find one, you should migrate it to a functional role. Snowflake provides a command to show grants on the system administrator role. This is the single most useful command we run on day one. If the output has more than three lines that are not role-management grants, you have this problem. Fixing this stops a mess that otherwise slows down your reps.
Anti-pattern two: default warehouse with too much grant
Every Snowflake user has a default warehouse. Your session attaches to this specific warehouse if you do not specify one. The most convenient setup is a single shared compute warehouse. Everyone uses this shared space as their default.
The mistake happens when this shared default warehouse gets far too much access. Someone grants usage to the public group or to a role that the public group inherits from. Now any service account, third-party application, or one-off integration credential can attach to it and run massive queries. They use your computer credits and run up your monthly bill with no clear attribution for who spent the money. When this happens, your technology budget runs out quickly, preventing you from buying the software your reps need.
You can find this issue easily. Check the grants given to the public role. If a warehouse appears on that list, you have this mistake. The fix is straightforward and fast: revoke the access from the public group and grant access explicitly to the functional roles that need it. You should also set timeout limits and resource monitors on the warehouse. This ensures that runaway queries cap themselves before they drain your funds completely.
Anti-pattern three: the BI tool that reads more than you think
Business intelligence tools connect to Snowflake using a simple service account. The convenient pattern is to give that service account a role with broad usage across multiple databases. This lets your analysts join tables anywhere they need to.
The mistake happens when that service account role can read tables it should never touch. These include billing tables, audit logs, or human resources data. The dashboard itself never queries these tables, but the service account could query them. If the tool credentials leak, you have a massive problem on your hands. A malicious internal user could pivot through the query history of the tool to reach those sensitive tables easily. This puts your entire business at extreme risk. If client data leaks, your sales teams lose all their trust and your pipeline dries up fast.
You can find this issue by checking the grants to your service account role. Compare those grants against the actual datasets the tool exposes to end users. Look for any database that the tool can access but never surfaces in a workbook. If you find one, that is a prime candidate to revoke immediately.
The pattern across all three
Every one of these mistakes starts as a harmless convenience to unblock a specific request quickly. None of these issues are flagged by the Snowflake interface. None of them break anything that someone would notice right away. Your systems keep running, and your sales teams keep quoting their prospects.
But underneath the surface, you have a messy and insecure data platform. The fix in all three cases is exactly the same. You need a quarterly walk of the role graph, starting from the system administrator role and moving downward. You need a written record of why every grant exists. If nobody can name the specific request that justified a grant, you must revoke it. Clean data access means your sales teams get accurate reports when they need them.
If you have not run a Snowflake role-based access review in twelve months, you should do it now. This is exactly what Lattice covers. Lattice is our two-week data-pipeline audit that covers all three mistakes above. It also includes lineage tracing for sensitive joins and gives you a priority-ranked hardening list.
Next step
If this sounds like your team, we can look at it together. A free pipeline review takes thirty minutes and ends with a written list of what to fix first. Book a review.