An engineering team granted a contract worker a Cursor AI coding agent a direct line to their Snowflake warehouse so the agent could generate queries on demand. Weeks later the contractor’s account was deactivated, but the agent’s token remained embedded in a CI pipeline. When the pipeline ran, a handful of unexpected SELECT statements appeared in Snowflake logs, and the team could not tell which run produced them or whether a human ever reviewed the output. The lack of a reliable audit trail made it impossible to attribute the queries, assess data exposure, or prove compliance to internal auditors.
That scenario is common when AI‑driven assistants are given blanket credentials. Most organizations treat the AI service as just another client, handing it a static Snowflake user or key. The service then talks to Snowflake without any visibility into who initiated each request, what data was returned, or whether the request should have been approved. Without a dedicated control point, the audit record lives only in Snowflake’s generic query log, which does not capture the identity of the AI agent, the originating user, or the justification for the request.
To close that gap, the environment must insert a gate that can see every request, enforce policies, and record the full session. The gate must be positioned after identity verification (so it knows who is acting) but before the request reaches Snowflake (so it can block or mask as needed). Only a Layer 7 proxy that sits on the data path can provide the required enforcement outcomes such as session recording, inline masking, and just‑in‑time approvals.
hoop.dev fulfills that role. It acts as an identity‑aware proxy for Cursor agents that need to talk to Snowflake. The gateway receives an OIDC token from the agent, validates the token against the organization’s IdP, and then forwards the request to Snowflake only after applying the configured policy set. Because hoop.dev is the only component that can see the traffic, it is the sole source of audit trails for the AI‑driven workload.
Audit trails for Cursor agents
When a Cursor instance attempts to execute a query, hoop.dev intercepts the wire‑level protocol. It records the full request, the authenticated identity, and the response payload. The recorded session is stored in a log that auditors can replay whenever needed. Because hoop.dev controls the data path, it can also mask sensitive columns in the response before they reach the AI agent, ensuring that downstream processing never sees raw PII or secrets.
The enforcement flow consists of three distinct layers:
- Setup: The organization configures OIDC or SAML integration so that each Cursor agent receives a short‑lived token reflecting the user’s group membership. This step decides who the request is and whether it is allowed to start, but it does not enforce any policy on its own.
- The data path: hoop.dev sits between the agent and Snowflake. It is the only place where request inspection and policy enforcement happen. No other component in the chain can alter or block the traffic.
- Enforcement outcomes: Because hoop.dev owns the data path, it can record every session, apply inline masking, require just‑in‑time approval for risky queries, and block disallowed commands. Those outcomes exist solely because hoop.dev is present.
With this architecture, the organization gains a complete audit trail that ties each query back to the originating user, the justification provided at approval time, and the exact data returned. The trail is retained, searchable, and can be exported for compliance reporting.
Why a dedicated gateway matters
If the team relied only on Snowflake’s native query log, they would lose three critical pieces of visibility:
- Identity context: Snowflake logs the service account but not the human who triggered the AI request.
- Policy enforcement proof: There is no record of whether a query was approved or blocked before execution.
- Data masking evidence: Snowflake cannot prove that sensitive columns were redacted before reaching the AI.
hoop.dev supplies all three, turning a blind spot into a controllable, auditable channel.
Implementing the solution
The implementation steps are straightforward but require coordination between the identity provider, the hoop.dev deployment, and the Snowflake connection configuration. First, register the Cursor client as an OIDC‑enabled application in your IdP. Then, deploy hoop.dev using the Docker Compose quick‑start or a Kubernetes manifest, pointing it at the Snowflake endpoint and providing the service credential that hoop.dev will use to authenticate to Snowflake. Finally, define a policy that requires approval for any query that accesses tables marked as sensitive and that masks columns such as email or ssn in the response stream.
All of those details are covered in the official getting‑started guide and the broader feature documentation. The repository contains example manifests and Helm charts for production deployments.
FAQ
- Do I need to change my existing Cursor code? No. Cursor continues to use its standard Snowflake client libraries. The only change is that the connection endpoint now points to the hoop.dev gateway.
- Can I retroactively add audit trails to historic queries? hoop.dev records only traffic that passes through it. To capture past activity, you would need to replay those queries through the gateway or rely on Snowflake’s native logs for historical analysis.
- Is the audit log stored securely? hoop.dev writes logs to a storage backend that you configure. The platform ensures that only authorized auditors can read the logs, and the logs are protected against tampering.
For a hands‑on walkthrough, start with the getting‑started documentation. It walks you through identity setup, gateway deployment, and policy definition. When you are ready to explore the code, contribute, or customize the gateway, visit the GitHub repository. For deeper insight into masking, approvals, and session replay, see the learn section of the site.
