A common misconception is that Snowflake's built-in query history provides complete visibility into every interaction an application makes. In reality, the native logs only capture the fact that a query ran, not who initiated it, what parameters were used, or the surrounding context of an automated MCP server. Because the platform lacks built-in session recording, teams cannot replay the exact sequence of queries and therefore struggle to prove which data set produced a particular model output.
Why native Snowflake logging falls short
Snowflake's audit logs are valuable, but they are a downstream artifact. They do not capture the full request-response exchange, nor do they provide a deterministic replay of the session. In a typical deployment, an MCP server authenticates once with a service account, then issues many queries. If a query fails, is retried, or is aborted, the native log may only show the final state, erasing the decision path that led to the outcome. This makes it hard to answer questions such as "Which exact query produced this unexpected row?" or "Did the model see PII before it was masked?". For teams that must demonstrate strict data-access governance, the missing piece is a trustworthy, end-to-end session recording capability.
How session recording works for Snowflake MCP servers
To close the gap, the architecture must place a recording component on the traffic path between the MCP server and Snowflake. The component must be able to see every protocol message, store it in a durable store, and make it searchable for auditors. This is exactly what the data-path gateway provides. The gateway sits between the identity provider and the Snowflake endpoint, acting as the sole conduit for all client traffic. Because every request must pass through the gateway, it can capture a complete, ordered log of each query, the parameters supplied, and the response payload.
Setup – Identity is still handled by the organization’s OIDC or SAML provider. Engineers and service accounts receive short-lived tokens that the gateway validates. The gateway then uses a Snowflake-specific credential that it stores securely; the client never sees this secret.
The data path – All MCP traffic is proxied through the gateway. The gateway inspects the Snowflake wire protocol, records the request and response, and forwards the data to Snowflake. Because the gateway is the only place where the traffic is observable, it is the only place where enforcement can occur.
Enforcement outcome – hoop.dev records each session. The recorded stream includes timestamps, user identifiers, query text, and result metadata. The recordings are kept in a backend that supports replay, so an auditor can later reconstruct the exact sequence of commands that led to a particular data view. This capability exists only because the gateway sits in the data path; without it, Snowflake's native logs would remain the sole evidence source.