Cursor + HIPAA: A Healthcare
Engineer's Checklist (2026)
Cursor doesn't sign a BAA — and doesn't need one. The 9-point engineering checklist for shipping HIPAA-safe code from an AI-native IDE
9-point engineer checklist
Privacy Mode + BAA model routing
Prompt template you can copy
By Garvita Amin· Co-Founder & CTO
July 8, 2026 · 11 min read
Cursor does not sign a HIPAA BAA, but it doesn't have to — Cursor is an IDE, not a covered service. The code Cursor helps you write can be fully HIPAA-compliant if you follow nine engineering rules: no PHI in prompts, BAA-covered model providers, BAA-covered cloud, audit logging, RBAC, encryption, dependency review, code review, and a documented risk analysis. Below is the 2026 checklist, mapped to the same cluster as the 2026 vibe-coding HIPAA gap list so you can compare Cursor's answer with Bolt, v0, and Lovable in one pass.
Key Takeaways
Cursor itself does not need a HIPAA BAA — it is a developer tool, not a service that processes PHI in production.
The #1 risk is developers pasting real patient data into Cursor chat. Block this with prompt hygiene rules and pre-commit PHI scanners.
Enable Cursor Privacy Mode and pin model providers to BAA-covered enterprise tiers (Anthropic Enterprise, Azure OpenAI, AWS Bedrock).
Cursor will not add audit logging, RBAC, or encryption defaults unless you prompt for them explicitly. Bake these into your prompt template.
Document Cursor in your § 164.308(a)(1)(ii)(A) risk analysis as a workforce tool that touches development artifacts.
Is Cursor HIPAA Compliant in 2026?
The short answer is that the question is slightly wrong. Cursor is an integrated development environment (IDE) that ships prompts and code context to Anthropic Claude and OpenAI APIs to generate suggestions. It is not a service that stores your production Protected Health Information, does not sit in the runtime path of your deployed app, and does not have a claim on your patient database. That distinction matters because HIPAA's Business Associate rule applies to entities that receive PHI, not to every tool a workforce member uses.
Under 45 CFR 160.103, a Business Associate is a person or entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity. If the developer never puts PHI into a Cursor prompt, Cursor never receives PHI, and no BAA is required for the IDE itself. What still needs BAAs are the LLM providers if PHI ever flows through them, the cloud where the generated code is deployed, and any observability or data service that touches the running app. Cursor's enterprise plan additionally offers a zero-retention configuration through Anthropic and OpenAI's enterprise APIs, which shrinks the risk surface further.
Under 45 CFR 160.103, a Business Associate is a person or entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity. An IDE that never receives PHI — because the developer follows prompt hygiene — is not a Business Associate. Source: HHS Office for Civil Rights, Business Associate definition.
The Compliance Line Sits at the Prompt, Not the Product
Cursor's HIPAA posture is not a property of Cursor. It is a property of what your team pastes into it. A team on Cursor Pro with disciplined prompt hygiene is safer than a team on a “HIPAA-branded” IDE that lets engineers routinely paste production rows into chat.
What Data Does Cursor Send to Its Model Providers?
Cursor's value comes from context. When you invoke chat or inline edit, Cursor packages the prompt you typed, the code you selected, nearby file context, file paths, and inferred metadata about the workspace, then ships that bundle to the configured model provider (Claude, GPT-4-family, or another supported model). With repo-wide context enabled, the surface grows to include additional files that Cursor thinks are relevant to your request.
Cursor's Pro and Business tiers expose a “Privacy Mode” toggle that disables the use of your prompts for model training and reduces retention. The Enterprise tier goes further, routing through Anthropic and OpenAI enterprise APIs that offer zero-retention guarantees. Practically, that means an Enterprise-configured Cursor session leaves nothing durable on the model provider's side once the request completes. To turn Privacy Mode on, open Cursor Settings and navigate to Privacy, then toggle Privacy Mode: enabled. Confirm the setting after any Cursor update — releases have occasionally shipped with the toggle reset.
Cursor's privacy documentation states that with Privacy Mode enabled, prompts are not stored beyond the request lifecycle and are excluded from model training. Cursor Business and Enterprise tiers route through Anthropic and OpenAI enterprise APIs with zero-retention guarantees. Source: Cursor Privacy & Security documentation, 2026.
Why Is a PHI Prompt the #1 HIPAA Risk With Cursor?
The realistic threat model for Cursor is not a nation-state breach of Cursor's infrastructure. It is a developer, at 11pm, debugging a parser, who pastes a real patient record into chat so the model can “see what the input looks like.” That PHI then lives inside the model provider's request logs, and — if Privacy Mode is off — potentially inside training corpora. It is the same exposure profile as pasting PHI into ChatGPT's consumer web interface, only more inviting because it is embedded in the developer's daily tool.
The fix is to make PHI-free prompting the path of least resistance. Every project should ship a Synthea-generated synthetic FHIR bundle in the repo, wired into fixtures so “show me the input” questions can be answered without real data. Wrong prompt: “Why does this endpoint fail on the record for John Doe, MRN 4478239, DOB 1962-04-11?” Right prompt: “Given the attached Synthea Patient bundle in fixtures/patient_synthea.json, why does parsePatient() return undefined?” Same debug, zero regulatory blast radius.
What Is the 9-Point Cursor + HIPAA Engineering Checklist?
The checklist below is the working document our team uses when a Cursor-heavy repo enters a HIPAA workflow. It is written for engineers, not lawyers — every point is either a concrete configuration change, a runtime control, or a documentation artifact. Work top to bottom; the earlier items reduce the surface area that the later items have to cover.
9
Checklist items
0
PHI rows allowed in prompts
6 yrs
Audit log retention
Prompt hygiene rules
Never paste real patient data into Cursor chat, inline edits, or committed prompt files. Ship a Synthea-generated synthetic FHIR bundle in the repo as the “show me the input” artifact. Add a pre-commit hook that scans staged diffs for regex patterns that look like MRNs, SSNs, DOBs, and common name-plus-DOB combinations, and blocks the commit. Train every engineer on the “wrong prompt vs right prompt” example. Treat the Cursor chat as if it were a public Slack channel for PHI purposes.
Enable Cursor Privacy Mode
In Cursor Settings → Privacy, toggle Privacy Mode: enabled. This blocks the use of your prompts for model training and reduces retention on the model provider side. On Enterprise, verify that requests are routed through the zero-retention enterprise endpoints, not the default consumer APIs. Re-check the setting after every Cursor release — a couple of past updates have reset user toggles. Document in your compliance file that Privacy Mode is required for all workforce Cursor installs.
Pin model providers to BAA-eligible tiers
Configure Cursor to route through providers with a signed BAA and zero-retention configuration. The three current defaults for healthcare teams: Anthropic Enterprise (Claude with zero-data-retention config), Claude on AWS Bedrock (covered under the standard AWS BAA), or Azure OpenAI Service (covered under the standard Microsoft BAA). Cursor Enterprise routes through these; on Pro tier you may need to pin models explicitly. If you can't verify the routing, treat the traffic as non-BAA.
Dependency audit on every generated file
AI-generated code loves outdated packages. Every Cursor-generated file goes through npm audit, pip-audit, or the equivalent for your stack before it lands on main. Wire the audit into CI so the check runs on the PR, not on the developer's memory. Version-pin every dependency the generator suggests, and prefer packages that already appear in your existing lockfile over the latest thing the model has heard of.
Deploy only to BAA-covered cloud
Cursor doesn't pick the deploy target — you do. Ship to AWS HIPAA-eligible services, Azure services in HIPAA scope, or Google Cloud services covered by GCP's BAA. Confirm the specific managed service (RDS, App Runner, Cloud Run, etc.) is on the vendor's HIPAA-eligible list and that your BAA names it. Never ship a Cursor-generated app to a free-tier host with no BAA and expect the app-layer controls to cover for it.
Audit logging on every PHI read/write
Cursor will not add logging unless you ask for it explicitly in the prompt. Every endpoint that touches PHI has to write to an append-only audit table capturing user_id, action, resource_id, timestamp, IP, status, and purpose-of-use, retained six years. Back that table with S3 Object Lock or the cloud-equivalent for tamper-evidence. The full field list is in our HIPAA audit logging deep dive.
RBAC + least privilege on every PHI endpoint
Cursor-generated CRUD defaults to “any authenticated user can do this,” which fails § 164.312(a) the moment a real user list arrives. Force explicit role checks (patient, clinician, billing, admin, auditor) on every endpoint that touches PHI. Enforce twice — once at the API layer and once in Postgres row-level security policies, so a bug in one layer doesn't become a data breach.
Encryption defaults verified, not assumed
AES-256 at rest, TLS 1.2+ in transit, no plaintext connection strings in .env examples or committed fixtures. Cursor sometimes generates code that downgrades TLS or writes secrets to disk unencrypted — verify every generated config against your baseline. Column-level encryption on the most sensitive PHI fields (SSN, mental-health notes, diagnosis codes) is the layer that survives a compromised DB credential. Pattern in our PHI encryption requirements guide.
Risk analysis under § 164.308(a)(1)(ii)(A)
Document Cursor in your asset inventory and risk register as a workforce tool that processes development artifacts. The IDE is not a Business Associate, but it is a system your workforce uses to build software that handles PHI, which puts it inside the risk analysis scope. Note the Privacy Mode configuration, the pinned model providers, the prompt hygiene training, and the pre-commit PHI scanner. This is the artifact OCR asks for first in any investigation — the pattern is covered in our HIPAA-compliant AI guide.
AWS, Azure, and Google Cloud all publish HIPAA-eligible service lists and will sign a Business Associate Addendum. As of 2026, AWS lists over 175 HIPAA-eligible services; Azure covers most production services; GCP's BAA covers Compute, BigQuery, Cloud Storage, and Vertex AI among others. Source: AWS HIPAA Eligible Services Reference, Azure HIPAA/HITECH scope documentation.
How Does Cursor's Default Behavior Compare to HIPAA Requirements?
The table below maps what Cursor gives you out of the box against the HIPAA rule the default fails, and the concrete engineering action that closes the gap. This is the artifact to hand to a new engineer joining the team — every row is a change they own.
| Cursor default | HIPAA requirement | Engineer's action |
|---|---|---|
| Prompts sent to Anthropic/OpenAI with default retention | No PHI exposure to non-BAA processors | Enable Privacy Mode; use Enterprise tier |
| Generated code has no auth checks | § 164.312(a) access control | Add RBAC + auth middleware in prompt |
| No audit logging in generated CRUD | § 164.312(b) audit controls | Require append-only PHI access log |
| Plaintext DB connection strings in .env examples | § 164.312(a)(2)(iv) encryption at rest | Force AES-256; KMS-managed keys |
| TLS not enforced on generated server | § 164.312(e)(1) transmission security | Force TLS 1.2+; HSTS header |
| Suggests dependencies without vuln check | § 164.308(a)(1)(ii)(B) risk management | Run npm audit / pip-audit on every gen |
| Verbose error responses leak schema | § 164.502(b) minimum necessary | Sanitize errors; generic 500 responses |
| No PHI redaction in logs | § 164.514(a) de-identification | Add PHI scrubber in logger middleware |
| No documented data flow | § 164.308(a)(1) risk analysis | Add Cursor to asset inventory |
Every row is a one-liner in a prompt or a five-line PR. What breaks teams is treating the list as optional. Cursor's productivity gain is real, but it comes with the tax of manually enforcing the defaults a HIPAA-native generator would have shipped for you.
How Do You Write a Cursor Prompt That Produces HIPAA-Safe Code?
Cursor is a mirror — if you ask for “a patient search endpoint,” you get a patient search endpoint with no auth, no audit log, and no encryption. If you ask for the HIPAA-compliant version, you get the HIPAA-compliant version. The trick is a prompt template every engineer keeps in their snippets and uses on every generation that touches PHI.
Wrong prompt: “Write a patient search endpoint in Express that queries the patients table by name.”
Right prompt (copy-paste template):
Write a patient search endpoint in Express using Prisma. Requirements: (1) require a signed JWT via authMiddleware; (2) enforce RBAC — only roles clinician or admin may call this endpoint; (3) write an audit-log row to the phi_access_log table with user_id, action="patient.search", resource_id, timestamp, IP, status, purpose_of_use before returning any data; (4) return only the minimum necessary fields (id, name, dob) — no SSN, no diagnosis; (5) return a generic 500 on error, do not leak schema; (6) do not log the search query or the returned rows to console.log or Sentry — PHI must not enter application logs.
Same endpoint, radically different generated code. Save this template in your team's snippet library and treat any deviation as a bug. The template also acts as documentation for the audit — when OCR asks “how do you ensure generated code meets § 164.312,” the answer is “here is the prompt template every engineer uses.”
When Does Cursor Itself Need a BAA?
Cursor would need a BAA only in the scenario where your usage causes Cursor's servers to process PHI. In practice, with Privacy Mode enabled and prompt hygiene enforced, that scenario doesn't occur — the IDE only sees code and generated context, never patient records. If your team cannot commit to that discipline (for example, in an environment where developers routinely debug against production data), then the correct move is not to try to sign a BAA with Cursor; it is to move debugging to an isolated environment with de-identified data and keep Cursor out of the PHI path entirely.
Cursor's Enterprise plan does offer contractual data handling commitments — retention guarantees, SSO, audit exports, admin controls — even without a formal BAA. For most healthcare teams, Enterprise + Privacy Mode + a documented determination that no PHI flows into Cursor is the sustainable posture. Write the determination down, sign it, keep it in your compliance file next to the risk analysis, and review it annually. If your workforce grows and prompt hygiene becomes harder to enforce, escalate through Cursor sales at that point — but the correct default is not to need it.
Sign the determination that Cursor is not a Business Associate for your workflow. Attach it to your risk analysis. That written determination is the artifact OCR wants — not a BAA that your IDE vendor won't sign.
Frequently Asked Questions
Is Cursor HIPAA compliant?
Cursor itself is not a HIPAA-covered entity or Business Associate by default. Your usage determines whether you need a BAA — and proper prompt hygiene means you don't. Cursor is an IDE, not a service that processes PHI in production, so the BAA obligation attaches to the LLM providers, cloud host, and runtime services that sit downstream of the code Cursor helps you write.
Does Cursor sign a Business Associate Agreement?
Cursor does not publish a standard BAA. Its Enterprise plan offers contractual data handling terms (retention guarantees, SSO, admin controls). If your workflow requires a BAA on the IDE itself, you need to escalate through Cursor sales — but for most healthcare teams, the correct posture is to configure Cursor so no PHI flows through it, making a BAA on the IDE unnecessary.
Can I use Cursor with Claude or GPT to write code that handles PHI?
Yes — the code that gets deployed can handle PHI. The prompts you send to Cursor must not contain PHI. As long as prompts stay PHI-free (via synthetic fixtures and prompt hygiene rules), the runtime app can process real patient data safely because the PHI never touches the IDE or the model provider during development.
Does Cursor Privacy Mode meet HIPAA requirements?
Privacy Mode blocks training-data use and reduces retention on the model provider side. It is a necessary control but not sufficient on its own — you still need the other 8 points of the checklist (prompt hygiene, BAA-covered providers, dependency audit, BAA-covered cloud, audit logging, RBAC, encryption, and a documented risk analysis).
Is Cursor's autocomplete safe in a HIPAA codebase?
Yes, if you don't have PHI in open files. Cursor's autocomplete sends surrounding file context to the model, so any PHI in an open file is shipped along with the completion request. Keep PHI test fixtures out of any repo opened in Cursor — use Synthea-generated synthetic FHIR bundles as your fixtures instead.
What if a developer accidentally pastes PHI into Cursor chat?
Treat it as a breach assessment under the Breach Notification Rule. Document the incident, rotate any exposed identifiers where possible, contact the model provider about their retention on the affected request, and notify if the risk assessment requires it. Add automated PHI-detection pre-commit hooks and repeat prompt-hygiene training so the same accident is harder to make next time.
Is GitHub Copilot a safer alternative to Cursor for healthcare?
GitHub Copilot Business offers a no-retention guarantee on prompts. Microsoft signs a BAA covering many Azure services, but not Copilot specifically as of 2026. The same prompt-hygiene rules apply — the difference between Copilot and Cursor in a HIPAA workflow is smaller than most teams assume, and comes down to who your engineers are actually disciplined with.
Do I need to list Cursor in my HIPAA risk analysis?
Yes — any workforce tool that processes ePHI-adjacent artifacts (source code, schemas, log formats, prompt files) belongs in your asset inventory and risk register per § 164.308(a)(1)(ii)(A). Note the Privacy Mode configuration, the pinned model providers, the prompt hygiene training, and the pre-commit PHI scanner. This is the artifact OCR asks for first in any investigation.
Ship Cursor-generated code to a HIPAA-compliant runtime, without the migration tax
VertiComply is a managed HIPAA deployment target for the code you build in Cursor: BAA on day one, audit logging, RBAC, column-level PHI encryption, and a starter risk analysis wired in. Keep the IDE you love; skip the 9-point retrofit.
Cursor for the prompt. VertiComply for the compliance surface.
Comparing generators? Read the sister spokes: the Lovable HIPAA-compliant backend playbook, the Bolt.new HIPAA migration playbook, and the v0 and Vercel HIPAA compliance gap — then loop back to the 2026 vibe-coding HIPAA gap list for the cross-tool comparison.
In This Guide
01
Is Cursor HIPAA compliant in 2026?
02
What data does Cursor send?
03
Why PHI prompts are the #1 risk
04
The 9-point engineering checklist
05
Cursor defaults vs HIPAA requirements
06
Writing a HIPAA-safe prompt
07
When does Cursor need a BAA?
08
FAQ
Key Numbers
Checklist items
9
BAAs Cursor signs by default
0
AWS HIPAA-eligible services
175+
Audit log retention
6 yrs
Glossary
Topics
Related Articles
Continue reading about vibe coding, HIPAA, and healthcare app architecture
Vibe-Coded a Healthcare App? The HIPAA Gap List (2026)
Vibe-coded healthcare apps from Cursor, Lovable, Bolt, v0, Replit, or Base44 ship 7 HIPAA gaps by default — no BAA, plaintext PHI, no audit log, weak access controls. The triage list + the fix for each.
Read article
Lovable + HIPAA: A Compliant Backend for Healthcare (2026)
Lovable does not sign a BAA. The architecture for keeping PHI off Lovable while keeping its prototyping speed: BAA-covered Supabase + Postgres alternatives, encryption defaults, audit logging, and the 4 mistakes that fail an OCR audit.
Read article
Bolt.new for Healthcare: The HIPAA Migration Playbook (2026)
Bolt.new is great for prototypes, fails HIPAA in production. The migration path: lift the React UI, replace the StackBlitz preview with a BAA-covered backend, add encryption + audit logging, document the risk analysis.
Read article