A CI pipeline spins up an autonomous coding agent that writes and runs SQL against Snowflake every commit. Because the agent uses a non-human identity, it receives a dedicated service credential instead of reusing a human account. When a mis-generated query runs, the damage spreads across the warehouse, and no one can point to who, or what, triggered it.
Non-human identity is the practice of giving machines their own, purpose-built credentials rather than reusing human or generic service accounts. It enables least-privilege access, per-job audit trails, and the ability to apply data-centric safeguards such as inline masking. Without a dedicated gateway, the agent still talks directly to Snowflake, carries the credential in-process, and leaves the request unobserved.
Why a gateway is required for non-human identity
Even when you provision a distinct service account for the AI agent, the connection terminates at Snowflake itself. The Snowflake endpoint sees only the credential; it cannot enforce dynamic policies, cannot mask result sets, and cannot record the exact command sequence for later replay. The setup phase, creating the OIDC client, assigning the service account to a group, and registering the Snowflake target, decides who may start a session, but it does not provide any runtime guardrails.
hoop.dev as the data-path enforcement point
hoop.dev sits between the AI agent and Snowflake, acting as a Layer 7 gateway that inspects every Snowflake wire-protocol message. The agent presents an OIDC token that proves its non-human identity; hoop.dev validates the token against your identity provider and maps the identity to a policy. The gateway holds the Snowflake credentials, so the agent never sees them. When a query arrives, hoop.dev applies just-in-time approval if the statement matches a risky pattern, masks any PCI/PHI/PII fields in the response, and records the full session for replay.
Because hoop.dev is the only place the traffic passes, it is the sole location where enforcement can happen. It blocks disallowed commands, injects approval steps, and redacts sensitive columns before the data reaches the client. All of these outcomes are performed by hoop.dev, not by Snowflake or by the AI agent.
Setting up non-human identity for Snowflake
The implementation begins with the usual identity setup: configure an OIDC provider (Okta, Azure AD, Google Workspace, etc.), create a group that represents AI coding agents, and issue short-lived tokens for that group. Next, register Snowflake as a connection in hoop.dev, supplying the Snowflake-specific credential that the gateway will use as its session principal. Finally, define policies that tie the AI group to just-in-time access, required approvals for DDL statements, and column-level masking rules for regulated data.
All of these steps are covered in the getting-started guide and the broader learn section. The repository at github.com/hoophq/hoop contains the Docker Compose and Kubernetes manifests you need to deploy the gateway in your network.
Enforcement outcomes you gain
- hoop.dev masks regulated fields in every Snowflake result set, ensuring that downstream tools never see raw PII.
- hoop.dev records each query, the identity that issued it, and the full response, providing a comprehensive audit trail for security reviews.
- hoop.dev can replay any session, allowing engineers to reconstruct the exact state that led to an incident.
- hoop.dev enforces just-in-time approvals, so a risky DDL operation must be manually approved before execution.
These capabilities shrink the blast radius of a rogue AI job, satisfy audit requirements, and give you confidence that every Snowflake interaction is governed by policy rather than by whatever credential a developer happened to embed in a script.
FAQ
How does hoop.dev authenticate an AI coding agent?
The agent obtains an OIDC token from the configured identity provider. hoop.dev validates the token, extracts the group membership that represents non-human identities, and then applies the corresponding Snowflake policy.
What happens when Snowflake credentials need rotation?
Because the gateway owns the Snowflake credential, you rotate it in the hoop.dev connection definition. The change propagates automatically to all sessions; the AI agents continue to use their OIDC tokens without any code change.
Can I limit masking to specific tables or columns?
Yes. hoop.dev’s masking configuration lets you declare which columns in which tables should be redacted for a given identity group. The gateway enforces those rules on every response that matches the pattern.
By placing the gateway in the data path, hoop.dev gives you the control plane you need to treat AI agents as first-class, non-human identities while keeping Snowflake secure and auditable.
