Putting access controls around Claude: session recording for AI coding agents (on Snowflake)

When an AI coding agent like Claude writes queries against a production Snowflake warehouse, every generated statement becomes a potential vector for data leakage or accidental schema change. Session recording gives you a complete, replayable audit trail for every Claude request.

Because Claude operates without a human in the loop, there is no natural audit trail that ties a specific prompt to the exact SQL that was executed. If a privileged query runs unintentionally, the organization loses visibility into who, or what, caused the change, and compliance teams cannot prove that the operation was authorized.

In practice, many teams simply expose the Snowflake credentials to the Claude service, let the agent run unchecked, and rely on Snowflake’s own query logs after the fact. Those logs do not capture the prompt‑to‑response relationship, they do not mask sensitive result fields, and they cannot be gated by a real‑time approval workflow. The result is a blind spot that makes it hard to demonstrate responsible AI use or to investigate a breach.

Why session recording matters for AI coding agents

Session recording captures a complete, replayable transcript of every interaction between the AI agent and the target system. For Claude, this means preserving the original prompt, the generated SQL, and the database response in a single, immutable record. The benefits are threefold:

• Forensics: When an unexpected data change occurs, investigators can replay the exact session to see the prompt that triggered it.
• Compliance: Regulations that require evidence of who accessed what data become satisfied when a verifiable session log ties the AI’s identity to the operation.
• Risk mitigation: Real‑time visibility enables automated policies that block or flag dangerous statements before they touch the warehouse.

Setting up a trustworthy identity foundation

The first step is to make Claude obtain OIDC or SAML tokens from a corporate IdP. By configuring Claude to request those tokens, the organization can enforce least‑privilege scopes, short‑lived tokens, and group‑based access controls. This setup determines *who* the request is, but it does not enforce *what* the request can do once it reaches Snowflake.

Without a dedicated enforcement point, the token alone cannot guarantee that the generated SQL complies with internal policies. The request would travel directly to Snowflake, bypassing any opportunity for inspection, masking, or approval.

Placing the gateway in the data path

hoop.dev acts as a Layer 7 gateway that sits between Claude’s authentication layer and the Snowflake endpoint. By routing every Claude‑initiated connection through hoop.dev, the organization creates a single, controllable choke point where policy can be applied.

Because hoop.dev proxies the wire‑protocol, it sees the exact SQL statements before it sends them to Snowflake. Only here can we reliably enforce inline masking, command‑level approval, and real‑time blocking.

How hoop.dev delivers session recording for Claude

hoop.dev records each Claude session from the moment the OIDC token arrives until it closes the connection. The recorded stream includes the original prompt, the generated query, and the full response payload. By storing the session outside the agent process, hoop.dev guarantees that the AI runtime cannot tamper with the log.

When hoop.dev captures a session, it also applies inline masking to any columns that match a configured pattern, ensuring that sensitive fields such as credit‑card numbers or personal identifiers never leave the gateway in clear text.

In addition to active recording, hoop.dev can trigger just‑in‑time approval workflows. If a generated statement matches a high‑risk rule, such as a DROP DATABASE or an export of large data sets, hoop.dev pauses the request and routes it to an authorized reviewer. Only after explicit approval does the gateway forward the command to Snowflake.

Operational benefits of a centralized audit trail

Because every Claude interaction is funneled through hoop.dev, security teams receive a single source of truth for AI‑driven data access. Security teams can export the audit trail to SIEMs, feed it into compliance dashboards, and replay it during incident response drills. The consistent format eliminates the need to stitch together disparate Snowflake logs and Claude debugging output.

Furthermore, the gateway’s session recordings are searchable by user, time range, or query pattern, making it easy to surface all instances where a particular table was accessed by an AI agent. This visibility is impossible when the agent talks directly to Snowflake.

Getting started

To implement session recording for Claude, follow the official getting‑started guide. The guide walks you through deploying the hoop.dev gateway, configuring OIDC authentication, and registering Snowflake as a protected resource. Detailed policy definitions, including masking rules and approval workflows, are covered in the feature documentation.

You can find all configuration files and example manifests in the open‑source repository. Review the code and adapt it to your environment.

View the open‑source repository on GitHub to explore the implementation details and contribute improvements.

FAQ

Is the session data stored encrypted? The gateway stores recordings in a location you control. Encryption at rest is recommended, but the exact mechanism depends on your storage backend.

Can I retroactively apply masking to existing recordings? Masking applies at record time. To mask older logs, you would need to reprocess them through the gateway or a separate data‑sanitization pipeline.

Does hoop.dev impact query latency? Because hoop.dev inspects traffic at the protocol layer, there is a modest overhead. In most environments the added latency is negligible compared to network round‑trip times, and the security benefits outweigh the cost.