Agent impersonation lets a compromised identity act as any user, breaking the reliability of access reviews.
Why access reviews fail when agents impersonate users
Most Snowflake deployments rely on a handful of long‑lived credentials that are shared across teams. Engineers store a service account password in a vault, copy it into CI pipelines, and grant it full read/write rights. The same credential is often used for ad‑hoc analytics, data science notebooks, and scheduled ETL jobs. Because the Snowflake instance sees only the service account, auditors cannot tell which human actually ran a query. When an attacker steals the credential, they can impersonate any employee, and the resulting activity blends seamlessly into legitimate usage. The access review process then becomes a guessing game: "Did Alice really run that SELECT?"
What a proper control fixes – and what it still leaves open
Introducing per‑user authentication and least‑privilege IAM roles solves the first problem: the system now knows who is trying to connect. However, the request still travels directly from the client to Snowflake. The gateway that could inspect the query, enforce masking of sensitive columns, or require a manager’s approval never sees the traffic. Without a data‑path enforcement point, the organization still lacks:
- Real‑time audit of each statement, tied to the actual user identity.
- Inline data masking that prevents accidental exposure of PII during exploratory queries.
- Just‑in‑time approval workflows for high‑risk operations such as bulk data exports.
In other words, the setup alone does not guarantee that access reviews can rely on trustworthy evidence.
hoop.dev as the mandatory data‑path gateway
hoop.dev is designed to sit between identities and Snowflake. It proxies every connection, inspects the Snowflake wire protocol, and applies policy before the query reaches the database. Because hoop.dev is the only component that can see both the authenticated user (from OIDC or SAML tokens) and the actual Snowflake request, it becomes the sole source of enforcement.
When a user attempts to run a query, hoop.dev first validates the token, checks group membership, and confirms that the user’s role allows the requested operation. If the query matches a high‑risk pattern, such as SELECT * FROM a table that contains regulated data, hoop.dev can either block the statement or route it for manual approval. For queries that return sensitive fields, hoop.dev can mask those columns in real time, ensuring that downstream logs never contain raw PII.
Every session is recorded by hoop.dev, and the recording is stored independently of Snowflake. The audit log includes the user identity, timestamp, full statement, and the outcome (allowed, blocked, or approved). This log is what access reviewers examine to answer the question, "Did Bob really export customer data on March 12?" Because the evidence originates from hoop.dev, the answer is provable.
How the three attribution layers work together
Setup. Identity providers such as Okta, Azure AD, or Google Workspace issue OIDC tokens. Those tokens identify the caller and carry group claims that define baseline permissions. This layer decides who can start a session, but it does not enforce what the session can do.