An offboarded contractor’s API key still lives in a CI pipeline that lets a ChatGPT‑powered coding assistant push queries to Snowflake. The assistant can read tables, write results, and even alter schemas, all without any human seeing the exact statements that were run. When a security audit asks for audit trails, the team can only point to a generic IAM policy; there is no record of which prompt triggered which query, no way to hide credit‑card numbers that might have been returned, and no gate to stop a destructive command before it hits the data warehouse.
This situation is common when organizations treat AI agents as just another service account. The account receives a static secret, the secret is baked into deployment scripts, and the agent talks directly to Snowflake over the wire. The setup satisfies authentication, but it provides no visibility, no real‑time data protection, and no way to require a human to approve a risky operation.
What is missing is a control plane that sits between the AI agent and Snowflake, inspects every request, and enforces policy before the request reaches the database. The missing piece must be able to validate the identity that the agent presents, enforce just‑in‑time (JIT) approvals, mask sensitive fields in query results, and record the entire session for later replay. Without that data‑path enforcement, the organization continues to rely on static credentials and hopes that IAM alone will keep things safe.
Audit trails for ChatGPT agents
hoop.dev provides the required data‑path gateway. It runs a lightweight agent inside the network where Snowflake is reachable, then proxies every connection from the AI coding assistant through that agent. The gateway reads the OIDC token that the assistant presents, extracts group membership, and decides whether the request is allowed. Because the gateway sits on the wire, it can record each SQL statement, capture the exact response payload, and store a replay‑able session log.
When a query contains columns that hold personally identifiable information or payment data, hoop.dev masks those fields in real time before they are returned to the AI agent. The masking policy is defined once and applied consistently to every response, ensuring that downstream processes never see raw secrets.
If a request attempts to run a DDL command that could drop a table, hoop.dev blocks the command outright and returns an error to the AI agent. For operations that are risky but not outright forbidden, such as loading a large data set into a production schema, hoop.dev can trigger a just‑in‑time approval workflow. A designated approver receives a concise summary of the request and must explicitly grant permission before the gateway forwards the command to Snowflake.
How the architecture works
The first layer is identity provisioning. Engineers create a non‑human service account for the ChatGPT coding agent and bind it to an OIDC provider. The service account receives only the minimal set of roles needed to query Snowflake. This setup decides who the request is and whether it may start, but it does not enforce any runtime guardrails.
The second layer is the gateway itself. hoop.dev is the only place where enforcement occurs. All traffic from the AI agent to Snowflake is forced through the gateway, which acts as an identity‑aware proxy. Because the gateway controls the TCP stream, it can inspect the SQL protocol, apply masking, enforce JIT approvals, and record the full session.
Finally, the enforcement outcomes, audit trails, inline masking, command blocking, and session replay, are produced exclusively by hoop.dev. If the gateway were removed, none of those outcomes would exist; the static credential would again give the AI agent unrestricted access.
Implementing the solution
Start by deploying hoop.dev using the official Docker Compose quick‑start. The compose file pulls the gateway image, configures OIDC verification, and launches the network‑resident agent. Register Snowflake as a connection in the portal, supply the service account’s Snowflake credentials, and define the masking rules for any columns that contain sensitive data.
Next, update the CI job or the AI integration to point its Snowflake endpoint at the gateway address instead of the raw Snowflake endpoint. The AI agent continues to use its standard client libraries (for example, the Snowflake Python connector), but the traffic is now intercepted by hoop.dev.
Finally, configure the approval workflow for high‑risk operations. The workflow can be tied to an internal ticketing system or a simple email approval step. Once configured, any request that matches the policy will pause at the gateway until an authorized approver clicks “allow.”
All of these steps are described in detail in the getting‑started guide and the broader feature documentation. The repository contains the compose file and example configuration files for Snowflake, so you can clone it and adapt it to your environment.
FAQ
- Does hoop.dev store Snowflake credentials? The gateway holds the credentials internally; they never leave the host where the agent runs, and they are never exposed to the AI agent.
- Can I retroactively view what the AI agent did? Yes. hoop.dev records each session and makes it replayable, so auditors can review the exact statements and masked results.
- Will masking affect the correctness of the AI’s output? Masking only applies to fields marked as sensitive. The AI receives the same schema and non‑sensitive values, preserving functional behavior while protecting data.
Explore the source and contribute on GitHub.
