When an agent runs a query you did not expect against your warehouse, the first question is always the same: what exactly did it run, and against which schema? If the answer lives only in the agent's own logs, you are trusting the thing under investigation to report on itself. Session recording exists so the answer lives somewhere the agent cannot edit.
The architectural requirement is simple to state and easy to get wrong. The record of what an agent did on Snowflake must be written outside the process the agent runs in. A log the agent can rotate, truncate, or never emit is not evidence. It is a courtesy.
Pair recording with a least-scope role
Recording is only half the control. The other half is making sure the agent cannot do much in the first place. A least-scope configuration grants the agent exactly the warehouses and schemas its task needs, so the recorded sessions are short, legible, and bounded. A tight role makes the recording easy to read and the blast radius small.
In Snowflake terms, that means a dedicated role granted usage on one warehouse and select on one schema, not a role that inherits half the account. Build the role narrow, then let session recording capture what the agent does inside that narrow box.
Snowflake's own ACCESS_HISTORY and QUERY_HISTORY views are a reasonable starting reference, but they have two limits for agents. They are queryable by anyone with the right grant, including potentially the agent's own role, and they tie activity to the connecting Snowflake user, which is usually the shared service account every agent connects through. A recording that an investigated principal can read, and that cannot separate one agent from another, is weaker evidence than it looks. Recording at the gateway fixes both: the record lives outside the agent's reach, and it is keyed to the agent's own identity rather than the shared warehouse login.
So the least-scope role and the external recording work together. The role keeps the agent inside a small box. The recording, written where the agent cannot edit it, shows exactly what happened inside that box and attributes it to one principal.
hoop.dev is an open-source Layer 7 access gateway. It proxies the Snowflake connection through an in-network agent, so engineers and AI agents query real Snowflake data through hoop.dev. Every statement is captured at the gateway, outside the agent runtime, which is exactly where session recording has to live.
- Register the Snowflake connection in hoop.dev. The gateway brokers access as the session principal and holds the warehouse credential.
- Create a least-scope Snowflake role and map the agent identity to it. Grant only the warehouse usage and schema reads the task requires.
- Authenticate the agent to the gateway through your identity provider over the MCP server, so each session ties to a known principal.
- Run queries. hoop.dev records each statement, the principal, and the timestamp at the command level, independent of the agent.
Verify the record
Run a known query through the agent, then open the session record and confirm the statement, principal, and time are all present. Then run a query the role should block and confirm it is denied and that the denial is recorded too. A good session recording captures both what happened and what was refused.
Pitfalls
- Recording but over-granting. A full transcript of an over-scoped agent is a long, alarming read. Scope the role first.
- Trusting agent-side logs as the system of record. Keep the authoritative record at the gateway, outside the agent.
- Skipping denied attempts. The queries an agent tried and could not run are often the most useful signal.
For the recording model in depth, see how command-level session recording works, and the getting-started guide for setup.
FAQ
Where is the session recording stored?
At the gateway, outside the agent process. That separation is what makes it usable as evidence rather than a self-report.
Does recording capture results or just queries?
It captures the statements and the session, and masking redacts sensitive fields in returned data before it reaches the client, so the record does not become a copy of regulated data.
Why combine recording with a least-scope role?
A narrow role keeps sessions short and readable and limits what a recording could ever show going wrong.
hoop.dev is open source. Read the code and set up recorded, least-scope Snowflake access at github.com/hoophq/hoop.
