Many assume that AI coding assistants automatically generate audit trails when they run queries against a database, but the reality is far different. In practice, a Cursor‑driven AI agent often talks directly to PostgreSQL using a shared service account, and the connection leaves no per‑user trace. The result is a blind spot: security teams cannot tell which engineer prompted the agent, which statements were generated, or whether sensitive rows were exposed.
Teams typically try to solve the visibility problem by adding an identity check before the AI request reaches the database. An OIDC token proves who is asking the AI to run a query, and the token maps to a role that can open a session. This step limits who can start a Cursor job, but the request still flows straight to PostgreSQL. No gateway sits between the token and the database, so there is no place to record the exact SQL statements, no way to mask returned credit‑card numbers, and no opportunity to pause a dangerous command for human review.
Because the enforcement point is missing, the audit trail remains incomplete. Even if the AI model is trained to obey policy, a rogue prompt can cause it to issue a DELETE or expose PII, and the organization would have no reliable log to investigate. The missing control surface also makes compliance reporting painful, as auditors expect per‑session evidence that ties an action back to an individual identity.
Why a dedicated data‑path gateway is required
To close the gap, the access control layer must sit on the data path, not just in the authentication front‑end. The gateway becomes the only place where traffic can be inspected, altered, or recorded before it reaches PostgreSQL. By placing a proxy at Layer 7, every Cursor request is forced through a single, policy‑enforced choke point.
This architecture satisfies three distinct responsibilities:
- Setup: Identity providers (Okta, Azure AD, Google Workspace, etc.) issue OIDC tokens that identify the engineer or service account. The token proves who is asking the AI to run a query, but it does not enforce what the query can do.
- The data path: The gateway intercepts the PostgreSQL wire protocol, allowing it to apply rules, mask fields, or require an approval before a statement is forwarded.
- Enforcement outcomes: Because the gateway sits in the data path, it generates audit trails, blocks unsafe commands, and records session replay data for later analysis.
Introducing hoop.dev as the enforcement point
hoop.dev sits exactly where the data path must exist. It runs a network‑resident agent next to the PostgreSQL instance and proxies every Cursor connection. When an engineer triggers a Cursor job, the request first validates against the OIDC token, then hands off to hoop.dev. From that moment onward hoop.dev controls the session.
hoop.dev records each SQL statement, the originating identity, and the time of execution, creating a reliable audit trail that can be replayed whenever needed. If a statement matches a policy that requires human sign‑off, such as a DROP TABLE or a query that returns columns marked as sensitive, hoop.dev pauses the flow and routes the request to an approval workflow. Only after an authorized reviewer approves does the statement continue to PostgreSQL.