Putting access controls around Cursor: database access for AI coding agents (on GCP)

Why AI‑driven code assistants need tighter database access

When a development team hands a Cursor instance to an external contractor, the contractor’s AI‑augmented IDE can issue SQL statements on the team’s production database without any human in the loop. The contractor’s token is often a long‑lived service account that has read‑write rights across every schema. No audit trail records which query the AI generated, and any accidental data leak is invisible until it surfaces in downstream systems.

This pattern repeats when CI pipelines embed Cursor to generate migration scripts. The pipeline runs under a generic CI service account that can query and modify the entire database. Because the connection bypasses any approval step, a malformed suggestion can corrupt tables, and the incident is hard to attribute because the pipeline logs only show the CI job ID, not the exact statements the AI produced.

Even when organizations move to short‑lived OIDC tokens for each build, the token still grants the same broad privileges, and the request travels directly to the database. The request reaches the target, but there is no real‑time visibility, no ability to mask sensitive columns, and no way to pause a dangerous query for human review.

What a strong database access model looks like for Cursor

A sound model separates three concerns:

• Setup: Identity providers (Okta, Azure AD, Google Workspace) issue short‑lived OIDC tokens that identify the calling entity – a CI job, a developer, or an AI agent.
• The data path: The actual network hop where the request is inspected, approved, masked, or blocked. This hop must sit between the identity source and the database.
• Enforcement outcomes: Session recording, column‑level masking, just‑in‑time approval, and command‑level audit. These outcomes only appear when the data path can intervene.

In practice, the data path becomes the single place where policy is enforced. Without it, the token alone cannot guarantee that a query complies with governance rules, because the token merely proves who is calling, not what they are allowed to do at the command level.

How hoop.dev places the enforcement point for Cursor

hoop.dev acts as a Layer 7 gateway that proxies the Cursor connection to the underlying database. The gateway runs an agent inside the same VPC as the database, so the actual traffic never leaves the trusted network. When an AI‑augmented session starts, the user’s OIDC token is presented to hoop.dev, which validates the token and extracts group membership. The token itself never reaches the database.

From that point forward, hoop.dev becomes the only component that can:

• Record every SQL statement and its result for later replay.
• Mask sensitive columns (for example, credit‑card numbers) before they are returned to the AI agent.
• Require a human approver to sign off on statements that match a risk profile, such as DROP or ALTER commands.
• Block queries that contain disallowed patterns, preventing accidental data loss.

Because hoop.dev sits in the data path, all enforcement outcomes are guaranteed to happen regardless of how the token was obtained. If the gateway were removed, none of those outcomes would exist – the database would see the raw request and execute it unchecked.

Implementing the model on GCP

Start by provisioning a GCP Compute Engine instance or a GKE pod that runs the hoop.dev gateway. The official getting‑started guide walks you through the Docker Compose or Helm deployment options. During registration, declare the target as a PostgreSQL connection (or the appropriate database type) and supply the service credential that the gateway will use internally. The credential never leaves the gateway, so the AI agent never handles secrets.

Configure your OIDC provider (Google Workspace, Okta, etc.) as the identity source for hoop.dev. The provider issues short‑lived tokens for each Cursor session. hoop.dev validates those tokens on every request, maps the caller’s groups to a policy, and then applies the enforcement rules described above.

When a Cursor‑driven query reaches the gateway, hoop.dev checks the policy. If the query matches a “high‑risk” pattern, the request is queued for manual approval. An authorized reviewer receives a notification, approves or rejects, and the gateway either forwards the query or returns an error. All actions are logged and stored for audit purposes.

Benefits of the gateway approach

Because hoop.dev is the sole enforcement point, you gain:

• Complete auditability: Every statement is captured, enabling forensic analysis after an incident.
• Real‑time data protection: Sensitive fields are masked before they ever reach the AI, reducing exposure risk.
• Just‑in‑time access: Permissions are granted per session, not via static service accounts, limiting the blast radius of a compromised token.
• Human oversight for dangerous actions: Approvals add a policy‑driven checkpoint for destructive commands.

These outcomes exist only because hoop.dev sits in the data path. The same OIDC token, if sent directly to the database, would provide none of these safeguards.

Next steps

Review the feature documentation to understand the policy language you can use for masking and approval rules. When you are ready to try it out, clone the open‑source repository and follow the quick‑start instructions.

View the source and contribute on GitHub.

FAQ

Does hoop.dev store database credentials?
The gateway holds the credential only in memory for the duration of a session. It never exposes the secret to the AI agent or the end user.

Can I apply different policies per team?
Yes. Policies are driven by group membership extracted from the OIDC token, allowing you to tailor masking, approval, and blocking rules per organizational unit.

What happens if the gateway goes down?
Connections are terminated, preventing any unaudited access. You can configure high‑availability deployments to avoid downtime.