A recently offboarded contractor’s CI pipeline still holds a hard‑coded Cursor API key that can spin up SQL against the production database. The key lives in a shared secret store, is used by an automated code‑generation agent, and anyone with repository access can trigger it. The result is a powerful AI coding assistant that can read or write production data without any human review, and the organization has no record of what queries were run.
Why production access matters for Cursor
Cursor’s AI model excels at turning natural‑language prompts into SQL statements. In a development sandbox that capability is a productivity win, but in production the same convenience becomes a risk. Teams often grant the agent a static service account that has full production access to PostgreSQL. The service account is created once, never rotated, and is used by every instance of the AI agent. Because the connection goes straight from the agent to the database, there is no audit trail, no ability to mask sensitive columns, and no gate to stop destructive commands.
What the current setup fixes – and what it still leaves open
Most organizations solve the first part of the problem by moving to non‑human identities. They create a dedicated service account for the AI agent, limit its role to the smallest set of tables, and store the credential in a vault. This satisfies the principle of least privilege and makes the credential lifecycle manageable.
However, the request still travels directly from the agent to PostgreSQL. The data path contains no enforcement point. Without a gateway, the following gaps remain:
- No real‑time approval workflow for risky queries.
- No command‑level audit that ties each statement to the originating user or CI job.
- No inline masking of columns that contain personally identifiable information.
- No session recording that can be replayed for forensic analysis.
These gaps are exactly what a production‑grade access control system must close.
hoop.dev as the data‑path enforcement layer
Enter hoop.dev. It is a Layer 7 gateway that sits between the identity provider and PostgreSQL. The agent authenticates to hoop.dev via OIDC (using the same IdP that issued the service‑account token). hoop.dev validates the token, extracts group membership, and then proxies the connection to the database.
Because the gateway owns the network‑resident agent that talks to PostgreSQL, every packet passes through hoop.dev. This is the only place where enforcement can happen. The platform provides four core outcomes that directly address the missing controls:
- hoop.dev records every query. Each statement is logged with the caller’s identity, timestamp, and result metadata, creating a complete audit trail.
- hoop.dev masks sensitive fields inline. When a SELECT returns columns marked as confidential, the gateway redacts or tokenises the data before it reaches the AI agent.
- hoop.dev routes high‑risk commands to a just‑in‑time approval workflow. A DELETE or ALTER statement triggers a human review step; the query is only forwarded after an approver signs off.
- hoop.dev records the full session for replay. The entire interaction – from authentication through each query and response – is stored for later forensic review.
All of these outcomes exist because hoop.dev is positioned in the data path; removing it would instantly eliminate the audit, masking, and approval capabilities.
Putting the pieces together
The recommended architecture looks like this: