Start from the requirement, not the tool. If an AI coding agent inside Cursor is going to touch a production database, the control that governs that touch has to live outside the agent. The agent can be asked to behave; it cannot be trusted to police itself. So the first design decision is architectural: production access for the agent must pass through a boundary the agent does not own and cannot reconfigure.
That boundary is a connection, not a permission inside Cursor. Cursor still drives the work. The thing that changes is the path between the agent and the Postgres, MySQL, or internal service it reaches. That path becomes a governed connection, and the controls attach to it rather than to the agent.
Why production access has to sit outside the agent
An agent that writes and runs code will, given a live credential, eventually run something against production that nobody approved. The failure is not malice. It is that the credential exists at all, standing and broad, inside a process that improvises. The agent does not know which table is load-bearing or which query is expensive. It only knows it has a connection string and a task to finish.
The fix is to remove standing access. The agent gets no long-lived database password. It connects through an identity-aware proxy that grants access just in time, for the specific connection, and revokes it when the session ends. The blast radius of a bad query shrinks from "everything the credential could reach, forever" to one scoped, recorded session.
This is the part teams get backward. They try to make the agent safer by writing more careful prompts. The durable answer is to make the connection safer, so the agent's behavior matters less and a single bad decision cannot cascade.
How production access works through hoop.dev
hoop.dev is an open-source Layer 7 access gateway. A small agent runs near your database and opens an outbound connection to the gateway. The Cursor-side agent reaches the database through that gateway, and four things happen on the way:
- The connection is authorized against the identity the agent authenticates as, not a shared secret baked into a config file.
- Access is granted just in time and scoped to one connection, so there is no standing production credential to leak.
- Every command is recorded at the gateway, outside the agent process, tied to that identity.
- Sensitive fields in returned rows are masked inline before they reach the agent.
hoop.dev does not read the agent's prompts or its model output. It governs the database actions the agent takes, which is the part that can drop a table or read a customer's PII. The model can think whatever it likes; the connection decides what actually runs. You can see this model laid out on the hoop.dev site.
A minimal setup
- Run the hoop.dev agent next to the production Postgres instance.
- Register the database as a connection, with the credential held on the connection, never in Cursor.
- Map the agent's identity to a role scoped to exactly what the task needs: read-only on most tables, no DDL.
- Require approval for any write, so a risky operation pauses for a human instead of executing.
A read query returns immediately, masked. A DELETE on a production table routes for approval and waits. The agent keeps moving on safe work and stops at the boundary on dangerous work. One model ends access on disconnect and hopes the agent behaved. The other checks every command. Production access for an agent should be the second.
Pitfalls to avoid
Do not hand Cursor a .env with a production connection string. That is standing access by another name, and it bypasses every control you just built. Do not rely on the agent to self-limit to read-only; enforce it at the connection. And do not assume a code-level audit log is enough. A log the agent's process can write is a log it can be coaxed to skip. The record has to live where the agent cannot reach it.
FAQ
Does hoop.dev run inside Cursor?
No. hoop.dev governs the database connection the agent uses. It does not install into Cursor, proxy the editor, or inspect the model.
How is this different from a read replica?
A replica limits what data exists. It does not record who ran what, mask fields per identity, or pause writes for approval. Production access is about the control surface on the connection, not a copy of the data.
Is hoop.dev open source?
Yes, it is MIT licensed. You can read exactly how the gateway enforces access before you trust it with production.
Scope an agent's production access end to end by running it through the gateway. Clone the repo and stand up your first connection at the hoop.dev GitHub repository, then follow the getting started guide to register a database and set a just-in-time policy.
