Before an AI agent gets a role in your warehouse, can you say who that role already reaches? Snowflake now can

When a team asks for a warehouse role for its new analytics agent, the request usually reads like this: “the same access as the analysts.” What does that mean in tables? Which of those tables hold salaries, health data or customer identifiers? And of all the people who hold that role today, how many have ever actually touched those tables?

In most companies nobody can answer the last question without a project. Snowflake’s release on October 20 makes it a report.

Two reports, two different facts

Snowflake made two Trust Center reports generally available, for Enterprise Edition and above:

• Sensitive Data Entitlement shows the access paths to tables containing sensitive data: the users, roles and privileges that grant access to them.
• Sensitive Data Access shows who actually queried those tables, within a lookback window you configure.

Both work on tables identified as holding sensitive data, so they are only as complete as the organization’s classification. Tables that were never classified do not appear, however sensitive they are.

Three questions about access, and which one each tool answers

Can access

• Users, roles, privileges
• Inherited grants

Entitlement report

Did access

• Who queried
• Within a lookback window

Access report

Should this request be allowed now

• Per query, per task
• Purpose and context

Runtime authorization, not a report

Why this matters more once agents arrive

Agents inherit roles at scale. A person with an over-broad role rarely explores tables they have no reason to open. An agent that answers open questions will query whatever its role allows when a question leads there. Excess privilege that was dormant for people becomes active for agents. The entitlement report shows that exposure before the agent exists.

“Did access” is the baseline for least privilege. The difference between who can reach a sensitive table and who has used it in the last 90 days is the most practical least-privilege finding a governance team can produce. For an agent, it gives the starting scope: grant what the human users of that workflow actually used, not everything their role technically allows.

The access report becomes an agent monitor. After go-live, the same report shows whether the agent’s identity is reading sensitive tables it was not expected to. That only works if each agent has its own identity in the warehouse. An agent that runs under a shared service user, or under the user’s own identity without a distinguishing marker, disappears into the human traffic.

What the reports do not do

They are evidence, not enforcement. A report that shows yesterday’s access does not stop today’s query; deciding whether a specific request should be allowed, for a specific purpose, is the job of row and column policies and of the agent platform’s authorization layer.

They also see one platform. If an agent combines Snowflake data with documents from SharePoint or records from a CRM, its real exposure is the union, and each source enforces its own rules. That is why patterns where the source system decides per user, or where the agent carries the user’s identity into each tool, matter as much as any single report.

A practical use this quarter

Make the two reports part of the request for any new agent role:

1. Run the entitlement report on the role the agent would receive. List the sensitive tables it reaches.
2. Run the access report for the people who do this work today. List the sensitive tables they actually used.
3. Grant the agent the second list, on its own identity, and record the decision.
4. Review the agent’s own access report monthly, and treat any new sensitive table as a change that needs approval.

None of this needs new technology beyond what Snowflake just shipped. It needs someone to decide that agent access reviews start from evidence, not from “the same access as the analysts.”