Many believe that giving an AI coding assistant like Cursor a static set of database credentials is harmless because the model only generates code. In reality, unrestricted database access opens a path for accidental data leaks, unauthorized queries, and audit gaps.
Why database access controls matter for Cursor
Cursor can read schema, execute ad‑hoc queries, and write results back to Snowflake. Without a guardrail, a single malformed prompt can cause the model to retrieve sensitive columns, export large data sets, or even alter production tables. The lack of visibility into which statements were issued makes forensic analysis impossible, and compliance frameworks demand evidence of who accessed what and when.
Current practice without a gateway
Today most teams hand the AI agent a permanent Snowflake user or service account. The credential lives in environment variables or secret stores that the agent can read directly. Cursor then connects to Snowflake as any other client, bypassing any central policy engine. The result is a black‑box connection: no command‑level audit, no inline masking of PII, and no ability to require human approval for risky operations.
The missing piece: a control surface
Identity providers such as Okta or Azure AD can issue OIDC tokens that identify the AI agent. That step tells the system *who* is making the request, but it does not enforce *what* the request may do. The token alone cannot block a destructive SQL statement, mask a credit‑card column, or record the session for later replay. Without a data‑path enforcement point, the request still travels straight to Snowflake, leaving the organization exposed.
Introducing hoop.dev as the database access gateway
hoop.dev provides the missing Layer 7 gateway that sits between Cursor and Snowflake. The gateway runs a network‑resident agent close to the database and holds the Snowflake credentials itself, so the AI agent never sees them. When Cursor initiates a connection, it authenticates via OIDC, and hoop.dev validates the token, extracts group membership, and then proxies the traffic to Snowflake.
How hoop.dev works with Cursor and Snowflake
First, deploy the hoop.dev gateway using the getting started guide. During registration, define Snowflake as a database target and provide the service‑level credential that hoop.dev will use. Next, configure your OIDC provider so that Cursor can obtain a short‑lived token representing its service identity. When Cursor connects, it points its client (psql, JDBC, etc.) at the hoop.dev endpoint instead of Snowflake directly. hoop.dev then inspects each SQL command, applies the policies you have defined, and forwards only allowed statements to Snowflake.
Key enforcement outcomes
- Session recording: hoop.dev captures every query and response, creating a replayable audit trail that can be reviewed by security or compliance teams.
- Inline data masking: sensitive columns such as SSNs or credit‑card numbers are redacted in the response before they reach Cursor, preventing the model from learning or leaking PII.
- Just‑in‑time approvals: queries that match a high‑risk pattern (e.g., bulk SELECT on a PII table) are paused and routed to a human approver via the hoop.dev workflow.
- Command blocking: destructive statements like DROP TABLE or ALTER DATABASE can be automatically rejected unless explicitly permitted.
- Audit logs: each access event is logged with the originating identity, timestamp, and policy decision, giving you the evidence needed for audits.
Getting started with hoop.dev and Cursor
To protect your Snowflake instance, begin by reading the learn page for an overview of policies such as masking and approval workflows. Follow the step‑by‑step instructions in the getting‑started guide to spin up the gateway, register Snowflake, and bind Cursor’s OIDC client. All configuration details are documented there, and the open‑source repository contains the full source code.
Visit the open‑source repository on GitHub to explore the code, contribute improvements, or raise issues.
FAQ
Can hoop.dev protect other AI coding assistants?
Yes. Any service that can obtain an OIDC token can be routed through hoop.dev, allowing you to apply the same masking, approval, and audit controls to Copilot, Gemini Code, or custom LLM‑driven tools.
What happens if Cursor issues a disallowed command?
hoop.dev intercepts the statement, evaluates the policy, and returns an error to the client. The attempt is still recorded in the audit log, so you have full visibility of the blocked action.
How are audit logs stored and protected?
hoop.dev writes logs to a backend of your choice, object storage, a SIEM, or a database, outside the agent that runs the target workload. Because the gateway is the sole point of enforcement, the logs cannot be tampered with by the downstream Snowflake process.
