An AI coding agent that writes data pipelines often runs with a shared service account token that grants it unrestricted access to the Snowflake warehouse. The CI job stores the token, developers check it into the repository, and pipelines reuse it. Because the organization lacks session recording, it cannot answer audit questions, cannot replay the interaction, and cannot prove that the agent behaved within policy.
Even if the team decides that every AI‑driven query should be recorded, the current setup still sends the request straight to Snowflake. Snowflake receives a normal client connection, the shared credential presents itself, and Snowflake processes the statement without any external guardrail. There is no place to inject a recording hook, no way to enforce a policy that says “only record when a human approves,” and no isolation of the credential from the agent itself.
Why session recording matters for AI agents
Session recording provides an immutable replay of every command and response that traverses a connection. For AI agents, this capability is essential because the generated code can change rapidly, and the intent behind a query may not be obvious after deployment. A recorded session lets security teams review the exact SQL, verify that data masking was applied, and demonstrate compliance with internal data‑handling rules. It also creates a deterrent: an agent that knows its actions are captured is less likely to execute a risky operation.
Placing the gateway in the data path
To achieve reliable session recording, the enforcement point must sit between the identity that initiates the request and the Snowflake service itself. The gateway becomes the sole place where traffic can be inspected, logged, and stored. This is the only architecture that guarantees every interaction is captured, because Snowflake never receives traffic directly from the agent.
hoop.dev fulfills this role. It acts as an identity‑aware proxy that validates OIDC or SAML tokens, determines the user’s groups, and then forwards the request to Snowflake using a credential that only the gateway knows. The agent never sees the Snowflake secret. While the connection is in flight, hoop.dev records each request and response, timestamps them, and stores the replay in a secure location. You can later play back the recorded session in a forensic tool or present it to auditors.
How the recording workflow works
- Setup: An engineer provisions an OIDC client in the organization’s identity provider and assigns the AI agent to a role that permits access to the Snowflake gateway.
- The data path: When the agent initiates a Snowflake session, it connects to hoop.dev instead of the Snowflake endpoint. hoop.dev authenticates the token, checks the role, and establishes a backend connection using its own Snowflake service account.
- Enforcement outcome: hoop.dev records the full session, including the exact SQL statements and the result sets returned. The gateway stores the recording in a secure location, and you can retrieve it for replay.
This architecture satisfies the three attribution categories. The setup decides who may start a request, but it does not enforce any policy. The gateway, the data path, is the only place enforcement occurs. The session recording outcome exists solely because hoop.dev sits in that path.