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

Common misconception: AI coding agents need unrestricted database access

Many teams assume that a large‑language‑model‑driven coding assistant such as Cursor can safely connect directly to a production database without any guardrails. The idea is that the model will only read what it needs and never write anything harmful. In practice, the model interacts with the database through standard client libraries, which means it inherits whatever permissions the underlying credential provides. If that credential is overly privileged, the agent can unintentionally expose sensitive rows, delete tables, or run expensive queries that affect service stability.

Why database access for AI agents must be controlled

Cursor runs as a pod inside a Kubernetes cluster and reaches the database using the same network path as a human developer. Without a dedicated enforcement layer, three problems emerge:

• Static, broad credentials. A service account key or password is often shared across many workloads, giving the AI agent the same level of access as any operator.
• No per‑request audit. When the model issues a query, the operation is logged only on the database side, making it hard to attribute the action to an AI‑driven request.
• Potential data leakage. Responses that contain personally identifiable information or secrets can be sent back to the model, which might store or expose them elsewhere.

These gaps violate the principle of least privilege and make it difficult to satisfy compliance requirements that demand fine‑grained control over who reads and writes data.

What a unified enforcement point looks like

The missing piece is a layer that sits on the network path between the Cursor pod and the database, capable of inspecting the wire‑protocol, applying policies, and generating evidence. This layer must be able to:

• Validate the caller’s identity via OIDC or SAML tokens.
• Grant just‑in‑time credentials that expire after the request completes.
• Mask sensitive fields in query results before they reach the model.
• Require human approval for risky commands such as DROP TABLE or bulk updates.
• Record the entire session for replay and audit.

All of these controls need to be enforced at the same point where the traffic passes, otherwise an attacker could bypass one check by targeting a different component.

hoop.dev provides the data‑path enforcement

hoop.dev is a layer‑7 gateway that sits between identities and infrastructure. It verifies the OIDC/SAML token presented by the Cursor pod, extracts group membership, and then decides whether to allow the connection. The gateway runs alongside a lightweight agent inside the same Kubernetes cluster, so the database credentials never leave the controlled environment.

Because hoop.dev is the only component that sees the actual database protocol, it can apply the policies listed above. It masks sensitive columns in result sets, blocks commands that match a denylist, and can pause a request for a manual approval step before it reaches the backend. Every interaction is recorded, enabling replay and forensic analysis.

How the architecture works for Cursor on Kubernetes

1. Deploy the hoop.dev gateway using the standard Docker‑Compose or Helm chart. The deployment includes the network‑resident agent that has direct network access to the target database.
2. Register the PostgreSQL (or MySQL, etc.) instance as a connection in hoop.dev, supplying the credential that the gateway will use. The credential is stored only inside the gateway.
3. Configure Cursor to invoke the hoop.dev CLI (or use the built‑in MCP server) instead of connecting directly to the database. From the model’s perspective this is just another client library.
4. When the Cursor pod initiates a connection, hoop.dev validates the pod’s OIDC token, checks the policy, and then proxies the traffic to the database.
5. During the session, hoop.dev applies inline masking, enforces command‑level blocks, and, if configured, routes high‑risk statements to an approver.
6. The entire session is logged and can be replayed from the hoop.dev UI or API.

Benefits of putting the enforcement in the data path

Because hoop.dev is the sole gatekeeper, the following outcomes are guaranteed:

• Fine‑grained audit. Each query is tied to the originating OIDC identity, so you know exactly which AI request performed a read or write.
• Just‑in‑time credentials. The gateway issues short‑lived tokens that disappear when the session ends, reducing the risk of credential leakage.
• Inline data masking. Sensitive columns such as credit‑card numbers are redacted before they ever reach the model.
• Command‑level blocking and approval. Dangerous statements are either rejected automatically or sent to a human reviewer.
• Session replay. Full packet‑level recordings let you reconstruct exactly what the model saw and sent.

These controls collectively shrink the blast radius of a compromised AI agent and provide the evidence needed for audits.

Getting started

To try this in your environment, follow the getting‑started guide for a quick deployment on Kubernetes. The documentation walks you through registering a database connection, configuring OIDC, and enabling masking and approval policies. For a deeper dive into policy configuration and audit features, see the learn section. All source code and deployment manifests are available in the public repository.

FAQ

Q: Does hoop.dev store my database passwords?
A: No. The gateway holds the credential only in memory and never exposes it to the calling pod or the AI model.

Q: Can I see who approved a blocked command?
A: Yes. hoop.dev records the approver’s identity, the timestamp, and the exact command that was approved or denied.

Q: Will masking affect application performance?
A: Masking is performed inline at the protocol layer and adds only minimal latency compared to a direct connection.

Ready to secure your AI‑driven database workloads? Explore the open‑source repository on GitHub and start building a controlled database access pipeline for Cursor today.