Giving an AI coding agent unrestricted database access is a recipe for data leaks.
Today many teams let Cursor, the Claude‑based coding assistant, connect directly to a PostgreSQL instance using a shared service account. The credential lives in a CI secret store, is checked into multiple pipelines, and is often granted broad read‑write privileges. Because the connection bypasses any central policy engine, every query runs with full rights, and no one knows which statements the agent issued or which rows it returned. The result is a blind spot: a powerful AI can read or modify production data without any audit trail, and any accidental query that touches sensitive columns goes unnoticed.
What teams really need is a way to enforce database access rules for Cursor without breaking the developer workflow. The ideal guardrail would let the agent request a connection, evaluate the request against the principle of least privilege, and, if needed, require a human to approve risky statements. At the same time the system should hide personally identifiable information in query results, block destructive commands, and keep a replayable record of every session. Importantly, these controls must sit on the data path – the point where the request actually reaches PostgreSQL – because any enforcement placed only in the identity layer or in the CI pipeline can be bypassed by a compromised secret.
Even with strong identity management – OIDC tokens, scoped service accounts, and strict IAM policies – the request still travels straight to the database engine. The token proves who is asking, but it does not inspect the SQL payload, does not mask returned rows, and does not capture the session for later review. In other words, the precondition of having a trusted identity is satisfied, yet the core security problem of uncontrolled database access remains unsolved.
Why the data path matters for Cursor
When an AI agent talks to PostgreSQL, the only place it can be observed in real time is the network hop that carries the wire‑protocol. By inserting a Layer 7 gateway at that hop, you gain visibility into each statement, the ability to rewrite results, and the authority to stop a command before the database executes it. This is the only reliable way to enforce fine‑grained policies such as:
- Allowing SELECT on public tables while denying INSERT, UPDATE, or DELETE on sensitive schemas.
- Masking credit‑card numbers or social‑security numbers in query results.
- Routing any DROP or ALTER statements to a manual approval workflow.
- Recording the full request/response exchange for forensic replay.
All of these controls require the gateway to sit between the Cursor client and the PostgreSQL server. The gateway becomes the enforcement point, while the identity system simply tells the gateway who is making the request.
How hoop.dev implements the enforcement point
hoop.dev provides exactly that Layer 7 gateway. It runs a network‑resident agent inside the same VPC or subnet as the PostgreSQL instance. Users – whether a human developer or an autonomous Cursor session – authenticate to hoop.dev via OIDC or SAML. The gateway validates the token, extracts group membership, and then decides whether the request may proceed, whether it needs approval, or whether it should be masked.
Because hoop.dev sits on the data path, it can:
- Inspect every SQL statement before it reaches PostgreSQL.
- Apply inline masking rules to column values in the response stream.
- Pause execution of high‑risk commands and trigger a just‑in‑time approval workflow.
- Record the entire session, including timestamps, user identity, and the exact payload, for later replay.
All of these outcomes are possible only because hoop.dev is the proxy that the Cursor client talks to instead of the database directly. The gateway holds the actual database credential, so the AI does not obtain the database credential or IAM key. This eliminates credential sprawl and ensures that every connection is mediated.
Putting it together for Cursor
To protect database access for Cursor on PostgreSQL, follow these high‑level steps:
- Deploy the hoop.dev gateway in the same network segment as the PostgreSQL server. The quick‑start Docker Compose file gets you up and running with OIDC authentication, masking, and guardrails enabled out of the box.
- Register the PostgreSQL instance as a connection in hoop.dev, supplying the host, port, and a service‑level credential that the gateway will use.
- Define a policy package that describes which SQL verbs are allowed for the Cursor service account, which columns must be masked, and which statements require manual approval.
- Configure Cursor (or the tool that launches Cursor) to point its database URL at the hoop.dev endpoint instead of the raw PostgreSQL address. From the agent’s perspective nothing changes – it still uses standard PostgreSQL client libraries.
- Test the flow: run a benign SELECT and verify that the result is masked as expected; then attempt a DROP TABLE and watch the approval request appear in your workflow system.
All of the heavy lifting – the policy evaluation, the masking engine, the approval UI, and the session recorder – lives inside hoop.dev. Your team only needs to maintain the identity provider and the policy definitions.
Common pitfalls to avoid
- Storing the database password in the AI’s environment. The credential should be stored only in hoop.dev’s connection definition; the AI never receives it.
- Relying solely on IAM scopes. IAM can limit which databases the AI may reach, but it cannot inspect the SQL payload. Without a data‑path gateway you lose the ability to mask or approve.
- Skipping the approval workflow for destructive commands. If you allow DROP or ALTER without a human check, you re‑introduce the same risk you tried to eliminate.
- Neglecting session replay. Auditors and incident responders need a complete record; make sure the recording feature is enabled in hoop.dev.
Next steps
Start with the getting started guide to spin up the gateway and register a PostgreSQL connection. Then explore the feature documentation for detailed policy syntax, masking rules, and approval workflow integration. The open‑source repository at github.com/hoophq/hoop contains the full source and example configurations.
FAQ
Does hoop.dev replace the need for IAM roles on the database?
No. IAM or database‑level roles still define the baseline trust boundary. hoop.dev adds a layer of runtime enforcement that inspects each query, masks data, and records the session.
Can I use hoop.dev with other AI coding assistants?
Yes. Any client that speaks the PostgreSQL wire protocol can be proxied through hoop.dev, including other LLM‑backed coding tools.
How does hoop.dev ensure that the AI never sees the raw credential?
The gateway stores the credential internally and authenticates to PostgreSQL on behalf of the client. The client only presents its OIDC token to hoop.dev, never the database secret.
