How can you let an AI coding assistant like Cursor run queries against production BigQuery datasets while enforcing production access controls?
Many teams hand the same service‑account key to Cursor and let it connect directly to the warehouse. The secret store holds the key, the deployment mounts it into the agent container, and the agent reuses it for every request. Engineers forget to rotate it, auditors cannot see which query ran when, and a single compromised agent can sweep across all tables. The risk is amplified because the AI can generate ad‑hoc SQL that a human might never have typed.
You really need production access that scopes, time‑bounds, and observes activity. You want the request to tie to an engineer’s identity, require approval for destructive statements, and inspect every response for sensitive fields. Yet, without a dedicated control point, the request still travels straight to BigQuery. The connection bypasses any policy engine, there is no real‑time masking, no command‑level approval, and no recorded session to replay for forensics.
Enter hoop.dev. It sits in the data path between Cursor and BigQuery, acting as an identity‑aware proxy that can enforce the missing controls. The gateway validates the caller’s OIDC token, maps group membership to a set of permissions, and then forwards the query only after applying the configured guardrails.
Implementing production access with hoop.dev
When a request arrives, hoop.dev first checks the user’s identity against the configured identity provider. This is the setup phase that decides who may start a session. The gateway then evaluates the request in the data path. If the SQL statement matches a policy that requires human approval, such as DROP TABLE or a massive DELETE, hoop.dev pauses the request and routes it to an approval workflow. Only after an authorized approver signs off does the query reach BigQuery.
For every response, hoop.dev can apply inline masking. hoop.dev redacts sensitive columns like SSN or credit‑card numbers before they ever return to the AI agent. This ensures that even if the agent tries to exfiltrate data, the payload is already sanitized.
hoop.dev logs each query, the identity that issued it, the approval decision, and the masked result. hoop.dev stores the logs outside the agent process, so the agent never sees the raw data or the audit trail. hoop.dev enables replay for any session, giving security teams a forensic window into what the AI actually did.
Why the data path matters
The enforcement outcomes, just‑in‑time approval, inline masking, session recording, exist only because hoop.dev occupies the gateway position. If you removed hoop.dev, the setup would still authenticate the user, but there would be no place to block a dangerous command, no place to redact a column, and no reliable record of the transaction. The gateway is therefore the only reliable point where policy can be applied consistently.
Deploying the solution
Deploying hoop.dev follows the standard quick‑start flow. You provision the gateway near your BigQuery endpoint, register the warehouse as a connection, and configure the OIDC provider that issues tokens for your engineers and CI pipelines. The agent runs inside your network, holds the service‑account credential that Cursor would otherwise need, and presents it only to the gateway after the policy checks have passed.
Once the gateway is live, Cursor continues to use its normal client libraries. You do not need to change any code in the AI workflow; the only difference is that the network traffic now passes through hoop.dev, where the controls enforce the policies.
Benefits for production environments
- Reduced blast radius: destructive statements need explicit approval.
- Continuous audit: every query is logged with identity and outcome.
- Data protection: sensitive fields are masked in real time.
- Compliance readiness: the recorded evidence can be used to satisfy SOC 2 and other audit requirements.
All of these advantages stem from placing enforcement in the data path, not from adjusting IAM policies alone.
Getting started
Follow the getting‑started guide to spin up the gateway and register your BigQuery connection. The documentation walks you through OIDC configuration, role mapping, and policy definition. For deeper insight into masking and audit capabilities, explore the learn section.
Explore the source code and contribute on GitHub: hoop.dev repository.
FAQ
How does hoop.dev prevent accidental data leaks?
hoop.dev inspects each response and redacts configured sensitive columns before they reach Cursor. The AI never sees the raw values, eliminating accidental exfiltration.
Can I keep using my existing Cursor workflow?
Yes. Cursor continues to connect with its standard client libraries. The only change is that network traffic is routed through the hoop.dev gateway, which applies the policies transparently.
What happens if an approval request is denied?
hoop.dev aborts the query and returns an error to the caller. No data is sent to BigQuery, and the denial is logged alongside the original request for audit purposes.
