When an AI coding assistant can query production data without any guardrails, unrestricted database access creates the risk of accidental data leakage, compliance violations, and costly remediation. Unchecked queries can also consume expensive BigQuery slots, inflating cloud bills while exposing sensitive columns to downstream tools that were never intended to see them.
In many early adopters' environments, Cursor runs with a static service‑account key that grants full read‑write rights on the analytics dataset. The agent connects directly to BigQuery, bypassing any review process. Because the connection is a straight API call, there is no session record, no inline masking of personally identifiable information, and no way to require a human to approve a potentially dangerous query. The result is a blind spot: engineers cannot answer who ran which query, what data was returned, or whether a query should have been blocked.
Even when teams move to a more disciplined model, issuing a dedicated service account for Cursor and limiting the IAM role to a specific project, the fundamental problem remains. The request still travels straight to BigQuery, and the gateway that could enforce policy is missing. The setup defines who the agent is, but it does not provide a place where the request can be inspected, approved, or logged. Without a data‑path enforcement point, the organization cannot guarantee that every database access request respects masking policies or that risky queries are held for review.
Why the data path must enforce database access policies
Enforcement belongs in the layer that actually carries the traffic. By placing a proxy between the AI agent and the database, the system can examine each SQL statement before it reaches BigQuery. This is the only reliable way to guarantee that masking, approval, and audit happen for every request, regardless of the client’s intent.
hoop.dev fulfills that role. It sits as a Layer 7 gateway, terminating the Cursor connection and then opening a separate, credential‑protected session to BigQuery. The gateway holds the database credential, so the AI agent never sees a secret. While the request passes through hoop.dev, the platform can:
- Record the full query and response for replay and forensic analysis.
- Mask sensitive columns in real time, ensuring that PII never leaves the gateway.
- Require just‑in‑time approval for queries that match a risk pattern, such as SELECT * FROM sensitive_table.
- Enforce role‑based limits on which schemas or tables the agent may touch.
All of these outcomes are possible only because hoop.dev is the data‑path component. The surrounding authentication setup (OIDC service account, least‑privilege IAM role) tells the system who the request is, but the actual policy enforcement happens inside the gateway.
Implementing the control flow for Cursor
Deploying the solution follows a high‑level workflow:
- Run the hoop.dev gateway in the same network segment as BigQuery. The official getting started guide walks through the Docker Compose or Kubernetes deployment options.
- Register BigQuery as a connection in hoop.dev, supplying the service‑account credential that the gateway will use.
- Configure Cursor to authenticate with the same OIDC provider that hoop.dev trusts. The AI agent presents a short‑lived token; hoop.dev validates it and maps the identity to the appropriate role.
- Enable the desired guardrails in the feature documentation: inline masking rules for columns like email or SSN, approval policies for high‑cost queries, and session recording.
- Once the gateway is active, Cursor’s normal client libraries (e.g., the BigQuery Python client) point at the hoop.dev endpoint instead of the public BigQuery API. The traffic flow is now: Cursor → hoop.dev → BigQuery.
The architecture guarantees that every database access request passes through the enforcement layer, and the AI agent cannot bypass the controls because it never holds the underlying credential.
Benefits at a glance
- Full audit trail of every query, satisfying internal and external compliance checks.
- Real‑time data protection through column‑level masking, reducing exposure of PII.
- Just‑in‑time approvals that stop costly or destructive queries before they run.
- Credential isolation – the AI agent never sees the BigQuery service account.
- Open‑source flexibility – teams can extend or self‑host the gateway to match internal policies.
FAQ
Can hoop.dev prevent accidental data exfiltration by an AI agent?
Yes. hoop.dev inspects each SQL statement and can block any query that attempts to read columns marked as sensitive. The block happens before the query reaches BigQuery, so no data leaves the database.
How does hoop.dev provide query‑level audit for Cursor?
hoop.dev records the full request and response payload for every session. The logs are stored outside the agent process, giving security teams a reliable source of truth for investigations and compliance reporting.
Explore the open‑source repository to see how the gateway is built and to contribute improvements: GitHub – hoop.dev.
