Vibe-Coded a Healthcare App?
The HIPAA Gap List (2026)
The 7 HIPAA gaps that ship by default in every Cursor, Lovable, Bolt, v0, Replit, and Base44 healthcare app — and the fix for each
BAA chain triage
Encryption + audit log fixes
Tool-by-tool eligibility table
By Garvita Amin· Co-Founder & CTO
June 25, 2026 · 15 min read
A vibe-coded healthcare app ships with seven HIPAA gaps by default: no signed BAA chain, plaintext PHI at rest, no audit log on patient-record reads, single-role access control instead of RBAC, PHI in prompt history, deployment to a non-BAA host, and no written risk analysis. Cursor, Lovable, Bolt, v0, Replit, and Base44 are all genuinely useful tools — they just train on the public web, which contains almost no real PHI handling, so the defaults they emit are wrong for healthcare. This is the triage list and the fix for each gap, ordered by what an OCR investigator would hit first.
Key Takeaways
- Vibe-coded healthcare apps ship with 7 HIPAA gaps by default; none of the six major vibe-coding tools (Cursor, Lovable, Bolt, v0, Replit, Base44) sign a BAA with end users in mid-2026.
- The biggest legal gap is the BAA chain: generated code calls OpenAI, Anthropic, Vercel, Supabase, and other vendors that each need their own BAA — the AI tool does not negotiate that for you.
- Generated CRUD code uses plaintext Postgres, no column-level encryption, no audit logging, and a single role flag — all four fail § 164.312 controls.
- Pasting PHI into a vibe-coding tool's chat (Cursor, Lovable, Bolt, ChatGPT) is itself a reportable HIPAA breach unless the tool is on a BAA-covered tier.
- The fix is a five-step triage: BAA inventory, encryption, audit log, RBAC, risk analysis — applied to the generated code before any real patient touches it.
What is vibe-coding, and why does it break HIPAA by default?
Vibe-coding is the practice, first publicly framed by Andrej Karpathy in early 2024, of generating production code by describing intent in natural language to an AI assistant and accepting most of the output without fully reading it. The vibe-coding stack as of mid-2026 is a half-dozen tools: Cursor and Copilot-style IDE assistants, Lovable and v0 for full-app generation, Bolt.new and Replit for AI-first cloud IDEs, and Base44 for no-code app generation. They are remarkable productivity tools. They are also, by default, hostile to HIPAA.
The mechanism is not malicious; it is statistical. These tools learned to code from public GitHub, npm, PyPI, and Stack Overflow. Less than one percent of public code is healthcare-grade, and almost none of it ships proper PHI handling, because real healthcare code lives in private repositories behind firewalls. So when a vibe-coder asks Cursor to "build a patient intake form," the model emits the most statistically likely shape of a generic web form — Prisma model, Next.js API route, fetch from React, throw it in localStorage. None of that satisfies HIPAA. It just looks like working code, and the developer ships it.
Per Specode's 2025 vibe-coding-in-healthcare survey and corroborating audit data from TechExactly, an estimated 73% of vibe-coded healthcare apps fail their first HIPAA audit on access control or audit log gaps alone — before any encryption or BAA issues are even reviewed. Source: Specode "Vibe Coding in Healthcare" report and TechExactly compliance audit aggregate, both published 2025.
The pattern is consistent across tools. The model emits plausible code, the developer trusts the vibe, the app ships, the OCR investigator opens the database and finds plaintext PHI on first query. The fix is not to stop using AI assistants — the leverage is too real to give up. The fix is to know what defaults are broken and patch them deliberately.
What does HIPAA actually require from a healthcare app?
HIPAA boils down to four enforceable technical controls and a stack of paperwork. The technical floor is set by the Security Rule at 45 CFR § 164.312 and the administrative requirements at § 164.308. The four controls every covered application must implement:
BAA chain. Every business associate that handles PHI on your behalf must have a signed Business Associate Agreement. § 164.504(e) and § 164.314(a). The chain includes your AI model, your database vendor, your hosting platform, your observability tool, your error-tracking service, anyone.
Encryption. PHI must be encrypted in transit (TLS 1.2+, made required by the January 2025 Security Rule update) and at rest (AES-256 or stronger). § 164.312(a)(2)(iv) and § 164.312(e)(2)(ii).
Audit logs. Every PHI access, modification, and deletion must be logged with user, timestamp, action, target record, and outcome — retained for six years. § 164.312(b) and § 164.316(b)(2)(i).
Access controls. Role-based access controls with the minimum-necessary principle, plus unique user identification and automatic logoff. § 164.308(a)(3) and § 164.312(a)(1).
HIPAA § 164.312 specifies four required technical safeguards: access control with unique user identification, audit controls that record activity in information systems containing PHI, integrity controls, and transmission security — with encryption explicitly required as of the January 2025 Security Rule final update. The 2025 update moved encryption from "addressable" to "required." Source: 45 CFR § 164.312, as amended January 2025.
Layered on top: a written risk analysis under § 164.308(a)(1)(ii)(A), incident response procedures, workforce training, and a sanction policy. The vibe-coded app misses every single one of these by default, because none of them are in the training distribution of a generic React or Next.js codebase.
What are the 7 HIPAA gaps in every vibe-coded healthcare app?
Every vibe-coded healthcare app I have reviewed ships with the same seven gaps. The order below is the order an OCR investigator would surface them in — not because OCR has a published checklist, but because these are the controls that fail loudest on first look.
Gap 1: No BAA chain
The most consequential gap, because it is the one most invisible to developers. Vibe-coding tools do not sign BAAs — not Cursor, not Lovable, not Bolt, not v0, not Replit, not Base44, not consumer ChatGPT, not Claude.ai, not Gemini. The generated code then calls services that each need their own BAA: OpenAI, Anthropic, Vercel, Supabase, Neon, Pinecone, Postgres on a non-BAA host. Each of those is a separate negotiation. The developer typically discovers this gap when their first paying customer asks for the BAA list.
Fix. Inventory every external call the generated code makes. For each, check whether the vendor signs a BAA and on which tier. Then either upgrade to the BAA tier, swap the vendor for a BAA-eligible alternative, or remove the integration from the PHI path. The reusable BAA matrix from our BAA vs HIPAA explainer is the starting point.
Gap 2: Plaintext PHI at rest
Generated database code — Prisma schemas, Drizzle ORM, raw Supabase queries, the typical Postgres-on-Neon setup that v0 emits — has no column-level encryption. The disk itself may be encrypted by the cloud provider (which counts for in-transit-style protection but not for application-layer PHI segregation), but the columns themselves contain plaintext patient names, diagnoses, and SSNs. A database export reveals everything.
Fix. Add column-level encryption on every PHI field. Use pgcrypto or application-layer envelope encryption, keyed from a KMS the deployment infrastructure provides (AWS KMS, GCP Cloud KMS, Azure Key Vault). Read/write through a thin encryption layer so the developer experience stays close to what the AI generated.
Gap 3: No audit logging on PHI reads
This is the gap that catches most teams in their first audit. Generated CRUD endpoints — the Next.js API routes Cursor writes, the Lovable functions Lovable exports — record nothing. Patient records are read, modified, and deleted with no trace. § 164.312(b) requires the trace, and OCR settlements have been built entirely on this gap (Anthem 2018 included audit log failures as a central finding).
Fix. Wire audit logging into every PHI read and write. The seven fields HIPAA wants per event: who (user ID), what (action: read/create/update/delete), which record (patient ID + record type), when (timestamp UTC), where (source IP + user agent), why (purpose code if you support one), and outcome (success/failure). Retain six years. The pattern is in our audit logging deep dive.
Gap 4: Weak access controls (single role check, no RBAC)
Generated auth code is usually a single role flag — user.role === 'admin' or a check against Clerk/Auth0's default user object. § 164.308(a)(3) and § 164.312(a)(1) want full role-based access control with minimum-necessary enforcement: a clinician sees their own panel, a nurse sees their unit, an admin sees everything, a patient sees only themselves. The default vibe-coded auth flunks this on the first investigator question.
Fix. Introduce real RBAC. Roles, permissions, resource-level scoping, a policy engine (Cedar, OPA, or a hand-rolled table-driven policy layer). Every PHI endpoint runs through the policy. Document the policy matrix.
Gap 5: PHI in chat or prompt history
This is the gap developers create themselves while debugging. The clinician shows up with a bug, the developer copy-pastes the failing patient record into Cursor's chat or ChatGPT to figure out the parse error, the AI tool logs the prompt indefinitely on its server. That paste is now a HIPAA breach under § 164.402, reportable to OCR, with notification obligations to the patient.
Critical — Never paste PHI into Cursor, Lovable, ChatGPT, or any non-BAA AI tool
The act of pasting a real patient name, MRN, diagnosis, or any identifier into a non-BAA AI surface is itself a reportable HIPAA breach. OpenAI signs BAAs on the API + ChatGPT Enterprise + Edu tiers with zero-retention; Anthropic on the Claude API with the BAA add-on. Consumer ChatGPT, Cursor chat, Lovable chat, and Bolt chat are not BAA-covered. Use synthetic data or BAA-covered surfaces.
Fix. Two parts. First, prohibit PHI-in-prompt operationally: training, sanction policy, automated scrubbing of clipboards and pre-prompt PII detection (Presidio, the open-source PII scanner, runs locally). Second, route AI-assisted debugging through a BAA-covered surface: OpenAI API on the Enterprise plan with zero-retention, Claude API with the BAA add-on, or a BAA-covered platform like VertiComply.
Gap 6: Insecure default deploy targets
The deploy target the vibe-coding tool nudges you toward is almost never BAA-eligible by default. Vercel Hobby and Pro do not sign BAAs (Enterprise + HIPAA add-on does). Replit free and Teams do not. Lovable preview URLs do not. Bolt's WebContainer preview does not. Netlify standard does not. Render and Railway standard tiers do not. Hosting PHI on any of these is a violation regardless of how the code is written.
Fix. Migrate to a BAA-covered host before launch. The cheapest options that sign BAAs are AWS, GCP, and Azure (BAA is free, you pay for services). Vercel Enterprise + HIPAA, Render Team with HIPAA, and Fly.io Enterprise sign BAAs at higher floor pricing. VertiComply includes the BAA on every plan including free.
Gap 7: No written risk analysis
OCR's very first document request in any investigation is your written risk analysis under § 164.308(a)(1)(ii)(A). Vibe-coded apps don't have one, because risk analyses aren't in the training distribution of Next.js codebases. Without one, you are technically out of compliance the moment you touch PHI, regardless of how good the rest of the controls are.
Fix. Write the risk analysis. NIST SP 800-30 Rev. 1 is the canonical methodology; HHS publishes a free SRA (Security Risk Assessment) tool that works for small teams. The document inventories the PHI you handle, the threats to it, the controls you have in place, and the residual risk. Update it annually and on material change.
Is Cursor HIPAA-compliant? Is Lovable? Is Bolt? The tool-by-tool table
The exact-match question developers ask first. The honest answer for every major vibe-coding tool in mid-2026:
| Tool | BAA Signed? | Safe to Paste PHI? | Code Output OK with Triage? |
|---|---|---|---|
| Cursor | No | ||
| Lovable | No | ||
| Bolt.new | No | ||
| v0 by Vercel | Enterprise only | ||
| Replit | No | ||
| Base44 (Wix) | No | ||
| VertiComply | Yes (free + paid) |
The first published deep-dive in this cluster:
Lovable HIPAA-compliant backend migration — the export-then-harden playbook.
Per-vendor deep-dives for Cursor, Bolt.new, v0, Replit, and Base44 are in our editorial queue; in the meantime the triage steps below apply across every tool in the comparison table above.
How do you fix a vibe-coded healthcare app?
The five-step triage runs in this order. The order matters: BAA first, because without it the rest is moot; risk analysis last, because it summarizes what the other four found.
Inventory the BAA chain
List every external service the generated code touches: AI model, database host, file storage, email provider, error tracker, analytics, observability, payment processor, anything. For each, check the BAA status. Maintain the inventory as a living document; vibe-coding generates new integrations every sprint.
Add column-level encryption
Pick a key management service (AWS KMS / GCP KMS / Azure Key Vault), generate a data encryption key per tenant, encrypt every PHI column at the application layer. Use pgcrypto or an ORM-level extension. Read/write through a thin helper so the developer experience matches the AI-generated baseline.
Add audit logging (the 7 fields HIPAA wants)
Wire a middleware layer into every PHI route. Capture user, action, record type, record ID, timestamp UTC, source IP + UA, outcome. Ship logs to a BAA-covered store (CloudWatch on AWS, Cloud Logging on GCP, Sentinel on Azure, or a BAA-covered SIEM). Retain six years.
Add real RBAC + PHI access policies
Define roles. Define resource-level scoping. Build a policy engine or table-driven policy layer. Every PHI endpoint runs the policy before responding. Default deny. Document the matrix — OCR will ask for it.
Document the risk analysis (§ 164.308(a)(1))
Write the risk analysis. NIST SP 800-30 Rev. 1 methodology, or HHS's free SRA tool for small teams. List assets (PHI types), threats, vulnerabilities, current controls, residual risk, mitigation plan. Sign and date it. Update annually and on material change.
Which AI code-gen tools are actually HIPAA-eligible in 2026?
The clean answer: as of mid-2026, none of the major vibe-coding tools sign a BAA with the developer using them. Cursor, Lovable, Bolt, v0, Replit, and Base44 all decline at the user-facing tier. The reasoning is consistent across vendors: they treat generated code as developer artifacts, not as a covered service. That makes their product simpler to operate but pushes HIPAA-eligibility entirely onto the developer.
The code those tools generate, however, can absolutely be made HIPAA-eligible if it's deployed on BAA-covered infrastructure with the 7-gap fix list applied. The vibe-coding tool doesn't need to be HIPAA-eligible — the runtime does. You can use Cursor to write the code, then deploy it to AWS with the AWS BAA in place and the column encryption, audit log, and RBAC patched in, and the resulting application is HIPAA-compliant.
The shortcut around this entire 7-gap triage: VertiComply generates HIPAA-eligible defaults out of the box on every plan, including free. BAA-covered AI inference, encrypted-by-default Postgres, audit logging wired into the CRUD layer, RBAC scaffolded per generated entity, BAA-covered hosting on day one. The point isn't that other vibe-coding tools are bad — they're excellent at non-healthcare. The point is that healthcare-by-default is a different product.
For teams that prefer to keep using their existing AI assistant, the bridge is: write the code anywhere, deploy to a BAA-covered host, apply the 7-gap fixes. For teams that want to skip the triage entirely, an AI code-gen platform that ships HIPAA defaults is the simpler path. Either route is valid; the unsafe path is the one where the vibe-coded app ships to a Vercel Hobby URL with plaintext PHI.
What mistakes get vibe-coders into trouble with OCR?
Patterns that have produced settlements in the real world, all of which are particularly easy to hit when shipping vibe-coded code without the triage:
Mistake 1: Missing access controls (Anthem 2018, $16M)
Anthem's 2018 OCR settlement — the largest in HIPAA history at $16 million — centered on access control failures and missing audit logs. The technical findings included unrestricted access to PHI by users who didn't need it, and no audit trail for the access that did happen. Both are gaps 3 and 4 on the vibe-coding triage list. A vibe-coded app that ships with single-role auth and no audit log has the same controls Anthem was fined $16M for.
Mistake 2: PHI in non-BAA cloud services (Premera 2020, $6.85M)
Premera Blue Cross's 2020 OCR settlement involved failure to ensure cloud-based assets that handled PHI were covered by BAAs. The vibe-coded equivalent: generated code calls Resend for email, Posthog for analytics, OpenAI for an embedded chatbot, Cloudinary for image hosting, none of which were signed onto a BAA. Each is a separate covered-entity-class violation.
Mistake 3: Lack of risk analysis (Touchstone Medical Imaging 2019, $3M)
Touchstone Medical Imaging's 2019 settlement called out the absence of a thorough, written risk analysis under § 164.308. The vibe-coded gap 7. OCR's position is consistent: without the written risk analysis, the rest of your security program is unauditable, and the absence is itself a violation.
None of these settlements were against AI-coded startups specifically. They're against organizations that had the same default-broken controls a vibe-coded app ships with. The OCR enforcement pattern doesn't care whether the broken code was written by a senior engineer in 2017 or by Cursor in 2026. The standard is the same.
FAQ
Is Cursor HIPAA-compliant?
No. Cursor does not sign a BAA with end users on any tier as of mid-2026, and the code it generates uses non-BAA defaults (Vercel Hobby, plaintext Postgres, no audit log). You can use Cursor to write healthcare code, but you must never paste PHI into its chat, and the generated code requires the 7-gap fix list before it touches a real patient.
Can I use Lovable for a healthcare app with PHI?
Not in production. Lovable does not sign a BAA, and its preview deploys (Lovable preview URLs) run on infrastructure that has never been BAA-eligible. You can prototype on Lovable, then migrate the generated code to a HIPAA-eligible host (AWS with BAA, GCP with BAA, or VertiComply) before any real PHI lands. The code itself still needs the 7-gap fix list.
Does Vercel sign a BAA?
Only on the Vercel Enterprise tier with the HIPAA add-on. Hobby, Pro, and standard team plans do not include a BAA. If a v0-generated app or any vibe-coded Next.js app gets deployed to default Vercel without the Enterprise BAA, every PHI request through that deployment is a HIPAA violation regardless of how clean the code is.
What about Bolt.new for healthcare?
Bolt.new does not sign a BAA and its WebContainer preview environment is not HIPAA-eligible. The code Bolt generates can be exported, migrated to a HIPAA-eligible host, and fixed for the 7 gaps. Never push PHI to a Bolt preview URL or paste PHI into the Bolt prompt.
Is it safe to paste PHI into ChatGPT or Cursor for debugging?
No. OpenAI does sign BAAs on ChatGPT Enterprise and the API with zero-retention configured, but consumer ChatGPT and Cursor chat do not. Pasting a real patient name, MRN, diagnosis, or any other identifier into a non-BAA AI tool is a reportable HIPAA breach under § 164.402. Use synthetic data, scrub before paste with Presidio, or use a BAA-covered AI surface.
Which AI code-gen tool ships HIPAA defaults out of the box?
VertiComply is the only AI code-gen platform we know of that ships HIPAA-eligible defaults — BAA-covered AI inference, encrypted-by-default Postgres, audit logging wired into the CRUD layer, and RBAC scaffolded for every generated entity. Every plan, including free, includes the BAA. Most vibe-coding tools (Cursor, Lovable, Bolt, v0, Replit, Base44) are excellent for non-healthcare work but require manual hardening for PHI.
How do I migrate a vibe-coded app to HIPAA-compliant infrastructure?
Run the 7-gap triage: (1) inventory every external service the generated code calls and sign BAAs with each, (2) add column-level encryption to the PHI tables, (3) wire audit logging into every PHI read and write, (4) replace the single role check with real RBAC, (5) scrub any PHI from prompt history, (6) redeploy to a BAA-covered host (AWS, GCP, Azure with BAA, or VertiComply), and (7) write the § 164.308(a)(1) risk analysis.
What's the cheapest HIPAA-eligible deploy target for a vibe-coded healthcare app?
VertiComply free tier is HIPAA-eligible with the BAA included. Outside that, the cheapest options that sign BAAs are AWS (BAA is free, you pay for the services), GCP (same model), and Azure (same). Vercel Enterprise, Render Team, and Fly.io Enterprise sign BAAs but at higher floor pricing. Hobby tiers of Vercel, Netlify, Railway, and Render do not sign BAAs and cannot host PHI regardless of how the code is written.
Does Replit sign a BAA for healthcare apps?
No. Replit does not sign a BAA on any tier as of mid-2026, including Teams and Pro. Replit-generated and Replit-hosted apps cannot legally process PHI. You can prototype on Replit, then export the code and migrate to a BAA-covered host with the 7-gap fix list applied.
Is Base44 HIPAA-compliant?
Base44 does not sign a BAA at the platform level, though acquired by Wix and integrated into the Wix Enterprise ecosystem, certain HIPAA-eligible configurations may be available on Wix Enterprise tiers. Default Base44 deploys are not HIPAA-eligible. The generated code still needs the 7-gap fix list before processing PHI.
Skip the 7-gap triage. Ship HIPAA-eligible by default.
VertiComply generates healthcare apps with BAA-covered AI, encrypted Postgres, audit logging, RBAC, and a BAA-covered host wired in on day one — on every plan including free. Same vibe-coding speed; HIPAA defaults baked in.
BAA on day one. Encryption + audit log built in. No 7-gap triage.
In This Guide
01
What is vibe-coding?
02
What HIPAA actually requires
03
The 7 HIPAA gaps
04
Cursor, Lovable, Bolt — table
05
How to fix a vibe-coded app
06
HIPAA-eligible AI code-gen tools
07
OCR enforcement patterns
08
FAQ
Key Numbers
HIPAA gaps shipped by default
7
Vibe-coded apps that fail audit
73%
Vibe tools that sign user BAAs
0
Audit log retention required
6 yrs
Stat Cards
7
Gaps per app
6
Major tools, 0 BAAs
Glossary
Related Reading
Topics
Related Articles
Continue reading about HIPAA, AI code generation, and healthcare app builders
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
HIPAA, Stripe & EHR Integration: Handle Payments and PHI Together (2026)
Stripe does not sign BAAs. The exact architecture for charging patients through Stripe while keeping PHI on the BAA-covered EHR side, plus the 3 processors that DO sign (Square Healthcare, InstaMed, BlueSnap) and the 3 mistakes that fail OCR audits.
Read article
Build a HIPAA-Compliant AI Medical Scribe in 2026
How to build a HIPAA-compliant ambient AI medical scribe: BAA-eligible speech + LLM stack, recording consent, clinician-in-the-loop review, hallucination guardrails, and FHIR write-back.
Read article