AI agents that can run arbitrary queries against Snowflake are a single misstep away from exposing or corrupting critical data.
Relying on session recording gives you a live, replayable view of every query, which is far more protective than looking at logs after the fact.
Most organizations treat Snowflake audit logs as the sole evidence of what an agent did. The logs capture timestamps, user identifiers, and the raw SQL statements that were executed. On paper that looks sufficient, but in practice audit logs are a retrospective view that offers no real control.
Typical deployments give an AI service a static Snowflake credential, often stored in a secret manager and mounted into the runtime. The service connects directly to the warehouse, bypassing any intermediate guardrail. Engineers rely on role‑based permissions to limit what the credential can do, but those roles are usually broad enough to satisfy many downstream workloads.
To gain real‑time control, organizations need a gateway that sits in the data path, terminates the client connection, applies policy, and forwards only approved traffic. Such a gateway can enforce session recording, inline data masking, just‑in‑time approvals, and command‑level blocking.
Why session recording matters more than audit logs
Session recording captures the entire interaction between the client and Snowflake: every query sent, every result returned, and every user‑initiated pause or cancellation. Unlike audit logs, which are generated after the fact, a recording is a live artifact that can be replayed to understand intent, verify compliance, or feed an incident response timeline. When an AI agent is involved, the recording also reveals the exact prompt that triggered a risky query, giving teams insight into model behavior.
Beyond forensic value, session recording enables proactive defenses. A gateway that inspects traffic can block a DELETE FROM statement before it reaches Snowflake, or it can mask credit‑card numbers in a result set in real time. Those actions are impossible when you rely solely on audit logs, because the damage has already been done.
Introducing a data‑path gateway for Snowflake
hoop.dev sits in the data path between identities and the Snowflake endpoint. It acts as an identity‑aware proxy that terminates the client connection, applies policy, and then forwards only the allowed traffic. Because all traffic flows through hoop.dev, it can enforce session recording, inline data masking, just‑in‑time approvals, and command‑level blocking.
When an AI service presents an OIDC token, hoop.dev validates the token, extracts group membership, and checks the request against a policy engine. If the request is approved, hoop.dev opens a connection to Snowflake using its own least‑privilege credential. The agent never sees that credential, and every command passes through hoop.dev’s guardrails.
hoop.dev records each session from start to finish, storing a replayable stream that can be inspected later. It masks sensitive fields in query results according to policy, ensuring that downstream logs or screenshots never contain raw personal data. If a command violates a rule, hoop.dev blocks it instantly and can trigger an approval workflow before allowing it to proceed.
How the enforcement outcomes are achieved
- Session recording – hoop.dev writes a complete, timestamped transcript of the interaction, enabling replay and audit.
- Inline masking – hoop.dev redacts configured columns in real time, preventing exposure of regulated data.
- Just‑in‑time approval – hoop.dev can pause a high‑risk query and route it to a human reviewer before execution.
- Command blocking – hoop.dev rejects prohibited statements such as DROP DATABASE or UNLOAD that could cause data loss.
All of these outcomes exist only because hoop.dev occupies the gateway position. The setup, OIDC authentication, role assignment, and credential provisioning, determines who may start a session, but without the gateway, there is no place to enforce the policies.
Getting started
To retrofit an existing Snowflake deployment with these controls, follow the getting started guide. The documentation walks you through deploying the gateway, registering a Snowflake connection, and defining policies for session recording and masking. Because hoop.dev is open source, you can inspect the code and extend the policy engine to match your organization’s risk profile.
For a deeper dive into the feature set, including how to configure inline masking rules and approval workflows, visit the learn portal. The examples there illustrate real‑world policy definitions without exposing any secret configuration.
FAQ
Does session recording replace audit logs?
No. Audit logs remain valuable for compliance reporting, but session recording provides a richer, replayable view that audit logs cannot. Using both together gives you the most complete picture.
Can I use hoop.dev with existing Snowflake roles?
Yes. hoop.dev forwards requests using its own credential, but you can map identity groups to Snowflake roles in the policy layer, preserving your existing role hierarchy while adding guardrails.
hoop.dev processes traffic at the protocol layer and adds minimal latency. The trade‑off is the increased security and visibility you gain.
Explore the source code on GitHub to see how the gateway is built and to contribute enhancements.
