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

An offboarded contractor still has a copy of the Cursor configuration file that contains a hard‑coded PostgreSQL user and password. The AI coding agent that runs inside the CI pipeline picks up those credentials and can run arbitrary queries against production tables, providing uncontrolled database access. No one sees a request log, no alert fires when a sensitive column is read, and the team has no way to revoke that access without rotating the entire database password.

This is the typical state of affairs in many on‑prem environments: a shared static credential is baked into the AI tool, the agent talks directly to the database, and the only control is the initial permission granted to the service account. The organization may have introduced an identity provider so that only known users can start a Cursor job, but the request still reaches the database unmediated, leaving the data path wide open.

What the team really needs is a way to keep the convenience of a single AI‑driven workflow while ensuring that every database access is checked, recorded, and, when appropriate, masked. The prerequisite is a trustworthy identity source – OIDC or SAML tokens that prove who is launching the job and what groups they belong to. That identity layer can tell the system *who* is asking, but it cannot enforce *what* the request is allowed to do, nor can it produce a complete audit trail.

Why database access matters for AI coding agents

AI agents like Cursor can generate code that reads or writes large volumes of data in seconds. A single mis‑generated query can expose customer PII, corrupt financial ledgers, or trigger a cascade of downstream failures. When the agent runs with a privileged database user, the blast radius expands dramatically. Controlling database access at the point where the query is issued, rather than relying on static passwords, reduces risk and satisfies audit requirements for many compliance frameworks.

What a minimal control model looks like

The first step is to bind each CI job or AI run to a non‑human identity that is issued by the corporate IdP. The identity token carries group membership that reflects the least‑privilege role the job should have – for example, read‑only access to the analytics schema. This setup decides *who* may start a Cursor session, but it does not stop the session from executing a destructive command, nor does it capture the exact statements that were run.

Without a gate in the data path, the request still travels straight from the Cursor process to the PostgreSQL endpoint. The database sees a valid user, executes the command, and returns the result. Operators see no inline masking and cannot insert human approval for high‑risk queries, and they cannot replay the session for later investigation.

Introducing an identity‑aware gateway

hoop.dev provides the missing data‑path enforcement layer. It sits between the Cursor AI agent and the PostgreSQL server, acting as a Layer 7 proxy that inspects each wire‑protocol message. Because hoop.dev is the only component that can see the traffic, it applies the full suite of controls required for safe database access.

When a Cursor job presents its OIDC token, hoop.dev validates the token against the corporate IdP, extracts the group claims, and maps them to a policy that defines which tables, columns, or SQL commands are permissible. If a query attempts to read a column marked as sensitive, hoop.dev masks the value in the response before it reaches the AI agent. If a statement matches a high‑risk pattern, hoop.dev pauses the request and routes it to a human approver, enforcing just‑in‑time approval.

hoop.dev records every interaction that passes through it. The gateway creates a session log that includes the identity of the requester, the exact SQL text, and the masked result set. Teams can replay those logs later for forensic analysis or compliance reporting. Because the credential to the database lives only inside hoop.dev, the AI agent never sees the password, eliminating credential leakage risk.

You can deploy this architecture straightforwardly. You can spin up the gateway and its network‑resident agent with a Docker‑Compose file in a few minutes. The agent runs alongside the PostgreSQL instance, and you change the Cursor configuration to point at the hoop.dev endpoint instead of the raw database host. Detailed steps are covered in the hoop.dev getting‑started guide and the broader hoop.dev feature documentation.

FAQ

Can hoop.dev enforce column‑level masking for all database engines?

hoop.dev can mask any field that appears in the response stream of a supported protocol. The policy defines which columns are sensitive, and the gateway replaces those values before they reach the AI agent.

What happens if an AI‑generated query is denied?

When a query triggers a policy rule that requires human approval, hoop.dev returns a prompt to the operator. The operator can approve, modify, or reject the request, and the decision is logged alongside the session.

How do you retain audit logs?

You can store the logs for audit and investigation, and you can export them to a storage backend for long‑term retention.

Ready to see the code in action? Explore the hoop.dev repository on GitHub to contribute, customize policies, and integrate with your existing CI pipelines.