Session recording for AI agents on Snowflake

Most broken audit trails for AI agents fail the same way: the recording existed, but it lived where the agent could touch it, or it captured a connection nobody could tie back to a single agent. Session recording for Snowflake is easy to turn on and easy to get wrong, so this post leads with the failure modes.

Get the mistakes out of the way first and the correct setup falls out naturally. Each pitfall below maps to one architectural requirement: the record must live outside the agent, attribute to one principal, and survive the agent's own environment.

Pitfall 1: recording inside the agent process

If the agent writes its own query log, the thing you are investigating controls the evidence. It can rotate, truncate, or simply not emit. The fix is structural: capture sessions at a boundary the agent does not run in. hoop.dev, an open-source Layer 7 access gateway, proxies the Snowflake connection through an in-network agent, so engineers and AI agents query real Snowflake data through hoop.dev and every statement is recorded at the gateway, outside the agent.

Pitfall 2: shared service account, no attribution

Ten agents behind one Snowflake login produce a recording that says "the service account ran a query" ten thousand times. That is not session recording, it is noise. Give each agent a distinct identity at the gateway so every session points at one principal.

Pitfall 3: recording the connection but not the commands

"Agent X opened a session at 14:02" tells you nothing about what it did. You need the statements. Configure command-level recording so each SELECT, each write, and each denied attempt is captured, not just the connection lifecycle.

Pitfall 4: the recording becomes a copy of the data

There is a quieter failure here. If you capture full query results to make the record complete, your session recording turns into a second store of the exact PII and PHI you were trying to protect, sitting outside the warehouse with its own access problem. The fix is to record the statements and the session metadata while masking redacts regulated fields in returned data before the client, and the record, ever see them. You get a faithful account of what the agent ran without minting a fresh copy of regulated data to defend.

Pitfall 5: nobody can read the recording where it lands

A recording that only lives in one console is evidence nobody checks. Route the session events to where your team already looks, for example by pointing the webhooks plugin at your monitoring or evidence sink, so each agent session becomes a record alongside the rest of your stack: who connected, which connection, the statement, the approval status, and the outcome. A recording you actually review beats a complete one you never open.

The setup that avoids all three

1. Register the Snowflake connection in hoop.dev. The gateway brokers access as the session principal and holds the warehouse credential.
2. Authenticate each agent to the gateway through your identity provider over the MCP server, one identity per agent.
3. Confirm command-level recording is active so statements, not just sessions, are captured.
4. Run queries and read the record at the gateway, where the agent cannot reach it.

Verify you avoided them

Run a query, then check the record shows the exact statement, a single agent principal, and a timestamp, stored at the gateway. Then run something the agent's role forbids and confirm the denial is recorded too. If all four are present, your session recording has cleared the three pitfalls above.

See how command-level recording is structured and the getting-started guide to configure the connection.

FAQ

Why not just use Snowflake's query history?

Query history is useful, but tying every statement to a specific agent identity and capturing it outside the agent is what makes the record usable as evidence. The gateway does both.

Does recording store sensitive query results?

Masking redacts regulated fields in returned data before the client sees them, so the record does not become a copy of PII.

What about denied queries?

Configure recording to capture them. The statements an agent tried and could not run are often the clearest signal of trouble.

hoop.dev is open source. Read the recording code and set up tamper-resistant Snowflake sessions at github.com/hoophq/hoop.