Why PHI compliance matters for Cursor
An engineering team hands a newly hired contractor a Cursor workspace that contains patient notes used to fine‑tune a code‑generation model. The contractor runs the same prompts the team uses in production, unaware that the inputs include PHI.
Today most teams connect Cursor directly to their data lake or to a private API that returns raw medical records. The connection uses a static service account token stored in the repository, and no one records which queries were issued or which fields were returned.
Regulators expect a complete audit trail for any system that processes PHI: who accessed the data, what was asked, the exact response, and evidence that protected fields were never exposed to unauthorized actors.
Without a gateway, the request flows straight to the data source, bypassing any real‑time checks, masking, or approval workflow. The organization can see that a token existed, but it cannot prove that each query complied with PHI handling rules.
How hoop.dev enforces PHI policies for Cursor
To satisfy auditors, the control point must sit on the data path, be able to inspect every Cursor request, and enforce policies before the request reaches the backend.
hoop.dev provides exactly that layer. It acts as an identity‑aware proxy for Cursor, intercepting each LLM call at the protocol level. Because the gateway sits between the client and the data source, it can apply inline masking, require a just‑in‑time approval for sensitive queries, and record the full session.
The organization still defines who may start a Cursor session through OIDC or SAML identity providers. Those identities determine whether a request is allowed to begin, but they do not enforce any data‑level rule. hoop.dev is the only component that can enforce masking, block disallowed commands, and capture audit evidence.
hoop.dev records every Cursor interaction, timestamps the start and end of the session, and writes the transcript to a log for audit purposes. When a query includes a PHI field, hoop.dev can replace the value with a placeholder before it leaves the gateway, ensuring the downstream system never sees raw identifiers.
If a query exceeds a pre‑defined risk threshold, hoop.dev routes the request to an approver. The approver’s decision is logged alongside the session, and hoop.dev attaches the decision, timestamp, and reviewer identity to the session log, creating an audit‑logged chain of custody for each PHI‑related operation.
When you define a PHI policy in hoop.dev, you specify which fields are considered protected, the masking pattern to apply, and the risk score that triggers an approval step. Policies are versioned and stored centrally, so any change is instantly enforced across all Cursor sessions without redeploying the application.
Because hoop.dev sits at Layer 7, it can inspect the exact JSON payload that Cursor sends and receives. This fine‑grained visibility lets you audit not only the query text but also the structure of the response, a requirement for many health‑care regulations that demand field‑level tracking.
The approval workflow integrates with existing ticketing or chat tools. When a high‑risk query is detected, hoop.dev creates a request that an authorized reviewer can accept or reject. The decision, timestamp, and reviewer identity are attached to the session log, giving a documented chain of custody.
All logs are written by hoop.dev to a backend you control. hoop.dev does not prescribe a storage solution; you can point it at an S3 bucket, a PostgreSQL table, or any system that meets your retention and encryption requirements. This flexibility lets you align audit storage with your organization’s data‑governance policies.
Because the gateway holds the credentials for the downstream data source, engineers never see the secret keys. The agent that runs inside your network presents those credentials to the target only after hoop.dev has approved the request, dramatically reducing the attack surface for credential theft.
Operational workflow and audit evidence
Together these capabilities generate the evidence auditors demand for PHI compliance: a detailed record of who asked what, proof that protected fields were masked, and a documented approval trail for high‑risk accesses. Because the gateway holds the credentials, engineers never see the underlying keys, reducing credential leakage risk.
Running hoop.dev in high‑availability mode ensures that a single gateway failure does not interrupt Cursor workloads. Deploy multiple replicas behind a load balancer, and configure health checks so that sessions are automatically rerouted if a replica becomes unhealthy.
Getting started with hoop.dev
Deploying hoop.dev follows the standard quick‑start flow. The gateway runs as a Docker Compose service or in Kubernetes, registers the Cursor endpoint as a connection, and pulls identity information from your existing IdP. For detailed steps, see the getting‑started guide and the full source repository on GitHub. To learn more about masking, approvals, and audit logging, explore the learn section on the hoop.dev site.
FAQ
Do I need to modify my Cursor code to use hoop.dev?
No. You point the Cursor client at the hoop.dev endpoint and the gateway handles the rest, so your existing scripts and notebooks continue to work unchanged.
How does hoop.dev ensure that masked data cannot be recovered?
Masking happens inside the gateway before any response leaves the data path, and the original value never reaches the client, eliminating the chance of accidental exposure.
Can I retain the audit logs for the required retention period?
hoop.dev writes logs to a configurable backend such as object storage or a database, letting you apply any retention policy your compliance framework mandates.
