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 isolation is enforced by row-level security at the database engine — not merely in application code. A query issued for one clinic physically cannot return another clinic's rows, even if application-layer logic were compromised. There is no administrative escape hatch that bypasses tenant isolation without a documented security review.

Every read, write, extraction, edit, and downstream push of PHI generates an audit-log entry capturing the actor, the clinic, the entity and action, a content hash, and a timestamp. The audit log is append-only: update and delete permissions are revoked at the database level, so historical entries cannot be altered or removed — including by privileged service accounts. This gives clinics a tamper-evident record of who touched what, and when.

Clinic staff sign in with email and password, with multi-factor authentication available and enforced for privileged roles. 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. Production access requires multi-factor authentication, and we operate on a least-privilege model: each person and each service holds the narrowest set of permissions needed for its task. Access is reviewed quarterly and revoked promptly when 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 every clinic before any real PHI is processed. The BAA governs our HIPAA obligations as a Business Associate and flows mirrored terms down to each subprocessor that handles PHI on our behalf. 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, and any subprocessor that handles PHI does so under a BAA or equivalent:

• Supabase — database, authentication, and file storage
• Vercel — application hosting
• Anthropic — AI inference for clinical data extraction, under a zero-data-retention configuration
• Twilio — transactional SMS messaging
• Resend — transactional email

We update this list as subprocessors change and notify clinics at least 30 days before adding a new PHI-handling subprocessor.

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.