Stale service credentials are the single biggest blind spot in most access reviews.
When a team relies on API keys, service accounts, or automated agents to talk to Snowflake, those identities often outlive the business need that created them. They are granted wide‑range privileges, copied across environments, and rarely rotated. During a quarterly review the auditor sees a list of user accounts, but the non‑human identities sit in a separate inventory, hidden behind scripts and CI pipelines. The result is a false sense of compliance: the review appears clean on paper while an over‑privileged service account silently executes costly queries or extracts sensitive data.
Two practical problems arise. First, the static nature of most service credentials means they cannot be revoked without breaking downstream jobs, so teams keep them alive indefinitely. Second, the lack of visibility into what those identities actually do makes it impossible to answer the core question of an access review – “who accessed what, when, and why?”. Without a single point that can observe and control traffic, any attempt to audit non‑human activity is piecemeal at best.
Why access reviews struggle with non‑human identities
Access reviews depend on three pillars: identity provenance, privilege justification, and activity evidence. Human users naturally satisfy the first two – they have an account in the identity provider, and their job role explains the access they need. Non‑human identities break this model. They are typically created directly in Snowflake or via cloud IAM, bypassing the organization’s identity provider. Their permissions are granted in bulk, often using role inheritance, and the justification lives in a ticket that disappears once the automation is deployed.
Because the credentials are stored in configuration files or secret managers, the gateway that actually talks to Snowflake never sees who is behind the request. The audit logs that Snowflake emits contain only the service account name, not the originating engineer or CI job. This makes it hard to tie a privileged operation back to a business purpose, a key requirement for a trustworthy access review.
Placing enforcement in the data path with hoop.dev
To close the gap, the enforcement point must sit where the request crosses the network – the data path. hoop.dev provides a Layer 7 gateway that proxies every Snowflake connection. The gateway is deployed inside the same network segment as Snowflake, and all clients – human, CI pipelines, or AI agents – must route their traffic through it.
Because hoop.dev is the only component that can see the full protocol exchange, it can apply the controls needed for a reliable access review. hoop.dev records each query, captures the full response, and stores a replayable session log. It masks sensitive columns in real time, ensuring that downstream tools never receive raw PII. When a request exceeds a predefined risk threshold, hoop.dev routes the operation to a human approver before it reaches Snowflake. All of these outcomes are possible only because hoop.dev sits in the data path.
From a setup perspective, non‑human identities are still issued by the organization’s identity provider – OIDC tokens, SAML assertions, or service‑account credentials. hoop.dev validates those tokens, extracts group membership, and then decides whether the request is allowed to proceed, needs approval, or should be blocked. The gateway never hands the underlying Snowflake credential to the caller, keeping the secret out of the hands of automated scripts.
How this changes the access review workflow
With hoop.dev in place, the access review process gains three concrete benefits. First, the audit evidence is complete: every Snowflake session is logged by the gateway, so reviewers can see exactly which non‑human identity executed which query and when. Second, privilege creep is mitigated because the gateway enforces just‑in‑time access – a service account can only run a query after an explicit approval, and the approval is recorded alongside the session. Third, data exposure risk is reduced through inline masking, which removes sensitive fields from logs and downstream pipelines without requiring changes to the application code.
These capabilities turn a vague list of service accounts into an actionable inventory. Reviewers can filter sessions by identity, by risk level, or by masked data exposure, and they can certify that every privileged operation had a documented business justification.
Getting started
Deploying hoop.dev for Snowflake follows the standard quick‑start flow. A Docker Compose file launches the gateway, configures OIDC authentication, and registers the Snowflake connection with the appropriate credentials. Detailed steps are available in the getting started guide. Once the gateway is running, point your Snowflake client (psql, SnowSQL, or any JDBC driver) at the hoop.dev endpoint and let the gateway handle authentication and policy enforcement.
For deeper insight into the feature set – session replay, inline masking, and approval workflows – explore the learn page. The documentation explains how to define risk policies, configure masking rules, and integrate with existing identity providers.
FAQ
- Do I need to change my existing Snowflake queries? No. hoop.dev acts as a transparent proxy, so existing client tools continue to work without modification.
- Will hoop.dev store my Snowflake passwords? The gateway holds the credential only for the duration of the connection; callers never see the password.
- Can I still use my CI pipelines? Yes. CI jobs authenticate to hoop.dev with OIDC tokens, and the gateway enforces the same policies as any other client.
By moving enforcement to the data path, organizations can finally treat non‑human identities with the same rigor as human users. hoop.dev makes access reviews for Snowflake both feasible and reliable.
Explore the open‑source repository on GitHub to contribute or customize the gateway for your environment.
