Just-in-time access for MCP servers on Snowflake

How can you grant an MCP server just-in-time access to Snowflake without handing out long‑lived credentials?

Most teams today give an AI‑driven MCP server a static Snowflake user or a shared service account. The credential lives in a secret store, is checked out by the server, and then used for every query. Because the account has broad read/write rights, any buggy prompt or malicious payload can exfiltrate data, alter tables, or run costly compute without anyone noticing. Auditing is limited to Snowflake’s own logs, which do not show who triggered the request at the application layer.

What you really need is just-in-time access: the server should receive a credential only at the moment it needs to run a query, and that credential should be scoped to the exact operation. The request would still travel straight to Snowflake, but the temporary grant would disappear after the query finishes. Without an additional control point, however, the request bypasses any approval workflow, data masking, or session recording. The Snowflake side sees a normal connection and cannot enforce the extra guardrails you require.

Why just-in-time access matters for Snowflake

Snowflake stores a lot of sensitive analytical data. Granting a permanent account to an MCP server creates a permanent attack surface. Just-in-time access reduces that surface by limiting the time window and the scope of each credential. It also aligns with compliance best practices that call for least‑privilege, time‑bound privileges. When the access is granted only for a single query, you can tie the operation to a specific user, purpose, and approval step.

How hoop.dev inserts the data path

hoop.dev acts as a Layer 7 gateway that sits between the MCP server’s identity and the Snowflake endpoint. The gateway authenticates the request using OIDC or SAML, then decides whether to issue a short‑lived Snowflake token. Because the gateway is the only place the traffic passes, hoop.dev can enforce several outcomes:

• It records each session so you have a replayable audit trail.
• It masks sensitive columns in query results before they reach the MCP server.
• It can pause a request and require a human approver when the query touches high‑risk tables.
• It revokes the temporary token immediately after the query finishes, ensuring no lingering privileges.

All of these enforcement outcomes exist only because hoop.dev sits in the data path; the Snowflake connection itself remains unchanged.

Putting it together for an MCP server

First, register Snowflake as a connection in the gateway. The registration includes the Snowflake account identifier and a privileged service principal that the gateway can use to mint short‑lived tokens. Next, configure your MCP server to authenticate to hoop.dev via OIDC. When the server needs to run a query, it asks hoop.dev for a session. hoop.dev checks the requestor’s group membership, applies any approval policies you have defined, and then creates a temporary Snowflake credential scoped to the requested database and role.

Because the gateway proxies the protocol, it can inspect the SQL statement in real time. If the statement matches a masking rule, hoop.dev redacts the designated columns before forwarding the response. If the statement touches a protected schema, the gateway can halt execution and route the request to an approver. After the query completes, hoop.dev logs the full request and response metadata, records the session for replay, and immediately expires the temporary credential.

From the MCP server’s perspective, the flow is identical to a direct Snowflake connection; the only difference is that the credential is never stored long term and every operation is subject to the policies you defined in the gateway.

For a step‑by‑step walkthrough of the registration process and policy definition, see the getting‑started guide. Detailed information about masking policies and approval workflows is available in the learn section of the documentation.

FAQ

Does this approach require changes to existing Snowflake queries?
No. The gateway forwards the SQL unchanged unless a masking or approval rule applies.

Can I audit who triggered each query?
Yes. hoop.dev records the identity that initiated the session, the exact statement, and the approval outcome.

What happens if the MCP server crashes mid‑query?
The temporary Snowflake token is revoked as soon as the gateway detects the broken session, preventing any orphaned privileges.

Ready to try it yourself? Explore the open‑source repository on GitHub and start building just‑in‑time access for your Snowflake workloads today.