Allowing an unconstrained LLM to run queries against your data warehouse can silently expose sensitive rows, violate compliance expectations, and make troubleshooting impossible.
Most teams hand the same API key or static Snowflake credential to a ChatGPT‑driven coding agent and let it execute whatever it generates. The agent talks directly to Snowflake, bypasses any human review, and leaves no trace of what was asked or returned. In practice this means a rogue prompt can retrieve personal data, a mis‑generated query can corrupt tables, and security auditors have nothing to show for the activity.
Without session recording, you have no evidence of what the model asked or received.
What organizations really need is a reliable session recording capability that captures every request, response, and user context, while still allowing the LLM to be useful. Session recording alone, however, does not solve the problem if the traffic never passes through a point where it can be observed. In a typical setup the LLM connects straight to Snowflake, so there is no gate where the recording logic can sit.
Why a dedicated recording layer is required
Even when you add logging on the Snowflake side, you only get high‑level query metadata. You lose the exact prompt that triggered the query, the intermediate reasoning steps, and any redacted fields that should never appear in logs. Moreover, Snowflake’s native audit logs are not designed to block or mask data in real time; they are purely retrospective.
To turn audit into a proactive control, the recording point must sit in the data path – the moment the LLM issues a request and before Snowflake processes it. Only then can the system capture the full conversational context, enforce masking rules, and optionally pause execution for a human approval step.
The gap in typical LLM‑to‑Snowflake pipelines
Most pipelines address identity and credential management but stop short of inserting a guardrail that can see the traffic. They rely on:
- Static Snowflake user or role credentials stored in the LLM’s environment.
- OAuth or SSO tokens that grant standing access for the lifetime of the service.
- Application‑level logging that records success or failure, but not the full payload.
These measures answer “who can connect” but leave “what happens after the connection is made” unchecked. The result is a blind spot: the LLM can run arbitrary SQL, return raw data, and modify schemas without any real‑time visibility or control.
Embedding a gateway in the data path
When you place a layer‑7 gateway between the LLM and Snowflake, every request must traverse that gateway. The gateway becomes the only place where enforcement can happen. This is exactly where session recording belongs.
hoop.dev provides that gateway. It runs a network‑resident agent close to Snowflake, authenticates the LLM via OIDC, and then proxies the connection. Because the proxy sits on the protocol level, it can capture the full request‑response cycle, apply inline masking, and store a replay‑able session record.
How hoop.dev records every interaction
hoop.dev observes the SQL wire protocol, extracts the raw query generated by ChatGPT, and writes a timestamped record that includes the originating identity, the exact prompt (if provided), and the full response payload. The record is stored outside the LLM’s process, ensuring the agent never sees the raw credentials.
Just‑in‑time access and approval
Before a query reaches Snowflake, hoop.dev can enforce a just‑in‑time approval workflow. If a query touches a high‑risk table or requests a column marked as sensitive, the gateway pauses execution and routes the request to a designated reviewer. Only after explicit approval does the query continue, and the approval decision is attached to the session record.
Replay and forensic analysis
Because each session is captured in its entirety, you can replay any interaction to understand how a particular result was produced. This is invaluable for incident response, compliance audits, and debugging LLM behaviour. The replay does not require access to Snowflake’s internal logs; the gateway already holds the full transcript.
Getting started with hoop.dev for ChatGPT and Snowflake
To add session recording to your AI‑driven Snowflake workflow, start by deploying the hoop.dev gateway. The quick‑start guide walks you through a Docker Compose deployment, OIDC configuration, and Snowflake connection registration. All of the heavy lifting – credential storage, identity verification, and gateway placement – is covered in the getting‑started documentation.
Once the gateway is running, register Snowflake as a target connection. hoop.dev will hold the Snowflake service account credentials, while ChatGPT authenticates with an OIDC token. From that point on, every query passes through hoop.dev, where session recording, masking, and approval happen automatically.
For deeper insight into the feature set – including inline data masking and command‑level guardrails – explore the learn section. The open‑source repository on GitHub contains the full source code and deployment manifests: https://github.com/hoophq/hoop.
FAQ
- Does hoop.dev store the Snowflake password? No. The gateway holds the credential internally and never exposes it to the LLM or any downstream client.
- Can I see the raw SQL that ChatGPT generated? Yes. Session recording captures the exact query string, which you can view in the audit UI or export for analysis.
- What happens if a query is blocked? The gateway returns a clear error to the LLM, and the block event is recorded alongside the attempted query for later review.
