Is Cursor HIPAA Compliant in 2026? BAA, Privacy Mode & PHI Setup

Yes, on the Enterprise plan as of 2026, once you have signed the BAA. The catch is that compliance depends on how you set things up, not just on the agreement existing.

A BAA alone does not make every workflow PHI-safe. Cursor is clear that only designated eligible services and models are covered. Third-party integrations and MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers are not automatically included.

"Eligible services and models" is the phrase that decides your rollout, and it does more work than it looks like it does. The BAA covers a named subset of Cursor surfaces and a named subset of models, both defined in the HIPAA Implementation and Configuration Guide that ships with the agreement. Unless an admin has restricted the model list, nothing in the product stops a developer from selecting a model that is not on it. The usage just falls outside the agreement, and you find out during an audit, months after it happened.

Enforcement, then, lands on the model allowlist. Enterprise admins can allow or block at the provider level or per individual model, and there is a setting to block new providers and model versions by default so each new release needs explicit approval before anyone can reach it. For a covered entity the default-open posture is the problem. Providers ship models faster than most compliance review cycles run, so a model nobody has assessed becomes available to your team the week it launches.

Treat the setup as a gate: nothing involving PHI starts until each step is done. Sign the BAA first, since it defines which services and models are in scope; lock Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. org-wide before anyone can opt out.

1. 1Sign the Enterprise agreement and BAA.
2. 2Review Cursor's HIPAA guidance via the Trust Center.
3. 3Enforce and lock Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. org-wide so no member can disable it.
4. 4Restrict work to the eligible services and models listed in Cursor's HIPAA guidance.
5. 5Keep PHI out of prompts where possible; prefer synthetic/de-identified data in dev.

Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. deserves a second look at step three. On Enterprise it is already on by default, so the instruction to turn it on reads as done when an admin checks the dashboard. The work is the org-wide lock that stops an individual member disabling it, and that is a separate setting from the mode itself. Verify the lock, then move on.

HIPAA applies to dev tools, not just production. PHI sneaks in through test data, fixtures, logs, code comments and debugging prompts. De-identify test data, scrub PHI from comments and logs and treat any prompt as something a third party could process.

• Use synthetic or de-identified datasets in development.
• Never paste real patient records into a prompt.
• Add PHI-adjacent paths to .cursorignore (best-effort, not a guarantee).

The mechanism that catches teams out is the index, because it starts on its own. Open a workspace and Cursor chunks the files and computes an embedding per chunk, with filenames obfuscated and file paths encrypted before they are sent. The source text sits in memory while the index is built and is then discarded, and the embeddings expire after six weeks of inactivity. A PHI-carrying fixture in a repo somebody opened once therefore has an embedding in a vector store for the next six weeks. Cursor's position is that embeddings cannot be reversed into the original text, and I would still rather not explain that distinction to a privacy officer mid-incident.

.cursorignore has to be in place before that first open. Put it in the repo template.

"Use synthetic data" is right for feature work. During an incident it is not advice at all, because the record that broke is the whole point of the investigation. The narrower rule I would write is to de-identify at the boundary instead of in the dataset. Work from field names, the failing code path and a de-identified repro, and keep the record out of the thread even when the agent would obviously get there faster with it. That costs real time on the first pass. Put the cost in the incident runbook so nobody is deciding it at 2am.

All of them, until you assess them yourself. Cursor's BAA covers Cursor's own services. Third-party integrations and MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers you connect are not automatically included, so an MCP server pointed at an EHR sandbox or a ticketing queue moves PHI into a system your Cursor agreement says nothing about.

This is the boundary healthcare rollouts cross without noticing, mostly because MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. is the piece developers wire up themselves and not something an admin provisions for them. Enterprise admins can allowlist which MCP servers members may use, then gate the individual tools inside each server. Read calls can auto-run while anything that writes waits for a person to confirm. A connection to a de-identified analytics store carries a different risk from one that can query production. Set the tool policy per server rather than once for all of them.

If a server can reach PHI at all, blocking it org-wide is cleaner than trusting per-tool settings to hold. Per-tool approval is for servers you already trust at the server level.

No. A team working entirely on synthetic or de-identified data does not need a BAA, and since the BAA is Enterprise-only, the tier question reduces to one thing. Does real PHI ever reach a prompt? If the answer is genuinely no, a lower tier is defensible.

What you give up is evidence. Audit logs are Enterprise, and so are SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition., CMEK and the org-wide policies, which means "Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. is on" describes each developer's own settings and not a state an admin has enforced. That distinction costs nothing until a provider customer's security review asks you to prove it instead of assert it.

The day it changes is usually the first pilot with a covered entity, whatever the headcount happens to be, so plan the upgrade a quarter before you expect to need it.