Cyera on Cyera: Examining Snowflake Access Before Letting Agents Run Free

On the surface, our read-only role for every Snowflake user looked harmless. Limited permissions, no obvious path to sensitive data. For years, it worked exactly as expected.

You probably have a role just like it. 

But as we prepared to give 1,500 employees access to agents through Claude Cowork, we took a closer look. Digging into the details uncovered some access worth tightening. In a handful of cases, the read-only role had picked up inherited access to sensitive data through nested and chained roles, the kind of hidden drift that rarely shows up in a standard access review. Those roles were not being misused. But we see a consistent pattern across the enterprises we work with: agents will use all the access they're granted to reach an objective.

At Cyera, we spend every day helping enterprises find where sensitive data lives and who can reach it so they can hand every employee AI without adding risk. Most companies rush AI out and worry about security later, but we know the very real dangers of that approach. So before letting agents touch a single internal workflow, we had to answer a harder question: who already had access to what? And we needed to answer that question quickly.

This is the first installment in Cyera on Cyera, a series about how we use our own platform as customer zero. Our hope is that these stories uncover use cases and insights that help you get more value out of the platform.

Everyone's a Data Analyst Now

One of the biggest promises of AI is that it lets anyone, not just people who write SQL in their sleep, analyze vast amounts of data. Data science, democratized. We bought into that and wanted to give employees the power to query Snowflake in plain language.

Putting Cowork in the hands of every employee meant more people tapping that data, and most of them doing it via autonomous agents. An analysis of 2.4 million workers by Cyera Research found that employees use only about 4% of the data they can access. That made over-permission remediation easy to deprioritize: in most cases, no one saw data they shouldn’t, and more urgent issues always won the day. But agents can move through vast tables in seconds, which means dormant access can suddenly become active and expose information it shouldn’t. 

And at any fast-growing company, permissions accumulate and broaden, platforms grow more complex, and without deliberate visibility, controls drift. So we ran our own Snowflake environment through Cyera to understand:

1. Who has access to sensitive data?
2. Do they actually need that access?
3. How do we right-size permissions?

The Read-Only Role That Reached Further Than it Looked

To start, we connected our Snowflake environment to Cyera via API. It took minutes to set up — point, scan, see — and within a few hours we had a complete picture of our sensitive data and who could reach it. 

One of the first things that caught our attention was a widely assigned read-only role that initially seemed innocuous. The role had no explicit grants to sensitive databases, and when used directly it was as harmless as it looked. But as any security and governance leader knows, it’s often not that straightforward. Roles expand as people move between teams and employees spin up new databases for research, analytics, and operations. In some cases, this read-only role had been granted access to another role that touched sensitive data. In others, the chain ran three layers deep before eventually reaching a database with sensitive data. The exposure was minimal when only humans were querying, but agents could make it a more substantial risk.

Cyera’s data security posture management (DSPM) showed us which users could reach sensitive data and where exposure risk was the highest so we could prioritize remediation. The platform identified the database owners and let us contact them directly from the platform to keep things simple. We removed access for those who didn’t require it and within days had meaningfully reduced exposure.

Dormant Accounts, Surfaced with Identity Context

Next we pulled in Okta to enrich the picture with identity data. Activity and department information helped us infer the business relevance behind each role grant. Instead of looking only at database roles, we could see the people attached to them.

That context quickly surfaced the next cleanup: hundreds of provisioned Snowflake accounts that had never been logged into, or hadn't been touched in six-plus months. Again, there were no signs of misuse. But dormant accounts represent operational complexity and avoidable risk, so there was no reason to keep them open.

We disabled them in a low-risk, reversible way. We didn’t delete any users, and all role grants stayed attached, so any account can be switched back on the moment a legitimate need comes up.

Privileged Access: Who Can Reach ACCOUNTADMIN?

With identity context in place, we turned to the most sensitive corner of Snowflake governance: privileged access.

ACCOUNTADMIN is Snowflake's most powerful role, granting full administrative control over the entire account. On the surface, only a few people had this access, and they all had clear justifications for it. But nested and inherited roles in Snowflake mean users can end up with ACCOUNTADMIN not through a direct grant but through a chain of intermediate roles. Without a tool that shows the full inheritance path, those indirect holders are effectively invisible to a standard access review.

Cyera's role-inheritance mapping traversed the full hierarchy to flag every user who could reach ACCOUNTADMIN, including those with inherited access. Combined with Okta and activity data from the platform, we could filter that list down to users with no recent activity to justify it. For each identity, Cyera's Identity Module showed the sensitive databases within reach of that access. That made the impact of abstract “roles” concrete and easy to prioritize.

Like with the dormant accounts, we revoked ACCOUNTADMIN for those users in a precise, reversible way. This was targeted least-privilege remediation, made possible by pulling sensitivity, identity, ownership, and access into one place.

The Bigger Lesson: Least Privilege Needs Data Context

Plenty of organizations try to manage access by reviewing roles and permissions alone. But as our Snowflake environment shows, roles without context on the data they can touch are often misleading. Each signal on its own would be easy for us to wave off. Cyera brought them all together to highlight issues that deserved our attention. 

This Snowflake review isn't a one-time exercise. We log into Cyera regularly to reassess permissions, especially as we add headcount quickly, and address anything new that surfaces.

In just a couple of weeks, we tuned our environment enough to roll out AI agents to 1,500 employees, many of them non-technical. Today those employees use Cowork agents to query Snowflake around 26 million times a day. Thanks to the proactive remediation work, that number doesn't scare us.