Putting access controls around Cursor: production access for AI coding agents (on Azure)

What a secure AI‑assisted deployment looks like

When an AI coding assistant like Cursor attempts production access, every change is traceable, approved, and never leaks secrets. Engineers see a clear audit trail, approvals happen just before the write, and any sensitive data is masked in responses. The result is confidence that AI‑generated code can be deployed without expanding the attack surface.

Current reality for many teams

In practice, teams often hand a static credential to Cursor so it can reach a production database on Azure. That credential typically has full read and write rights, and it is stored in a configuration file that developers and CI pipelines can access. Because the connection goes straight from the agent to the database, there is no central point that can observe which statements are executed, no way to require a human approval before a destructive command, and no mechanism to hide credit‑card numbers or API keys that might appear in query results. The lack of visibility makes it hard to answer questions such as “who ran this UPDATE?” or “did the AI expose a secret?”.

The missing piece in the control chain

What we need is a way to keep the convenience of AI‑driven code while adding a guardrail that enforces production access policies. The guardrail must sit on the request path so that every query passes through it, but the guardrail itself does not replace the identity system that decides who can start a session. In other words, the identity provider (Azure AD, Okta, etc.) still authenticates the user or service account, and the policy engine still decides whether a request is allowed to begin. What remains open after this step is that the request still travels directly to the database, with no audit, no masking, and no opportunity for a just‑in‑time approval.

Introducing hoop.dev as the data‑path enforcement layer

hoop.dev is a Layer 7 gateway that sits between the AI agent and the production database. It proxies the connection, inspects the wire‑protocol, and applies policy decisions in real time. Because the gateway is the only place the traffic can flow, hoop.dev can enforce every production access requirement without relying on the database itself.

Setup: identity and least‑privilege grants

First, configure Azure AD (or another OIDC provider) as the source of identity. Each AI‑driven session receives a short‑lived token that conveys the user’s group membership. The token is presented to hoop.dev, which validates it before any traffic is allowed. The token does not carry any database credentials; those remain stored securely inside the gateway.

The data path: where enforcement happens

All Cursor traffic is routed through hoop.dev’s gateway. The gateway terminates the client connection, then opens a separate connection to the target PostgreSQL instance on Azure. Because the gateway controls both ends of the flow, it can read every statement, examine every result, and intervene when necessary.

Enforcement outcomes delivered by hoop.dev

• hoop.dev records each session, preserving a replayable audit trail that shows exactly which statements the AI issued and what responses were returned.
• hoop.dev masks sensitive fields in query results, ensuring that credit‑card numbers, tokens, or personal data never leave the gateway in clear text.
• hoop.dev requires just‑in‑time approval for any command that matches a high‑risk pattern, such as DROP, ALTER, or mass UPDATE statements. The request is held until a designated approver grants permission.
• hoop.dev blocks commands that violate a deny list, preventing accidental or malicious schema changes.
• hoop.dev never exposes the underlying database credential to the AI agent; the credential stays inside the gateway.

Putting the pieces together

With identity handled by Azure AD, hoop.dev becomes the single enforcement point for every production access request. The AI agent authenticates, receives a short‑lived token, and then talks to hoop.dev instead of the database. hoop.dev validates the token, checks the request against policy, optionally pauses for human approval, masks any sensitive data in the response, and finally forwards the allowed command to the database. After execution, the gateway streams the result back to the agent, applying any masking rules on the way. The entire interaction is logged and can be replayed for forensic analysis.

Getting started

To try this pattern, follow the Getting started guide. The documentation walks you through deploying the gateway, configuring Azure AD as an OIDC source, registering a PostgreSQL connection, and enabling just‑in‑time approvals and masking. All of the heavy lifting is handled by hoop.dev, so you can focus on defining the policies that matter for your production environment.

Further reading

The Learn section provides deeper insight into how masking, approval workflows, and session recording are implemented. It also explains best practices for designing policy rules that protect production data without slowing down the AI development cycle.

FAQ

What if Cursor only needs read‑only access to production?

hoop.dev can enforce read‑only policies by allowing SELECT statements while requiring approval for any write operation. The same audit and masking capabilities apply, giving you visibility into every read request.

Can I revoke an AI‑generated session instantly?

Because the gateway controls the live connection, hoop.dev can terminate a session at any time. Revocation is immediate and does not rely on the underlying database to enforce it.

Does hoop.dev store database credentials?

hoop.dev stores the credentials needed to reach the target inside the gateway process. The credentials never leave the gateway, and they are never exposed to the AI agent or to end users.

Ready to protect your production workloads while still letting Cursor accelerate development? Visit the repository on GitHub to explore the source code and contribute.