How can you prove that every Cursor query respects gdpr when the data lives in your own environment?
Most teams hand developers a static database user, embed the password in CI pipelines, and let the application talk directly to the Cursor instance. The connection is open‑ended, the credential never changes, and there is no central point that can see which rows are read or written. When a data‑subject request arrives, the audit trail is either missing or scattered across log files that are difficult to correlate. In practice, compliance officers end up asking for a manual export of query logs, a copy of the credential rotation schedule, and a promise that no personal data was exposed.
This is the real, unsanitized starting state: a shared credential, standing access, and no reliable evidence that gdpr‑relevant operations were observed.
gdpr requirements for Cursor workloads
gdpr expects three technical guarantees for any personal data processor:
- Ability to demonstrate who accessed which data and when.
- Mechanisms to prevent unauthorized fields from being returned.
- Just‑in‑time approvals for high‑risk queries that could impact data subjects.
Many organizations already adopt non‑human identities, role‑based access control, and secret‑management tools. Those measures decide who may start a connection, but they do not give you visibility into the actual commands that cross the wire. The request still reaches the Cursor server directly, without any audit, masking, or approval step. In other words, the precondition fixes identity but leaves the enforcement gap wide open.
Why the data path must host enforcement
The only place you can reliably apply gdpr controls is on the traffic that flows between the caller and the Cursor instance. If the gateway sits in the data path, it can inspect each SQL statement, apply field‑level redaction, enforce a policy that requires a manager’s sign‑off for SELECTs that include sensitive columns, and record the entire session for later replay. Anything that happens downstream of the gateway is invisible to auditors, and anything that happens upstream can be bypassed by a compromised client.
That is why the architecture must separate three concerns:
- Setup: Identity providers, OIDC tokens, and least‑privilege roles decide who may initiate a Cursor connection.
- The data path: A Layer 7 gateway intercepts every protocol message before it reaches the database.
- Enforcement outcomes: The gateway records each session, masks personal fields, blocks disallowed statements, and routes risky queries to an approval workflow.
Only the gateway can guarantee that the gdpr evidence is complete and tamper‑evident because it never relies on the client to generate logs.
hoop.dev as the gdpr‑focused gateway
hoop.dev fulfills the data‑path requirement. It runs a network‑resident agent next to the Cursor server and proxies every client connection. When a user presents an OIDC token, hoop.dev validates the identity, maps group membership to a policy, and then decides whether the request may proceed.
From that point onward, hoop.dev becomes the active enforcement point. It records each query and its result, stores the log for later audit, and makes the record searchable for audit requests. If a SELECT statement asks for a column that is marked as personal data, hoop.dev masks the value in real time before it reaches the client. For queries that exceed a risk threshold, such as bulk exports of user tables, hoop.dev pauses execution and routes the request to a human approver. Once approval is granted, the query resumes; otherwise it is rejected and the attempt is logged.
Because hoop.dev sits in the data path, the enforcement outcomes exist only because the gateway is present. Remove hoop.dev and the masking, approval, and session recording disappear, leaving the original unsanitized state.
Continuous gdpr evidence
gdpr audits require evidence that is continuously accrued, not a snapshot produced at quarter‑end. hoop.dev generates that evidence automatically:
- Every session is captured with timestamps, user identity, and the exact SQL payload.
- Inline masking ensures that any personal data that leaves the database is already redacted, satisfying the data‑minimisation principle.
- Just‑in‑time approvals create a chain of custody for high‑risk operations, proving that a responsible party reviewed the request.
- All logs are stored outside the Cursor process, so they cannot be altered by a compromised database user.
When an auditor asks for proof of compliance, you can export the session archive, filter by the data‑subject identifier, and demonstrate that every access was either masked or approved. The evidence is tied to the identity that originated the request, which satisfies gdpr’s accountability requirement.
Getting started
To adopt this model, start with the getting‑started guide. It walks you through deploying hoop.dev with Docker Compose, configuring OIDC authentication, and registering a Cursor connection. The learn section provides deeper coverage of masking policies, approval workflows, and audit‑log retention. All of the heavy lifting, credential storage, session replay, and policy evaluation, lives inside hoop.dev, letting you focus on defining the right gdpr rules rather than building a custom audit pipeline.
FAQ
Does hoop.dev replace the need for database‑level audit logging?
No. hoop.dev complements native logs by capturing the exact request and response at the protocol layer. It adds masking and approval that most database engines cannot provide out of the box.
Can I use hoop.dev with existing Cursor users without changing their client code?
Yes. Clients continue to use their standard Cursor driver or CLI; hoop.dev acts as a transparent proxy, so no code changes are required.
How long are the session records retained?
Retention is configurable in the deployment configuration. The default aligns with common gdpr‑related retention periods, but you can adjust it to meet your organization’s policy.
Explore the source code on GitHub to see how the gateway is built and to contribute enhancements.
