Why non-human identity matters for Snowflake MCP servers
Many teams assume that a machine‑to‑machine integration can be secured simply by embedding a static Snowflake user name and password, or a long‑lived key, inside the MCP server code, but they overlook the need for a non-human identity. The belief is that once the secret is stored, the service can query Snowflake whenever it needs data, and that this is sufficient because the service never interacts with a human.
That assumption is dangerous. Static credentials are copied across repositories, leaked in logs, and often shared among multiple services. When a breach occurs, every integration that relies on the same secret becomes an easy foothold. Auditors also struggle to prove who actually accessed sensitive tables because the same credential is used by dozens of automated jobs.
What you really need is a non-human identity that is unique to each MCP server instance, can be revoked instantly, and is tied to a policy that records every query, masks protected fields, and requires approval for risky operations. The challenge is that Snowflake itself does not provide a built‑in gateway to enforce those controls; the service simply trusts the credential presented to it.
From static secrets to a controlled access path
In the current, unprotected state, an MCP server connects directly to Snowflake using a credential stored in its configuration. The request travels straight to Snowflake, bypassing any point where an organization could inspect the query, enforce masking, or require a human to approve a potentially destructive command. The setup satisfies the need to get data, but it leaves three critical gaps:
- There is no audit trail that ties each query to the specific server instance that issued it.
- Sensitive columns such as PCI or PHI can be returned in clear text to the server, where they may be logged or cached.
- If a server is compromised, the attacker inherits the same long‑lived Snowflake credential, giving unfettered access.
Adding a non-human identity alone does not close those gaps. Even if you issue a separate service account per server, the connection still goes straight to Snowflake, and Snowflake will not mask data or record the session beyond its own logs, which are not tied to your internal policy engine.
How hoop.dev creates the enforcement point
hoop.dev acts as a Layer 7 gateway that sits between the MCP server and Snowflake. The gateway runs a network‑resident agent close to Snowflake and proxies every Snowflake wire‑protocol request. Because all traffic passes through this data path, hoop.dev can apply the missing controls:
- Just‑in‑time identity. Each MCP server authenticates to hoop.dev using an OIDC token. hoop.dev validates the token, extracts the service’s unique non-human identity, and then establishes a Snowflake session on its own behalf. The server never sees the Snowflake credential.
- Query‑level audit. hoop.dev records every SQL statement, the identity that issued it, and the response metadata. The audit log lives outside the Snowflake process, giving you a tamper‑evident trail that can be exported to your SIEM.
- Inline data masking. Before the result set reaches the MCP server, hoop.dev runs a masking plugin that redacts PCI, PHI, or any custom PII fields. The original values never leave the gateway.
- Approval workflows. If a query matches a risky pattern, such as a DROP, ALTER, or a SELECT that touches a high‑value table, hoop.dev can pause the request and route it to a human approver. The operation only proceeds after explicit consent.
- Session recording and replay. For forensic investigations, hoop.dev can replay a recorded Snowflake session, showing exactly what was asked and what was returned.
All of these outcomes are possible only because hoop.dev sits in the data path. The identity verification step (the OIDC token) decides who may start a session, but without the gateway there would be no place to enforce masking, approval, or recording.
Architectural steps for a fast first connection
1. Deploy the gateway. Use the official Docker Compose quick‑start to run hoop.dev locally or in your Kubernetes cluster. The compose file includes OIDC configuration, so the gateway can verify tokens issued by your identity provider.