A newly hired contractor is given access to a Claude‑powered coding assistant that automatically generates Snowflake SQL statements, but the organization lacks audit trails for those actions. The assistant runs as part of a CI pipeline, pushes queries directly to the data warehouse, and returns results to downstream jobs. No human ever sees the raw queries or the data that flows back, and the organization has no record of which statements were issued, who triggered them, or what rows were returned.
Without a centralized observation point, the team cannot answer basic forensic questions: Did the AI write a query that exposed personally identifying information? Was a privileged table accessed during a nightly batch? Did a mis‑prompt cause a costly full‑table scan? The lack of visibility makes it impossible to demonstrate compliance with internal policies or external regulations that require detailed audit trails of data access.
For AI‑driven workloads, an audit trail must capture the full request‑response cycle: the prompt sent to Claude, the generated SQL, the execution result, and any subsequent actions taken by downstream services. It should also record the identity that initiated the request, even when that identity is an automated service account, and store the information in an audit log that can be queried by auditors.
Why existing identity checks are not enough
Most organizations already enforce identity verification for service accounts that call Snowflake. An OIDC token or a short‑lived IAM role can prove that a request originates from an authorized source. However, that verification happens at the Snowflake authentication layer, after the request has already traversed the network and been processed by the database. At that point, the platform cannot retroactively apply masking, block risky commands, or insert an approval step. The request reaches the target directly, and Snowflake itself does not provide built‑in, per‑prompt audit logging for AI agents.
In other words, the identity check solves the "who is calling" question but leaves the "what did they do" and "can we intervene" questions unanswered. The system still lacks a single control surface that can enforce audit trails, inline data masking, and just‑in‑time approvals for every Claude‑generated query.
hoop.dev as the data‑path enforcement point
hoop.dev supplies a Layer 7 gateway that sits between Claude and Snowflake. The gateway acts as an identity‑aware proxy: it validates the caller’s OIDC or SAML token, maps the identity to a set of policies, and then forwards the request to Snowflake using credentials that only the gateway knows. Because the traffic passes through the gateway, hoop.dev can record each session, apply inline masking to sensitive columns, and require a human approver for queries that match risky patterns.
When a Claude agent initiates a query, hoop.dev captures the prompt, the generated SQL, and the resulting data rows. It stores this information as an audit record that includes the originating identity, timestamp, and policy decisions made (e.g., "masked column X", "approval required", "query blocked"). The gateway also supports replay of the entire session, allowing security teams to reconstruct exactly what the AI agent attempted and what Snowflake returned.