Putting access controls around Cursor: guardrails for AI coding agents (on BigQuery)

Why guardrails matter for AI coding agents

Every unchecked query generated by an AI coding assistant can silently exfiltrate data, trigger costly scans, or alter production tables, driving up cloud spend and exposing compliance risk. When a developer lets Cursor run against a BigQuery warehouse without any runtime checks, the organization loses visibility into who asked what, when, and whether the request aligns with policy.

Current practice without a gateway

Most teams hand a service account key to Cursor, store it in a CI secret store, and point the agent at the BigQuery endpoint. The AI can then issue SELECT, INSERT, or DELETE statements on behalf of any user that invoked it. Because the request travels directly from the agent to the database, there is no central point where the query can be inspected, approved, or redacted. Auditors see only the final state of the tables, not the series of AI‑generated commands that produced it. The result is a blind spot that makes it impossible to enforce least‑privilege, prevent accidental data leakage, or capture a replayable audit trail.

The missing control point

What teams really need is a place where every request from Cursor can be examined before it reaches BigQuery. The ideal solution would still let the AI agent initiate the connection, but it would stop the query from executing unless it satisfies policy, would mask any PII in the response, and would record a replayable audit trail. At present, the request still reaches the target directly, with no audit, no inline masking, and no approval workflow.

Introducing hoop.dev as the enforcement layer

hoop.dev provides a layer‑7 gateway that sits between Cursor’s AI runtime and the BigQuery service. By deploying the gateway inside the same network as the data warehouse, every query passes through a single, controllable data path. hoop.dev validates the user’s OIDC token, extracts group membership, and then applies guardrails before forwarding the request.

How hoop.dev enforces guardrails for Cursor

When an AI‑generated query arrives, hoop.dev checks it against a policy that can block dangerous commands such as DROP TABLE or ALTER DATABASE. If the query matches a risk pattern, hoop.dev rejects it and returns a clear error to the agent, preventing accidental schema changes.

For queries that are allowed but contain potentially sensitive result columns, hoop.dev masks those fields in real time. The masking happens at the protocol layer, so the AI never sees raw PII, and downstream consumers only receive the sanitized view.

Before any high‑impact operation is executed, hoop.dev can trigger a just‑in‑time approval workflow. A designated reviewer receives a concise summary of the pending query and must approve it before the gateway forwards the request to BigQuery.

Every session that passes through the gateway is recorded. hoop.dev stores a replayable log that includes the original query, the decision taken by the guardrail engine, and the masked response. This log satisfies audit requirements and gives security teams a complete forensic trail.

Because hoop.dev holds the credential used to talk to BigQuery, the AI agent never sees the service account key. The gateway acts as a credential broker, ensuring that the secret stays inside the controlled environment.

Next steps

Start by reviewing the getting‑started guide to deploy the gateway in your environment. The learn section contains detailed information on defining guardrail policies, configuring inline masking, and setting up approval workflows for AI agents like Cursor.

When you are ready to explore the implementation, clone the hoop.dev repository on GitHub. The open‑source code lets you customize the policy engine to match your organization’s risk tolerance.

FAQ

Can hoop.dev block queries that modify schema?

Yes. hoop.dev evaluates each incoming statement against a rule set. If a statement matches a prohibited pattern such as DROP, ALTER, or CREATE, the gateway rejects it before it reaches BigQuery.

How does masking work for result sets?

hoop.dev inspects the response payload and replaces values in columns marked as sensitive with a placeholder. The masking occurs in the data path, so the original data never leaves the gateway.

Is there a way to see who approved a high‑risk query?

Every approval event is recorded in the session log. The log includes the reviewer’s identity, the timestamp of the approval, and the exact query that was authorized.