A reliable audit trail for every query an AI coding agent runs against BigQuery lets you see who asked what, when, and which rows were returned. With that visibility you can detect misuse, satisfy compliance reviewers, and roll back unintended data exposure. The goal is clear: every request from Cursor should be recorded, attributed, and retained for later inspection.
In many organizations the current workflow is far from that ideal. Teams provision a static service‑account key for the Cursor AI model, bake the credential into the CI pipeline, and let the agent talk directly to BigQuery. The connection bypasses any central policy layer, so the platform has no record of which prompt triggered which query. If the model generates a costly or sensitive query, there is no way to trace it back to the originating user or to the prompt that caused it. The result is a blind spot that can hide data exfiltration, cost overruns, or regulatory violations.
What is missing is a control point that can observe the request, enforce policies, and generate an audit trail. Adding a gateway that sits between the Cursor agent and BigQuery satisfies the first part of the problem, but it does not automatically solve everything. The request still reaches BigQuery directly, and without a recording mechanism the organization remains unaware of what was executed. In other words, the precondition of having a visible audit trail is not met simply by routing traffic through a proxy.
Why audit trails matter for Cursor on BigQuery
Audit trails give you three concrete benefits. First, they provide non‑repudiation: you can prove which identity initiated a query and what data was returned. Second, they enable forensic analysis after an incident, allowing you to replay the exact sequence of prompts and queries. Third, they support external audits that require evidence of per‑user access to analytical workloads. Without these capabilities, any breach or misuse is difficult to detect, attribute, or remediate.
Setup: identity and least‑privilege provisioning
The foundation is a reliable identity source. Cursor agents should authenticate with an OIDC or SAML provider that your organization already trusts. Users receive short‑lived tokens that encode group membership and role information. Service accounts used by the AI model are granted only the BigQuery scopes they need, and those scopes are tied to the identity that will appear in the audit record. This setup decides who can start a request, but on its own it does not enforce any logging or masking.
The data path: placing a gateway between Cursor and BigQuery
hoop.dev acts as the only point in the data path where enforcement can occur. By deploying the gateway inside the same network segment as BigQuery, every SQL statement issued by Cursor must pass through hoop.dev before reaching the database. The gateway inspects the wire‑protocol, extracts the query, and applies policy checks. Because the gateway is the sole conduit, no request can bypass the controls.
Enforcement outcomes: audit trails generated by the gateway
hoop.dev records each session, capturing the authenticated identity, the full SQL text, and the result set metadata. Those records are stored in a log that is retained for audit and can be queried later for compliance or incident response. Because hoop.dev is the active component in the data path, the audit trail exists only because the gateway is present; removing hoop.dev would eliminate the record entirely.
In addition to logging, hoop.dev can mask sensitive columns in query results before they leave the gateway, and it can block statements that match a deny‑list. Those controls complement the audit trail by reducing the blast radius of a rogue query while still providing a complete record of the attempted operation.
Putting it together: a step‑by‑step conceptual flow
- Deploy the hoop.dev gateway in the same VPC or subnet as your BigQuery instance. The deployment uses Docker Compose for a quick start, or you can use the provided Kubernetes manifests.
- Configure a connection object that points to the BigQuery endpoint and supplies the service‑account credential that the gateway will use. The credential never leaves the gateway.
- Enable OIDC authentication so that Cursor agents present a token that hoop.dev validates. The token’s claims drive the access policy.
- Define an audit policy that tells hoop.dev to log every query, retain the log for the required period, and optionally mask columns such as credit‑card numbers.
- When a developer triggers a Cursor generation, the AI model sends the SQL to the gateway. hoop.dev records the request, applies any masking or blocking rules, forwards the query to BigQuery, receives the response, masks as needed, and returns the result to the model.
The result is a complete, tamper‑evident audit trail for every AI‑generated query, plus real‑time protection against accidental data exposure.
Common mistakes to avoid
- Giving the Cursor service account broad BigQuery permissions and relying on downstream IAM checks. The gateway should be the only place where the request is examined.
- Storing the audit log in a location that the same service account can delete. Use a separate storage bucket or log service with write‑only permissions for the gateway.
- Assuming that a static credential alone provides accountability. Without per‑request logging, you cannot tie a query to a specific user or prompt.
Getting started
For a hands‑on walkthrough, see the getting‑started guide. The documentation explains how to deploy the gateway, configure the BigQuery connection, and enable OIDC authentication. All of the policy definitions are described in the learn section, where you can explore masking rules, approval workflows, and log retention settings.
When you are ready to explore the source code, contribute, or customize the gateway, visit the hoop.dev GitHub repository. The repo contains the Docker Compose file, Helm charts, and example policies to help you get up and running quickly.
FAQ
Do I need to change my existing BigQuery queries?
No. Because hoop.dev operates at the protocol layer, existing client tools such as the BigQuery console or psql‑compatible drivers continue to work unchanged. The only difference is that traffic now passes through the gateway.
Can I retain audit logs for multiple years?
Yes. hoop.dev’s audit log can be configured to write to any durable storage backend you choose, allowing you to meet long‑term retention requirements.
Masking is applied after the database returns the result set, so the performance impact is limited to the size of the response. In most workloads the overhead is negligible compared to the benefit of protecting sensitive columns.
