Vibe coding enterprise healthcare limits: where PHI stops working

No. Not as the runtime for the production app. Vibe coding tools generate browser-side HTML/CSS/JS and host it in shared sandboxes (in mk0r's case, E2B sandboxes that auto-pause every hour per E2B_TIMEOUT_MS = 3,600,000 in src/core/e2b.ts line 33). HIPAA's Security Rule (45 CFR §164.312) requires access control, audit logs, and encryption at rest with a managed key. None of those are produced by the agent. There is also no Business Associate Agreement between you and the sandbox provider that extends to PHI you put through the generated app, which §160.103 makes load-bearing. Use vibe coding for synthetic-data prototypes, then rebuild the production app on infrastructure where the BAA, the auth model, and the audit log are first-class.

Three things you can read directly. First, the runtime: E2B_TIMEOUT_MS at src/core/e2b.ts line 33 is 3,600,000 milliseconds, with lifecycle: { onTimeout: 'pause', autoResume: true } at line 309. The sandbox suspends at the 1 hour mark. POOL_MAX_AGE_MS at line 1896 recycles warm pool entries at 45 minutes. Second, the publish path: src/app/api/publish/route.ts line 11 sets NOTIFY_TO = 'i@m13v.com', and the deploy action sends an email rather than provisioning DNS, while src/core/e2b.ts line 1870 throws 'Domain publishing is not yet supported on the E2B backend.' Third, the model layer: src/app/api/chat/model/route.ts line 5 sets FREE_MODEL = 'haiku' and returns 'subscription_required' for anyone trying to switch without billing. None of these are bugs. They are correct decisions for a prototyping tool, and each one independently disqualifies the workload for PHI.

Two regulatory hinges matter. The HIPAA Privacy Rule (45 CFR Part 164, Subpart E) governs how Protected Health Information is used and disclosed. The HIPAA Security Rule (45 CFR Part 164, Subpart C) governs the technical and administrative safeguards on the systems that touch PHI. 'Enterprise' adds organizational layers: SSO, SCIM provisioning, audit-log export to the security team's Splunk or Sumo, change management routed through the IT ticketing system, and procurement that requires a signed BAA before any compute touches a patient record. A vibe coding tool is the wrong shape for any of those. It does not have an enterprise plan, an SSO setting, an auditable change pipeline, or a BAA in the loop with the sandbox provider. Categorically the wrong tool, not a tool that is missing one feature.

Anywhere the data is synthetic and the lifespan is short. A clinician describes a workflow change at standup. A product manager opens mk0r, types a sentence, watches a mobile-first prototype build live, and hands the link around the room before the meeting ends. The sandbox dies an hour later. Nothing was persisted. No PHI was ever in scope. That loop is the right loop for healthcare prototyping precisely because the throwaway-by-default lifecycle (the sandbox auto-pauses, no account is created) maps cleanly onto 'we do not want this thing to outlive the conversation.' The product config calls out exactly this lane: 'has a specific app or prototype idea they want to ship or demo within the next week or two,' and 'fine with mobile-first HTML/CSS/JS output as the starting point.' For a clinical demo with no real data, that fits.

You can build the UI on synthetic data and hand it to engineering as a spec. You should not load real PHI into the prototype 'just for testing,' even on an internal-only network. The prompt and any pasted text are sent to the model provider, the generated app is hosted on infrastructure outside your covered-entity boundary, and the preview URL on the mk0r preview subdomain is internet-reachable. That combination violates §164.502 minimum necessary use and §164.312(e)(1) transmission security. The clean rule for any AI app builder, including mk0r: every byte of data you paste or render in the preview is leaving your hospital's compliance boundary. Treat synthetic test data as the only acceptable input.

Three swaps, in order. The runtime: deploy the generated HTML/CSS/JS (or the underlying Vite/React project, the prototype repo is portable) onto compute that has a signed BAA. AWS, GCP, and Azure all sign BAAs for their HIPAA-eligible services. The auth and storage: replace the prototype's hard-coded fixtures with a real identity provider (Okta, Azure AD with SAML/SCIM) and a HIPAA-eligible database with encryption at rest using a customer-managed KMS key. The audit log: instrument every PHI read and write with structured logs that flow into your SIEM, with retention that meets §164.316(b)(2). The vibe-coded artifact informs the build, the build is what ships. None of those steps require throwing out the design work, which is the point of using vibe coding for the discovery phase.

Not in the open consumer category. The closest analogs are platforms with explicit HIPAA-eligible tiers (a managed enterprise plan, a signed BAA, SSO, audit logs, encryption at rest with managed keys). Those tools are typically not free, not no-account, and not 1-hour-sandbox-by-default. The reason is that all of those constraints add cost and friction. Vibe coding wins on speed because it strips them out. The two product shapes are answering different questions. The right move is to use the fast no-account tool for the early loop, then graduate to the slower compliant tool when the work moves into production.