Security

Medbright handles Protected Health Information on behalf of medical clinics, so security is the foundation of the product rather than a feature bolted on afterward. We design every system around two principles: data is encrypted everywhere it lives or moves, and one clinic can never reach another clinic's data. The controls below describe how we enforce those principles today.

All traffic to and from the platform is encrypted in transit with TLS 1.2 or higher; we do not accept unencrypted connections. All patient data at rest — database records, file storage for insurance card and ID images, and voice-intake audio — is encrypted with AES-256. Encryption keys are managed by our cloud infrastructure providers and are never stored alongside the data they protect.

Medbright is multi-tenant from the ground up. Every record that can contain PHI carries a clinic identifier, and row-level security policies are defined at the database engine for every such table, so a query running under an end-user session cannot return another clinic's rows. Application services that need to act across a request — the server actions behind the dashboard — run with an elevated database role and enforce the same clinic scope in code. An automated scan runs on every build over every such query and blocks the release when one is missing its tenant filter; a small number of deliberate platform-wide sweeps are individually listed and justified in the codebase rather than silently skipped. Both layers are exercised by a multi-tenant isolation suite that runs in continuous integration and blocks deployment on failure.

Writes, extractions, edits, and downstream pushes of PHI generate an audit-log entry capturing the actor, the clinic, the entity and action, a content hash, and a timestamp, as do accesses by anyone outside the practice. Reads of message threads are logged server-side for staff and referral partners alike, including every attachment URL issued, and reads of clinical notes, visit transcripts and printed patient summaries are logged at the point the data is retrieved rather than at the page that displays it. The audit log is append-only: update and delete permissions are revoked at the database level for every role, including the elevated role the application itself runs under. Removing a clinic from the platform detaches that clinic's audit entries rather than deleting them, so the record of a deletion survives the deletion. This gives clinics a tamper-evident record of who touched what, and when.

Clinic staff sign in with email and password. Multi-factor authentication is available to every staff account and can be required for all members of a clinic by that clinic's owner; we do not currently enforce it per role. Where a clinic requires it, the requirement is applied by the same server-side guard that authorises every page and every action, not by the page layout alone. Repeated failed sign-ins and failed second-factor attempts are rate limited and locked out per account. Password strength is scored against current NIST 800-63B guidance at signup and reset. Patient access uses a single-use, signed check-in link gated by date of birth, scoped to a single appointment, and expiring within 48 hours — no standing patient credentials exist to be phished or reused across clinics.

Access to production systems is limited to a small number of engineering personnel under signed confidentiality and HIPAA agreements, and we operate on a least-privilege model: each person and each service holds the narrowest set of permissions needed for its task. The administrative console that can reach more than one clinic sits behind its own gate, and its destructive operations — removing a tenant, suspending one, or acting on a clinic's behalf — additionally require a fresh re-authentication with a second factor, recorded in a separate operator audit that is written before the action runs and aborts it if the record cannot be stored. Access is reviewed and revoked when it is no longer required.

We are actively working toward SOC 2 Type II attestation. That work is in progress and we are not yet certified — we will say so plainly here and update this page when our report is available. In the meantime, we are happy to walk prospective clinics through our controls, policies, and roadmap under NDA during evaluation.

Medbright executes a Business Associate Agreement (BAA) with a clinic before that clinic's real PHI is processed. The BAA governs our HIPAA obligations as a Business Associate. We will state the current agreement status of any individual subprocessor on request rather than make a blanket claim here. Contact security@medbright.ai to request a copy.

We rely on the following subprocessors to deliver the Service. Each is covered by a written agreement with terms appropriate to its access scope. “Patient data” below means the vendor receives Protected Health Information in the course of doing its job; the others receive operational data only.

• Supabase — Database, authentication, and file storage (United States) · patient data
• Vercel — Application hosting (United States) · patient data
• Anthropic — AI inference for clinical data extraction and drafting · patient data
• Twilio — Transactional SMS to patients · patient data
• Vapi — AI voice calling for intake and follow-up · patient data
• Deepgram — Speech-to-text for visit transcription and voice intake · patient data
• Zoom — Telehealth video, and recording where a clinic enables it · patient data
• Stedi — Clearinghouse for eligibility checks and claim submission · patient data
• Fly.io — Hosting for background processing workers · patient data
• Resend — Transactional email to clinic staff · operational data only

We update this list as subprocessors change and notify clinics at least 30 days before adding a new subprocessor that will handle patient data.

If you believe you have found a security vulnerability or suspect a breach, please contact us at security@medbright.ai. We investigate every report and will acknowledge receipt promptly.